Re: [PERFORM] Tuning shared_buffers with ipcs ?

[Doug Y]

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