Hi!
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.
Exactly. But the sort-mem setting is the same on the other machine where
it's working flawlessly (and with 2 GB RAM/2GB swap, too). And isn't
"ReadRecord: record with zero length at someadress" an indication to
data corruption happening as well?
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.
Yes - and memory usage doesn't differ on the affected machine from the
machine we currently use (the one without the RAID). file-max (32768)
and shmmax (323380838) are both set to the same values on both machines.
Both of them run SuSE 7.3, installed with the same options. Both have
got four processors and 2 GB of RAM and 2 GB of swap. There's nothing
much running on these machines apart from PostgreSQL - and what is
running is running with the same configuration on both machines. I think
I can safely rule out any misconfiguration - I still think it's some
sort of hardware issue.
Regards,
Markus