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

141–150 of 151 posts

Re: In defence of swap: common misconceptions

#141

Post by AstralStorm »

cdown wrote: post #123
mikekchar wrote: post #121

Earlier quoted context omitted.

Feel free to explain it to me. " Under no/low memory contention [...] Without swap: We cannot swap out rarely-used anonymous memory, as it’s locked in memory. While this may not immediately present as a problem, on some workloads this may represent a non-trivial drop in performance due to stale, anonymous pages taking space away from more important use." Now imagine that I have no memory contention. In other words I'…

I mean, it really depends on your application how non-trivial the performance improvement will be, but this statement isn't theoretical -- memory bound systems are a major case where being able to transfer out cold pages to swap can be a big win. In such systems, having optimal efficiency is all about having this balancing act between overall memory use without causing excessive memory pressure -- swap can not only r…

The real question is why those pages are being held in RAM. If they're needed, swapping them out will induce latency. I'd they're a leak or not needed, the application should be fixed to not allocate swathes of RAM it does not use.

Re: In defence of swap: common misconceptions

#142

Post by AstralStorm »

caf wrote: post #75
wahB4vai wrote: post #20

I'm a big fan of determinism and service uniformity. Having that rarely used and response time critical function/data/whatever swapped out increases service time variation at best and complicates all worst case response time calculations at least. I understand from the land of JIT compilers, garbage collectors, and oversubscribed everything that this is not much of a substantial concern as these features are already…

One of the article's points is that running without swap doesn't necessarily alleviate that. The rarely-used code pages of your rarely-used but response time critical daemon can just as easily be dropped from the page cache and have to be refaulted in from disk, and in fact that's more likely if there isn't swap available to stow the dirty anonymous pages from the cron daemon that wakes up once a day or whatever. The…

No they cannot. Code that is loaded into memory stays in memory when three is no swap. (Mlock is to prevent swap out or compression - major faults.) The exception would be lazy library loading. BIND_NOW is your friend in this case.

Essentially having no swap is similar to having everything mlocked - no major faults can happen except with mmapped files which will just use direct disk IO.

If you mean disk caches, when have you seen a multigigabyte executable?

Re: In defence of swap: common misconceptions

#143

Post by tmyklebu »

inamberclad wrote: post #102
phire wrote: post #88

Earlier quoted context omitted.

I actually did this on a old laptop, setup 200mb of swap for 4gb of ram. And it caused huge problems for me, would run out of swap while having plenty of free memory and then go cripplingly slow.

Set the swappiness lower.

It doesn't go lower than 0. Swapping can still hose your machine when swappiness is set to 0.

Re: In defence of swap: common misconceptions

#144

Post by sigstoat »

deathanatos wrote: post #90
sigstoat wrote: post #68

Earlier quoted context omitted.

the highest end NVMe SSDs can sustain those multi-gigabyte/second reads. https://smile.amazon.com/Samsung-950-PRO-Internal-MZ-V5P512B... for instance. not sure even they could pull off those speeds with random reads, though.

I think when most people say "hard disk", they usually mean rotating discs that use magnetism to store data. That is what I took tmyklebu's question to mean, since I too have never heard of a HDD reaching anywhere near 2 GB/s.

> I think when most people say "hard disk", they usually mean rotating discs that use magnetism to store data.

while i would personally avoid referring to an SSD as a "hard disk", i was attempting to interpret the original claim in the most charitable possible fashion, since it was utterly absurd if interpreted strictly.

Re: In defence of swap: common misconceptions

#145

Post by cdown »

AstralStorm wrote: post #141
cdown wrote: post #123

Earlier quoted context omitted.

I mean, it really depends on your application how non-trivial the performance improvement will be, but this statement isn't theoretical -- memory bound systems are a major case where being able to transfer out cold pages to swap can be a big win. In such systems, having optimal efficiency is all about having this balancing act between overall memory use without causing excessive memory pressure -- swap can not only r…

The real question is why those pages are being held in RAM. If they're needed, swapping them out will induce latency. I'd they're a leak or not needed, the application should be fixed to not allocate swathes of RAM it does not use.

There are some systems which are memory-bound by nature, not as a consequence of poor optimisation, so it's not really as simple as "needed" or "not needed". As a basic example, in compression, more memory available means that we can use a larger window size, and therefore have the opportunity to achieve higher compression ratios. There are plenty of more complex examples -- a lot of mapreduce work can be made more efficient with more memory available, for example.

Re: In defence of swap: common misconceptions

#146

Post by Symbiote »

IncRnd wrote: post #78
Symbiote wrote: post #58

Earlier quoted context omitted.

I have 4GiB swapfiles on the cluster nodes I manage, which have 512GiB RAM. It's hardly used, around 300MiB at present, probably things like the mail daemon. It's been useful to have a very slow node, which I can SSH into (after 10 minutes) and kill a chosen process, rather than a dead/OOMed node. But I think the difference is marginal, and perhaps 512MiB would have been a more appropriate size for the partition. (Sw…

We run without swap, and haven't noticed an issue. Did you see any practical benefit to running swap vs not?

Other than a couple of occasions where things have run slowly, giving me time to kill the process I choose, I've not noticed any benefit.

Picking a random machine, there is 600MB of swap used. "top" shows where about 50MB is used (Hadoop daemons, systemd bits) but I don't know what the rest is. I guess it could backfire, since logind is swapped out, and I might want to log in on the serial console if the machine is very busy.

Re: In defence of swap: common misconceptions

#147

Post by caf »

AstralStorm wrote: post #142
caf wrote: post #75

Earlier quoted context omitted.

One of the article's points is that running without swap doesn't necessarily alleviate that. The rarely-used code pages of your rarely-used but response time critical daemon can just as easily be dropped from the page cache and have to be refaulted in from disk, and in fact that's more likely if there isn't swap available to stow the dirty anonymous pages from the cron daemon that wakes up once a day or whatever. The…

No they cannot. Code that is loaded into memory stays in memory when three is no swap. (Mlock is to prevent swap out or compression - major faults.) The exception would be lazy library loading. BIND_NOW is your friend in this case. Essentially having no swap is similar to having everything mlocked - no major faults can happen except with mmapped files which will just use direct disk IO. If you mean disk caches, when…

Code that is loaded into memory stays in memory when three is no swap.

That is not true. In the normal case (absent debugging, JIT, self-modifying code etc), pages of executable code are clean, shared mappings so they do not interact with swap at all.

As clean, shared mappings they are eligible to be dropped from the page cache in the same way as other clean file mapped pages.

(Your executable code pages essentially are mmapped files. )

Re: In defence of swap: common misconceptions

#148

Post by AstralStorm »

cdown wrote: post #145
AstralStorm wrote: post #141

Earlier quoted context omitted.

The real question is why those pages are being held in RAM. If they're needed, swapping them out will induce latency. I'd they're a leak or not needed, the application should be fixed to not allocate swathes of RAM it does not use.

There are some systems which are memory-bound by nature, not as a consequence of poor optimisation, so it's not really as simple as "needed" or "not needed". As a basic example, in compression, more memory available means that we can use a larger window size, and therefore have the opportunity to achieve higher compression ratios. There are plenty of more complex examples -- a lot of mapreduce work can be made more e…

Indeed. None of the above are typically used (as in most of the time) on desktop systems where swap is the most problematic. As for compession, the only engine I know of that wants more than 128 MB of RAM is lrzip and other rzip derivatives.

Common offenders that bog down the system in swap for me as a developer are the web browser, JVM (Android) and electron based apps (messengers, two).

I would also like a source that substantiate the claim that using swap in map-reduce workloads actually helps. Or perhaps in database workloads. Or on any machine with relatively fixed workload.

Re: In defence of swap: common misconceptions

#149

Post by _ph_ »

AstralStorm wrote: post #139
_ph_ wrote: post #116

Earlier quoted context omitted.

The point being is, that a system doesn't have to misbehave to allocate more memory than the total RAM. And in those cases, there is a very good reason to have swap space, and swapping won't impact the performance of the system - rather the opposite.

Sure it does misbehave. The memory allocation failures should be handled properly and by that I mean not by crashing. Very few applications should require memory use beyond current free RAM. Especially not JVM, JavaScript VM, a web browser or even video player. Yet this silly heuristics in Linux lets it happen.

No, that is not correct. If you have any idle processes, their memory can safely swapped out without impacting performance. The user should not be forced to quit programs as soon as they become idle. Also, as described in the article, a program often allocates pages, which also become unused and can be swapped out. In an ideal world, a program would not allocate pages which become idle, but that happens with complex software (and often depends on the user interaction, and thus is not completely predictable). Swapping out idle pages is a very simple solution to make more memory available for the active processes.

Re: In defence of swap: common misconceptions

#150

Post by Doxin »

jcelerier wrote: post #124
mikekchar wrote: post #114

Earlier quoted context omitted.

I'm running on an 8GB Linux box without swap and never even come close to running out of memory. If I don't have any VMs running, then it's pretty unusual for me to use much more than 1-2 gigs. It's interesting... one of my colleagues has serious problems with performance because he keeps running out of memory -- and I don't think he's doing anything unusual. I think there is something wrong with some of the major di…

> I'm running on an 8GB Linux box without swap and never even come close to running out of memory. If I don't have any VMs running, then it's pretty unusual for me to use much more than 1-2 gigs. It's interesting... one of my colleagues has serious problems with performance because he keeps running out of memory -- and I don't think he's doing anything unusual. 64gb here and 40gb used. Firefox alone uses 2 gigs with…

Browsers have a tendency to use some percentage of available RAM. Firefox using 40gigs on a 64gig machine doesn't mean it'll try to use 40gigs on a 8gig machine.
Post reply on HN