On Tue, 6 Aug 2002, Markus Wollny wrote:
> Hi!
>
> Thank you - that clears up my confusion about swap available being
> smaller than the swap partition :)
> sort_mem is set to 65534, following the recommendation about setting it
> to 2-4% of available physical RAM.
> If shmmax were the issue, the postmaster would refuse to start up - so
> this isn't it either; I took care of both filemax and shmmax - and the
> very same configuration is working on our fallback-machine under the
> same environment (application, load, database, data) without any
> trouble.
>
> I upgraded the kernel of the machine to 2.4.16 - there are no RPMs for
> and not very much experience with SuSE 7.3 and 2.4.19 yet and I'm quite
> cautious when it comes to the kernel; I do know how to configure and
> compile the kernel, but on a production machine I leave this to SuSE :)
>
> Taking into account that this thing does work when run on a different
> machine, I think bad RAM is my best bet. But there's only one way to
> know for shure - I'll go and find out tomorrow.
Well, I'd first lower the sort mem myself. 64 Megs is pretty big, even on
a box with gigs of ram. But more importantly, since the kernel looks like
it was killing the processes, I would NOT tend to think of this as being a
bad RAM issue, but a memory starvation issue. Bad memory results in
database corruption, things like that. It seems like yours is just
suddenly shutting down, and coming right back up.
Have you checked the available memory when the server is having these
problems? I would tend to think it may be a configuration issue. shmmax
doesn't just affect startup. If the sort_mem is coming out of the
shared memory then the limit there could affect the ability of a child to
allocate memory when sorting, which would result in the problems you're
seeing where a backend dies while trying but failing to allocate memory.
Someone correct me if the sort mem doesn't come under the heading of
shared memory. It would NOT be the first time that's happened. :-)