On Thu, Mar 22, 2012 at 10:02 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > On Thu, Mar 22, 2012 at 8:46 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >> large result sets) or cached structures like plpgsql plans. Once you >> go over 50% memory into shared, it's pretty easy to overcommit your >> server and burn yourself. Of course, 50% of 256GB server is a very >> different animal than 50% of a 4GB server. > > There's other issues you run into with large shared_buffers as well. > If you've got a large shared_buffers setting, but only regularly hit a > small subset of your db (say 32GB shared_buffers but only hit 4G or so > regularly in your app) then it's quite possible that older > shared_buffer segments will get swapped out because they're not being > used. Then, when the db goes to hit a page in shared_buffers, the OS > will have to swap it back in. What was supposed to make your db much > faster has now made it much slower. > > With Linux, the OS tends to swap out unused memory to make room for > file buffers. While you can change the swappiness settings to 0 to > slow it down, the OS will eventually swap out the least used segments > anyway. The only solution on large memory servers is often to just > turn off swap. Right -- but my take on that is that hacking the o/s to disable swap is dealing with symptoms of problem related to server misconfiguration. In particular it probably means shared_buffers is set too high...the o/s thinks it needs that memory more than you do and it may very well be right. The o/s doesn't swap for fun -- it does so when there are memory pressures and things are under stress. Generally, unused memory *should* get swapped out...of course there exceptions for example if you want zero latency access to an important table that is only touched once a day. But those cases are pretty rare. On systems with very fast storage (ssd), removing swap is even more unreasonable -- the penalty for going to storage is less and the server could use that memory for other things. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
