Don Armstrong <d...@debian.org> writes: > On Tue, 09 Sep 2014, lee wrote: >> Why would 40GB be too much? > > It's probably too much, unless you have processes which allocate lots of > memory and then use it very infrequently or you have incredibly fast > disks.
It works fine, only can slow the system down very much --- which is the purpose. It doesn't matter much when a bit of the swap space is used in terms of performance, that's "normal operation". But when some process(es) suddenly require lots of memory, I *really* prefer it becoming slow over it going down or becoming unstable. When you have "incredibly fast disks", you want to have only a relatively small part of your swap on those (like 8GB, for example) because the swap space on them can also fill up "incredibly fast". I would put the remaining 56GB on slow disks. (You can set priorities for swap partitions. First use the fast ones, then the slow ones. That does work fine.) >> I have 8/64 so I can use swapping to slow down the downfall of the >> system. > > The system won't go down unless you've disabled the OOM killer or > discovered a kernel bug. [Granted, processes will be killed off, but > that's to be expected.] Yes, and the killing can result in the system becoming unstable, or it might go down. "Go down" can have various meanings. When you run a server and a server process (like an MTA or an IMAP or web server) is killed because the system runs out of memory, the server is effectively down. It may not be unstable (though I consider a system without an operational MTA as non-functional), yet you never know what process will be killed. You could have ZFS with fuse, and what prevents such processes from being killed? I have seen it happen, long ago, that my system became unstable because it ran out of memory. > Generally speaking, you want enough swap so that infrequently used > memory can be offloaded to disk, but not so much swap that your > computer stops being responsive when you begin to run out of free > memory. It doesn't work that way. When your system just begins to run out of memory, it will swap out a bit as needed, no matter how much swap space you have, unless you have none. What is swapped out at that point may be infrequently used data. The system doesn't swap out more than otherwise when you have more swap space (see below). At some point, you either still have enough swap, or the system may go down. With 64GB of swap (see below), it's less likely to run out, and before it does, it becomes so slow that I will notice (when I'm using it) and have a chance to do something about it before it does run out. When I'm not using it, the 64GB may yet be enough for the system not to run out of memory. Doing something may take a while because the system will be slow when it swaps out lots of data. It's nice to have a cushion because it may (will) continue to fill the swap space while I'm trying to do something. (I start to notice when something between 7 and 12GB are actually used in total. My disks are rather slow.) [~] uptime ; free -m 01:30:55 up 5 days, 6:00, 3 users, load average: 0.04, 0.04, 0.09 total used free shared buffers cached Mem: 7982 5303 2679 0 82 3790 -/+ buffers/cache: 1430 6552 Swap: 65535 67 65468 This is from a VM, and you can see how it kinda gets tight already: root@gulltop:~# uptime ; free 01:31:24 up 4 days, 4:38, 2 users, load average: 0.06, 0.03, 0.05 total used free shared buffers cached Mem: 2050596 2003600 46996 0 60084 855408 -/+ buffers/cache: 1088108 962488 Swap: 975860 2604 973256 root@gulltop:~# The system and all the VMs are on rather small disks, or they would have more swap (the server should have more RAM, too). Those are 2x15k RPM SAS disks in a hardware RAID-1, which is fast and thus does fill fast. The web browser (seamonkey) running on this VM (display is on my desktop) just eats ridiculous amounts of memory. Yet it takes only 1/2 second to start :)) Open too many tabs, and the VM --- or least the web browser --- will go down --- *before you notice*. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zje711v0....@yun.yagibdah.de