Martijn van Oosterhout wrote:
> IIRC you said you're on a 32-bit architecture? Which means any single
> process only has 4GB address space. Take off 1GB for the kernel, 1GB
> shared memory, 1 GB maintainence workmem and a collection of libraries,
> stack space and general memory fragmentation and I can absolutly
> beleive you've run into the limit of *address* space.
>
Should have been 64-bit, but a foul-up means it is running in 32-bit at
the moment.
> On a 64-bit machine it doesn't matter so much but on a 32-bit machine
> using 1GB for shared memory severely cuts the amount of auxilliary
> memory the server can use. Unless you've shown a measuable difference
> between 256MB and 1G shared memory, I'd say you're better off using the
> smaller amount so you can have higher maintainence work mem.
>
We're still in the process of testing and tuning (which takes its sweet
time), so at the moment I can not tell what benefits we have on the
different settings in practice. But I'll try to set shared buffers down
to 128-256 MB and the maintenance_work_memory to 512-1024MB when I next
have a time slot where I can run the server into the ground.
However, the problem also occurred with the shared_buffers limit set at
24 MB and maintenance_work_mem was at its default setting (16 MB?), so I
would be rather surprised if the problem did not repeat itself.
Regards,
Michael Akinde
Database Architect, met.no
