Beginner article: Do we really need swap on modern systems?

szboardstretcher · 02-23-2017, 12:11 PM

Quote:

Do we really need swap on modern systems?

This question is asked here and there at LQ. A RedHat employee wrote up an excellent article/primer explaining why you need swap, what happens if you don't have swap, and how much swap you are likely to need.

Highly recommend reading this and sharing

https://www.redhat.com/en/about/blog...modern-systems

273 · 02-23-2017, 12:25 PM

I like that very much as an explanation of how much swap one may need. Succinct and clear.

suicidaleggroll · 02-23-2017, 04:47 PM

It seems like an alright rule of thumb, but as with most things, it really depends on the application. Personally, I find swap pretty pointless.

Under normal circumstances (no OOM condition), old pages can get moved to swap to open up ram for disk caching. That seems fine on the surface, but in reality it means that whenever you leave an application running but don't interface with it for a while (eg: leave your email program open on another workspace), it gets moved to swap and takes an eternity to start working again when you want it. I find that beyond irritating. If I don't want rapid access to a program anymore, I'll close it, I don't want the system moving it to swap to make room for more disk cache, because the user experience is destroyed as soon as I try to use that program again. You can use vm.swappiness to prevent that from happening, but then swap never gets used and just sits there doing nothing.

Which brings us to the extraordinary circumstances, running beyond your RAM limits. Swap gives you a buffer zone so if you run past the end of RAM, the data has a place to go without triggering the OOM killer, giving you time to figure out what's happening and fix it. As before, it sounds great on the surface, but in reality I have found that in every-single-case where a system has started running into swap, the system bogs down to the point that it's 100% unusable. It's busy swapping its data and can barely even keep up with mouse movements, much less actually clicking on anything, and you can forget SSHing into a system in this condition. This is usually caused by a runaway process, and will persist until swap is gone too and the OOM killer gets run anyway (or you don't run out, the system finally stabilizes after 20 minutes, you're able to log in, and YOU kill the offending process...same result). So since you can't actually do anything about the problem, all that ends up happening is the system basically locks up for a few minutes before the runaway process gets killed anyway. Why not just run the OOM killer when you first run out of RAM and bypass the 15+ minute lockup stage of the process?

Maybe it's just me, but I've always found swap to be more hassle than it's worth. I still use it, because something in the back of my head starts yelling at me whenever I try to setup a system without, but every time it actually ends up getting used, I'd rather the OOM killer just get called instead. It's going to happen regardless, might as well get it over with.

sundialsvcs · 02-23-2017, 05:39 PM

Whereas, I always want to give the operating system an "out."

Obviously, it depends on your situation, but I always like to give Linux the option to "swap out" things, either because they're inactive and taking up otherwise-valuable memory real-estate, or to make sure that it doesn't have to invoke

"the dreaded 'OOM [== Out Of Memory] Killer™'"

on anything that might actually be important.

I allocate swap space equal to at least twice the size of RAM, and then "fuhgeddaboudit." In normal operations, I find that swap is never used.

rokytnji · 02-23-2017, 06:08 PM

Depends on the user and what he/she needs to do I guess.

Code:

:~
$ sudo parted -l
Model: ATA KINGSTON SV300S3 (scsi)
Disk /dev/sda: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 2      1049kB  8390MB  8389MB  primary  ext3
 1      8390MB  60.0GB  51.6GB  primary  ext3


:~
$ inxi -m
Memory:    Using dmidecode: you must be root to run dmidecode
:~
$ su
Password: 
# inxi -m
Memory:    Used/Total: 425.2/8021.7MB
           Array-1 capacity: 8 GB devices: 2 EC: None
           Device-1: DIMM_A size: 4 GB speed: 1067 MHz type: DDR3
           Device-2: DIMM_B size: 4 GB speed: 1067 MHz type: DDR3
           Device-3: N/A size: N/A speed: N/A type: N/A
           Device-4: N/A size: N/A speed: N/A type: N/A
# exit
exit
:~
$inxi -f
CPU:       Dual core Intel Core i5 M 520 (-HT-MCP-) cache: 3072 KB 
           clock speeds: max: 2400 MHz 1: 1866 MHz 2: 1199 MHz 3: 1199 MHz 4: 1199 MHz
           CPU Flags: acpi aes aperfmperf apic arat arch_perfmon bts clflush cmov constant_tsc
           cx16 cx8 de ds_cpl dtes64 dtherm dts eagerfpu ept est flexpriority fpu fxsr ht ida
           lahf_lm lm mca mce mmx monitor msr mtrr nonstop_tsc nx pae pat pbe pcid pclmulqdq pdcm
           pebs pge pni popcnt pse pse36 rdtscp sep smx ss sse sse2 sse4_1 sse4_2 ssse3 tm tm2
           tpr_shadow tsc vme vmx vnmi vpid xtopology xtpr

replica9000 · 02-24-2017, 03:48 PM

I use swap, because I find Firefox and Chrome will usually eat lots of RAM if left open for a while. I've also found the slower I/O of swap has helped when I've had a script/process run away on me.

Pearlseattle · 02-24-2017, 05:48 PM

Quote:

Originally Posted by suicidaleggroll

It seems like an alright rule of thumb, but as with most things, it really depends on the application. Personally, I find swap pretty pointless.

Under normal circumstances (no OOM condition), old pages can get moved to swap to open up ram for disk caching. That seems fine on the surface, but in reality it means that whenever you leave an application running but don't interface with it for a while (eg: leave your email program open on another workspace), it gets moved to swap and takes an eternity to start working again when you want it. I find that beyond irritating. If I don't want rapid access to a program anymore, I'll close it, I don't want the system moving it to swap to make room for more disk cache, because the user experience is destroyed as soon as I try to use that program again. You can use vm.swappiness to prevent that from happening, but then swap never gets used and just sits there doing nothing.

Which brings us to the extraordinary circumstances, running beyond your RAM limits. Swap gives you a buffer zone so if you run past the end of RAM, the data has a place to go without triggering the OOM killer, giving you time to figure out what's happening and fix it. As before, it sounds great on the surface, but in reality I have found that in every-single-case where a system has started running into swap, the system bogs down to the point that it's 100% unusable. It's busy swapping its data and can barely even keep up with mouse movements, much less actually clicking on anything, and you can forget SSHing into a system in this condition. This is usually caused by a runaway process, and will persist until swap is gone too and the OOM killer gets run anyway (or you don't run out, the system finally stabilizes after 20 minutes, you're able to log in, and YOU kill the offending process...same result). So since you can't actually do anything about the problem, all that ends up happening is the system basically locks up for a few minutes before the runaway process gets killed anyway. Why not just run the OOM killer when you first run out of RAM and bypass the 15+ minute lockup stage of the process?

Maybe it's just me, but I've always found swap to be more hassle than it's worth. I still use it, because something in the back of my head starts yelling at me whenever I try to setup a system without, but every time it actually ends up getting used, I'd rather the OOM killer just get called instead. It's going to happen regardless, might as well get it over with.

I agree, at least partially.
Currently I find it especially annoying when running database ops (mariadb, cassandra, kudu, whatever) for days or weeks => at a certain point the system will start swapping to disk stuff and when I finally want to interact with it I'll have to wait for minutes until I see feedback from the console or the programs.

Personally, I question overall the "size" of the swap - does it make sense to have a swap of 1GB? 10GB? 100GB? Does it really have something to do with the available RAM? Shouldn't it have more something to do with the speed of the device on which the swap is hosted?

273 · 02-24-2017, 05:55 PM

I'm confused now. I thought that the article suggested that swap may not be needed but could be helpful in stopping memory leaks should they occur?

Personally, I have swap on my laptop because I may decide to "hibernate" and I have a swap file twice the size of the memory on my desktop "just in case" "because I can". If I had a system which actually used swap I'd change the WM or just go with a terminal -- a system using swap is a system that's declared itself dead.

jefro · 02-24-2017, 07:14 PM

I didn't get much out of it. Since it is a RH article it would mostly direct it's comments toward the support of that product.
" supported by Red Hat - just be sure the behaviour of such a system under memory pressure is what you want. In most environments, a bit of swap makes sense"

My problem here. "design your applications to regularly use swap," No where do I have data on any program easily that tells me if the creator(s) assumed swap.

At one time ram was terribly expensive. Linux users had to make do with very minimal specs. Creating swap was a way to overcome this. Ram still is a limit but hard drive space and now ssd space is really cheap. Who's going to miss a few gig's of space?

astrogeek · 02-24-2017, 07:20 PM

Yea, I agree with jefro, not much actual meat in the article for me.

I agree also with creating swap just to give the operating system an "out" should it be needed. It consumes no dynamic resources and very little disk space.

I always create a swap partition and then don't think much about it unless it shows up as being used in my normal monitoring... rarely.