| 1 |
On Sunday, 20 October 2019 00:35:56 BST Wol's lists wrote: |
| 2 |
|
| 3 |
> The original swap algorithm NEEDED twice ram as swap. And when Linus |
| 4 |
> ripped out all the "optimisation", the vanilla kernels only needed to |
| 5 |
> touch swap, and if they didn't have twice ram they would crash. |
| 6 |
|
| 7 |
Was this also the time when the default swappiness was set at 60? |
| 8 |
|
| 9 |
|
| 10 |
> At that point, the recommendation changed to "no swap is fine, twice or |
| 11 |
> more is fine, just don't have swap less than twice ram". |
| 12 |
|
| 13 |
Are you sure of this? At least on current kernels (I'm currently on 4.19.72- |
| 14 |
gentoo) the overcommit_accounting kernel mechanism using a heuristic over- |
| 15 |
commit memory handling is set at 0, which refuses wilder over commits, but |
| 16 |
allows more measured over commits to use swap space. |
| 17 |
|
| 18 |
$ cat /proc/sys/vm/overcommit_memory |
| 19 |
0 |
| 20 |
|
| 21 |
|
| 22 |
When set at 2, where no over-commit of memory is allowed, the mechanism will |
| 23 |
be informed by the overcommit_ratio by default set at 50%, to calculate how |
| 24 |
much RAM will be used by malloc. In this case, all swap will be used but only |
| 25 |
50% of RAM. |
| 26 |
|
| 27 |
$ cat /proc/sys/vm/overcommit_ratio |
| 28 |
50 |
| 29 |
|
| 30 |
|
| 31 |
Unless someone has purposefully set their overcommit_memory to 1, where |
| 32 |
potentially wild over commits are allowed and the risk of OOM increases, the |
| 33 |
kernel will not allow over-committing of RAM without checking how much RAM + |
| 34 |
swap is available. |
| 35 |
|
| 36 |
On my system with default overcommit_memory settings I have: |
| 37 |
|
| 38 |
$ free --kilo |
| 39 |
total used free shared buff/cache available |
| 40 |
Mem: 15975043 1359884 13849407 22528 765751 14126170 |
| 41 |
Swap: 17179865 0 17179865 |
| 42 |
|
| 43 |
but only 24577524 is reported as the commit limit: |
| 44 |
|
| 45 |
$ grep CommitLimit /proc/meminfo |
| 46 |
CommitLimit: 24577524 kB |
| 47 |
|
| 48 |
This is all swap and a percentage of RAM: |
| 49 |
|
| 50 |
24577524 - 17179865 = 7397659 of RAM, or 46.3%. |
| 51 |
|
| 52 |
From the above and without further experimentation I assume having a swap |
| 53 |
slightly larger than my RAM is more than adequate for a desktop, including |
| 54 |
hibernating on swap. |
| 55 |
|
| 56 |
|
| 57 |
> My personal rule is to take the motherboard's max ram, double it, and |
| 58 |
> create a swap partition that size on every disk. So my current desktop |
| 59 |
> system has 80GB of ram/swap - 4x4GB slots times 2 disk drives. And my |
| 60 |
> new system has 4x8GB so that'll be 160GB!!! HOWEVER - Richard Brown of |
| 61 |
> SUSE said that's dangerous - if somebody fork-bombs you it'll take a |
| 62 |
> long time to fill that much swap and regaining control of your system |
| 63 |
> could well be a big red switch job. |
| 64 |
> |
| 65 |
> Cheers, |
| 66 |
> Wol |
| 67 |
|
| 68 |
Each to their own, but I tend to think this huge amount of swap is probably |
| 69 |
excessive, unless you're running some scientific applications which require |
| 70 |
big over commits for their calculations. |
| 71 |
-- |
| 72 |
Regards, |
| 73 |
|
| 74 |
Mick |
Archives