Обсуждение: Suggested swap size for new db?
I'm planning to migrate our pg db to a new machine in the next couple of weeks. The current DB has 32 GB memory; the new one will have 96 GB. It's going to be Postgres 8.2.x (we're planning to upgrade to 8.4 as part of another project) running on CentOS 5.4 or 5.5. I know the old rule of thumb that your swap partition/disk should be equal to the physical memory, but when dealing with memory sizes greater than ~16 GB that starts to seem strange to me; and now with 96 GB of physical memory I'm starting to wonder if I'd be better off forgoing swap altogether for the new database. Are there any general suggestions for swap size for a Postgres DB? I assume that paging to/from disk is something that I'd want to avoid, especially in a database (which is why I'm debating disabling it altogether), but I'm not sure what the drawbacks would be (aside from the obvious one of there being less total memory available to the system). Oracle actually has some guidelines for swap space in the installation docs - http://www.dba-oracle.com/t_server_swap_space_allocation.htm - but I don't know of anything similar for Postgres, and I don't know if/how having such a huge amount of memory affects those guidelines. 3/4 of 8 GB is 6 GB of swap, which seems reasonable; 3/4 of 96 GB is 72 GB, which strikes me as excessive. Any thoughts would be appreciated. Thanks, Evan
On Sun, Nov 14, 2010 at 8:34 PM, Evan D. Hoffman <evandhoffman@gmail.com> wrote: > I'm planning to migrate our pg db to a new machine in the next couple > of weeks. The current DB has 32 GB memory; the new one will have 96 > GB. It's going to be Postgres 8.2.x (we're planning to upgrade to 8.4 > as part of another project) running on CentOS 5.4 or 5.5. I know the > old rule of thumb that your swap partition/disk should be equal to the > physical memory, but when dealing with memory sizes greater than ~16 > GB that starts to seem strange to me; and now with 96 GB of physical > memory I'm starting to wonder if I'd be better off forgoing swap > altogether for the new database. My servers were setup with something like 16G of swap on a machine with 128G ram. After runnig for about a month of heavy work, kswapd decided to start thrashing the system for no apparent reason, and would not stop. The fix was sudo swapoff -a. As soon as kswapd had swapped everything back in the server returned to normal. Now, swapoff -a is the last line in my /etc/rc.local on both machines. Running Ubuntu 10.04 64 bit btw. Note that at the time of this happening I had 90+G of kernel cache, and nothing NEEDED to be swapped out. the linux kernel, and virtual memory, with a machine with lots of memory, has some rather odd behaviour, and I don't really need swap on these machines.
On Sun, Nov 14, 2010 at 10:34 PM, Evan D. Hoffman <evandhoffman@gmail.com> wrote: > as part of another project) running on CentOS 5.4 or 5.5. I know the > old rule of thumb that your swap partition/disk should be equal to the > physical memory, but when dealing with memory sizes greater than ~16 > GB that starts to seem strange to me; and now with 96 GB of physical > memory I'm starting to wonder if I'd be better off forgoing swap > altogether for the new database. > The "old" rule is swap = 3x RAM. But those were the days of 64MB RAM being an extravagance. :) What I currently do is try to make swap = RAM + delta, so that if (when?) the machine panics I can get a useful kernel panic core dump. Given that boot drives are ~1TB these days, that's not a big deal. Machines running large RAM like that should never swap, else the point of having that much RAM is lost, and you probably needed more RAM to handle your workload than you anticipated.