Kevin Brown <kevin@sysexperts.com> writes:
> Tom Lane wrote:
>> However, it seems that the real problem here is that we are so far off
>> base about how many files we can open. I wonder whether we should stop
>> relying on sysconf() and instead try to make some direct probe of the
>> number of files we can open. I'm imagining repeatedly open() until
>> failure at some point during postmaster startup, and then save that
>> result as the number-of-openable-files limit.
> I strongly favor this method. In particular, the probe should probably
> be done after all shared libraries have been loaded and initialized.
I've now committed changes in 7.4 and HEAD branches to do this. Per the
recent tests, the code does not worry about tracking dlopen() calls, but
assumes that loading a shared library has no long-term impact on the
available number of FDs.
>> I also notice that OS X 10.3 seems to have working SysV semaphore
>> support. I am tempted to change template/darwin to use SysV where
>> available, instead of Posix semaphores. I wonder whether inheriting
>> 100-or-so open file descriptors every time we launch a backend isn't
>> in itself a nasty performance hit, quite aside from its effect on how
>> many normal files we can open.
> I imagine this could easily be tested.
In some simplistic tests, I couldn't find any clear difference in
backend startup time on Darwin with max_connections set to 5 vs 100.
So the idea that the extra FDs hurt us on backend startup seems wrong.
I am still a bit concerned about the possible impact of having an
unreasonably small number of available FDs, but against that we also
would have to determine whether Posix semaphores might be faster than
SysV semaphores on Darwin. I think I'll leave well enough alone unless
someone feels like running some benchmarks.
regards, tom lane
