Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defence of swap: common misconceptions

chrisdown.name

Post reply on HN
Print view View original

21–30 of 151 posts

Re: In defence of swap: common misconceptions

#21

Post by w1kt0r »

loeg wrote: post #5

All of this boils down to "because buying more disk is cheaper than buying more RAM" and "avoid memory contention." The author discusses the situation as if the quantity of RAM is fixed and swap can be added (or not). But that isn't the only possibility — you can also add more RAM (it's just expensive). For the same number of GB of RAM+swap vs just RAM, there is no reason to prefer the option with swap.

Author assumes that you actually have some disk space to spare, which is not always the case.

I wonder if instead of using 4GB RAM, I'd setup 3GB RAM + 1GB swap space in RAM disk would result in much wiser OOM killer decisions (or stability).

Showing superiority of such configuration would probably convince all swap sceptics

Re: In defence of swap: common misconceptions

#22

Post by nicklaf »

bruce_one wrote: post #17
nicklaf wrote: post #6

I have an older Chromebook (c720), which is really quite memory starved (2GB RAM), and have experienced ChromeOS completely frying the SSD simply through prolonged tab-heavy swapping. Now, I've replaced the SSD and installed a non-Google Linux distro, and would like to limit the amount of swapping Firefox can do. I had been planning to simply use cgroups' memory features to limit the amount of memory consumed by Fire…

Setting the `swappiness` value might be of use to you. Setting a lower value (min is 0, default is 60 iirc, max is 100, so above half) reduces the likelihood of the kernel swapping. The lower the number the fuller ram needs to be before the kernel will start swapping. Hence a low number will mean that less swapping will happen, hence meaning less SSD wear.

Thanks, I should simply start with that.

Along with a hard limit set by cgroups so that browser tabs start being killed in order to stop the swap from being overwhelmed when memory is being used well beyond its capacity.

(I'd be interested to know if 'swappiness' already effectively implements the following system-wide, but here goes.)

Now that I think of it, it's not so much the quantity of disk storage being consumed by swap, so much as the number of write / delete transactions. One thus wonders if an approach in which the browser somehow favors a small number of tabs to keep in ram, and then dumps the state of the remaining tabs to disk, might be just as effective, but without worrying about the growth of swap. Then, when the user opens a tab that had been saved to disk, if we crudely assume that the memory consumed by open tabs are roughly comparable in memory use, then we can take care of the whole affair of 'swapping' in a single exchange between memory and disk, where we dump the state of the in-memory tab in order to make way for restoring the saved one.

(Or did I just reinvent what swappiness does already? From your description of swappiness, I'm inclined to guess the answer is no. This approach strikes me more akin to using the swapfile as a filesystem, and keeping just a small number of tabs paged into RAM.)

Re: In defence of swap: common misconceptions

#23

Post by Hello71 »

avar wrote: post #10

Even for those who understand this well, it's historically been really hard to coerce the Linux kernel into applying the right swap policies to your application. As the author notes much of this has been improve by cgroups, and there's always been big hammers like mlock(), even with those things it can be hard to prevent memory thrashing in extreme cases. I've seen swap disabled completely by people who understood ho…

Android has this last bit. as explained at https://www.youtube.com/watch?v=ikZ8_mRotT4&t=2145 (linked in the article) though, Linux does not have the facilities presently to determine when you have "10G left" in a way that applies across all system configurations.

Re: In defence of swap: common misconceptions

#25

Post by nicklaf »

tombrossman wrote: post #18
nicklaf wrote: post #6

I have an older Chromebook (c720), which is really quite memory starved (2GB RAM), and have experienced ChromeOS completely frying the SSD simply through prolonged tab-heavy swapping. Now, I've replaced the SSD and installed a non-Google Linux distro, and would like to limit the amount of swapping Firefox can do. I had been planning to simply use cgroups' memory features to limit the amount of memory consumed by Fire…

Firefox has a couple options which may help you get by. I can't guarantee these will fix everything but they are worth experimenting with. about:memory has various options, including a 'minimize memory usage' button and profiling tools. about:preferences has Privacy & Security > Cached Web Content > Override automatic cache management (select and set at 500MB, 1GB, or whatever works best).

Thank you, I had not known about about:memory. Interesting.

Re: In defence of swap: common misconceptions

#26

Post by slaymaker1907 »

I recently reenabled swap on my Windows machine due to frequent OOM, even with 16GB of RAM while playing Overwatch and browsing on Firefox. It seems like both of these programs allocate vast swaths of memory but then do not actually use that memory very heavily. After I turned swap back on, I did not notice any degradation in performance but my system stability skyrocketed.

Re: In defence of swap: common misconceptions

#27

Post by Anderkent »

whopa wrote: post #16
Anderkent wrote: post #13

Earlier quoted context omitted.

Every cloud provider I've worked with (okay, so AWS :P) gives you ephemeral local storage. Obvioulsy you don't swap onto a network drive.

Modern AWS instance types are EBS-only.

Huh. You're right; it seems for the newer instance types only c1.medium and m1.small get swap mounts. That seems like a mistake by aws; but I guess you can a M3 instead of a M5.

Re: In defence of swap: common misconceptions

#28

Post by CoconutPilot »

Swap was a great idea, but its time is gone. Swap doesn't make sense anymore, hard drives have not scaled and kept up with the improvements in RAM.

In the Pentium 1 era EDO RAM maxed out at 256MB/s and hard disk xfer was 10MB/s. Common RAM size was 16MB.

In today's era DDR4 maxes out at 32GB/s and hard disk xfer is 500 MB/s. Common RAM size is 16GB.

RAM xfer rate has grown is 320x. RAM capacity has grown 100x. Disk xfer rate has grown 50x.

Swap is no longer a useful tool.

Re: In defence of swap: common misconceptions

#29

Post by merb »

whopa wrote: post #8

This is an informative and well written article, but seems incomplete in this day and age. In public cloud environments, network attached storage is far more prevalent, so the swap story may be different there (I honestly don't know though). Since the author works at Facebook, he probably lacks experience in this regard.

well the default kubernetes install (kubeadm) will actually fail installing when having swap enabled. (even worse you can force him to ignore that, but kubelet would fail starting when swap is enabled).

Re: In defence of swap: common misconceptions

#30

Post by Dylan16807 »

CoconutPilot wrote: post #28

Swap was a great idea, but its time is gone. Swap doesn't make sense anymore, hard drives have not scaled and kept up with the improvements in RAM. In the Pentium 1 era EDO RAM maxed out at 256MB/s and hard disk xfer was 10MB/s. Common RAM size was 16MB. In today's era DDR4 maxes out at 32GB/s and hard disk xfer is 500 MB/s. Common RAM size is 16GB. RAM xfer rate has grown is 320x. RAM capacity has grown 100x. Disk x…

The purpose of swap is not running things out of it. The purpose is shoveling unused data out of memory. And for that it doesn't need to be particularly fast.

Swap has a lot less purpose in a world without memory leaks and extraneous functions. But in practice it's quite good at getting several gigabytes of unnecessary data out of the way, so ram can be used properly.

Swap, well-used, should only take up a few percent of the drive's bandwidth.

Post reply on HN