2010/2/6 Jeff Ross <jross@openvistas.net>:
quoted text
> When I set shared_buffers to slightly less than 1/4 of my system ram I
> started this whole round of system panics and reports because in order to
> get postgres to start I then had to crank kern.shminfo.shmmax to 1GB, and
> that would trigger a panic very quickly under load.

Probably, it is because that big piece of _shared memory_ eat so much
pv_entries that some kernel map have been exhausted. So you receive
panic. You should supply detailed panic trace.

quoted text
> With postgres's shared_buffers set to 256M I have to set
kern.shminfo.shmmax
quoted text
> to 270M to get the server to start.  I then set postgres's
> effective_cache_size to 2816M (a value suggested by the pgtune program that
> equals 68% of my 4G ram) and set kern.bufcachepercent to 70.
> This drops my TPS in a select only test by about 25%, and it panicked with
> "panic: pmap_enter: no pv entries available" when scale hit 80.

Probably, it is because that big _buffer cache_ eat so much pv_entries
that some kernel map have been exhausted. So you receive panic. :-)
You should supply detailed panic trace. This case must be most
interesting. I think Bob Beck can say you much more if you do so.

quoted text
> This test run is going to take a while to either complete or panic so
here's
Again, you should supply detailed panic trace.

Can you try this. Setup options in assume that you have 1G ram. Set
shared buffers to something about 256M, and buffer cache to something
about 768M. And appropriate shmmax/shmall and effective_cache_size.
This will not set so much pressure to kernel map, so you should not
see so much panics.
Keep in mind, that postgres eat and uses memory in other places
(AFAIR, work buffers, temp buffers, etc). And there are one process
per connection(!), so that usage multiplies. And yes, they can eat
pv_entries too...
So, first, others 3G ram will not idle, it will be actively used by
(many) postgres processes. Second, try to reduce max connections to
reduce maximum of simultaneous postgres processes, so they not "eat
all pv_entries".
--
antonvm