From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re: Too many open files (was Re: spinlock problems reported earlier) |
Date: | 2000-08-28 18:48:51 |
Message-ID: | Pine.BSF.4.21.0008281544490.564-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 28 Aug 2000, Tom Lane wrote:
> The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> >> cat t.c
> > #include <stdio.h>
> > #include <unistd.h>
>
> > main()
> > {
> > printf("%ld\n", sysconf(_SC_OPEN_MAX));
> > }
>
> >> ./t
> > 4136
>
> Yup, there's our problem. Each backend will feel entitled to open up to
> about 4100 files, assuming it manages to hit that many distinct tables/
> indexes during its run. You probably haven't got that many, but even
> several hundred files times a couple dozen backends would start pushing
> your (previous) kernel FD limit.
>
> So, at least on FreeBSD, we can't trust sysconf(_SC_OPEN_MAX) to tell us
> the number we need.
>
> An explicit parameter to the postmaster, setting the installation-wide
> open file count (with default maybe about 50 * MaxBackends) is starting
> to look like a good answer to me. Comments?
Okay, if I understand correctly, this would just result in more I/O as far
as having to close off "unused files" once that 50 limit is reached?
Would it be installation-wide, or per-process? Ie. if I have 100 as
maxbackends, and set it to 1000, could one backend suck up all 1000, or
would each max out at 10? (note. I'm running with 192 backends right now,
and have actually pushed it to run 188 simultaneously *grin*) ...
From | Date | Subject | |
---|---|---|---|
Next Message | Alfred Perlstein | 2000-08-28 19:00:07 | INHERITS doesn't offer enough functionality |
Previous Message | Tom Lane | 2000-08-28 18:30:05 | Re: Re: Too many open files (was Re: spinlock problems reported earlier) |