Tom Lane wrote:

Doug Y <[EMAIL PROTECTED]> writes:

Tom Lane wrote:

This might tell you something about how many concurrent backends you've
used, but nothing about how many shared buffers you need.

Thats strange, I know I've had more than 4 concurrent connections on that box... (I just checked and there were at least a dozen).

There is more than one per-backend semaphore per semaphore set, 16 per set if memory serves; so the ipcs evidence points to a maximum of between 49 and 64 concurrently active backends. It's not telling you a darn thing about appropriate shared_buffers settings, however.

A mirror DB with the same config also has the same basic output from
ipcs, except that it has times for 11 of the 17 arrays slots and most
of them are the time when we do our backup dump (which makes sense
that it would require more memory at that time.)

That doesn't follow either. I think you may have some bottleneck that causes client requests to pile up during a backup dump.

regards, tom lane

Ok, that explains the number of arrays... max_connections / 16.

Thanks... my mind works better when I can associate actual settings to effects like that. And I'm sure that performance takes a hit during out back-up dump. We're in the process of migrating them to dedicated mirror machine to run dumps/reports etc from crons so that it won't negatively affect the DB servers that get queries from the web applications.

Thanks again for clarification.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to