Greetings, Tom!
At 20.09.2000, 10:41, you wrote:
TL> "Alexey V. Borzov" <borz_off@rdw.ru> writes:
>> Nope, that's not the problem. I just checked and every DB has its own
>> PG_VERSION. Besides, _all_ of the databases are accessed on regular
>> basis (I'm speaking of a website), but the crashes occur only once in
>> a while (like, once a week)...
TL> I'm wondering if you could be running out of kernel filetable slots,
TL> so that the open of PG_VERSION is failing with ENFILE. (This would be
TL> the trouble spot just because it's the first file a new backend tries
TL> to open, and being a new backend it has no possible recovery tactic
TL> like closing other files. Once a backend is up and running it can
TL> usually survive ENFILE open failures by closing off other files.)
This MIGHT be problem. I'm not sure, as it wasn't me who compiled
the kernel for the box, but I'll look into it...
Well, last question then: I wasn't too specific, but the problem
with this crash is that not ONE SINGLE backend fails, but ALL OF
THEM AT ONCE: someone comes running to me and shouts 'our site is
down!', when I login and type 'ps eax | grep postgres' there
are no postgres processes in memory... Which is strange, as I
connect to Postgres from PHP, and use `persistent` connections, so
the backends which are in memory should have already read their
PG_VERSIONs...
Is it as it should be with ENFILE failure?
TL> If that's it, the solution is either to alter your kernel parameters to
TL> increase NFILE, or to reduce the allowed number of concurrent backends,
TL> or both.
Guess we should increase file slots, as reducing the number of
backends is definitely NOT an option.
--
Yours, Alexey V. Borzov