I have a question about caching and how it impacts SSD’s…
Used to be the advice when installing GNU/Linux was to set up a cache partition - I’ve heard suggested sizes from the amount of RAM to twice the amount…. I’ve seen claims that this is less necessary these days, but I know I occasionally get error messages that some of my apps have been shut down by the system due to a lack of memory, and presumably having a cache would help with this.
However I’ve also seen discussion that because SSD’s have a large but finite number of write cycles, and that the flogging a cache gets can result in an SSD failing (possibly taking the /home directory with it…) Some claim it’s BS, but who knows? One could put the cache on a spinner, but that is SLOW compared to an SSD…
I know that these days you can get small (100-250GB) SSD’s for around USD$10 each. I’m wondering about the wisdom of putting one of those in as a dedicated cache drive? That way if the drive dies it doesn’t hurt the rest of the system, and it is no big deal to replace a $10 drive…
I don’t have an authoritative recommendation for you, but I can tell you what I do. I have 16 GB RAM and a 1 TB NVMe SSD in my laptop. I setup a swap file rather than a swap partition. I’ve even thought about using a secondary Optane drive that is sitting idle in my laptop as the location for the swap file. I’m just too lazy to do it.
It shouldn’t swap very often because it has 16 GB RAM. Each time I boot it should allocate a new swap file. That way the writes are spread around the “disk”. I think the controller on the SSD also spreads writes around regardless of using a dynamic swap file or a more static swap partition.
That is what I do.
My swap partition and data partition are on an HDD… I dont notice it being slow.
The small separate SSD is a good idea, but I would be happy with a small HDD.
My applications use a lot of ram… I have 64GB but sometimes it fills and the machine
swaps heavily… so I have 2 swap partitions on different HD’s… each is 200GB.
Putting them on 2 separate HDD’s spreads the load.
Most users would not need anything like that amount of swap space… they used to recommend 4x the amount of RAM., but today they say less than that.
It you use hibernation, you need at least 1x the amount of ram in swap space.
I dont use swap files, always a separate partition.
I think it is a good idea not to put swap on your main SSD.
I have some fairly active data files, and I keep those away from the main SSD too.
I don’t know about “cache” - that’s something the Linux kernel manages isn’t it (buff/cache)?
i.e. unused RAM is allocated to “cache” - when a PID needs more RAM the kernel scavenges it from cache…
On my desktop system - AMD Ryzen, I have 64 GB of RAM - I have swap disabled… I don’t run huge jobs - but when I’m e.g. re-encoding video or audio files - sometimes like a 4GB mkv - with two jobs (using ffmpeg / ffpb) - each with 4 threads - I don’t see my RAM get anywhere close to being exhausted…
Ubuntu defaults to a swapfile - I prefer the flexibility of this - vs dedicating a fixed size partition to swap…
I don’t dual boot - but if I did so - I guess a shared swap partition between different Linux installs would make sense - although you probably couldn’t share it with other O/S like BSD or god forbid MS Windows…
I have 4 GB swapfile on my ThinkPad running Ubuntu 24.04 - it has 16 GB RAM…
On both my desktop and Thinkpad - Linux is the only O/S and my desktop as a 2TB NVME SSD and the ThinkPad a 1 TB NVME SSD…
Thanks for the replies, sounds like it wouldn’t be a bad thing to do, though it might or might not do a lot of good….
I should also admit to a bit of a ‘brain fart’ in calling it cache - should have been talking about a swap partition. Fortunately it seems everyone picked up on my meaning though, so no harm done…
I only do one Linux on a machine, so sharing isn’t an issue for me, but I’ve heard that it can be risky to share a swap partition in some cases… The basic concern is if you have multiple Linux versions running at the same time (i.e. w/ virtual machines) they can stomp on each others data… Similarly if you have one hibernated in a swap that a different one is trying to use….
Never tried it so not sure how big a problem it is, probably won’t be either…
That is correct. I dont do that…my VM 's have their own swap inside the virtual disc.
I only run one hard installed linux at a time, so swap sharing with those is fine.
I dont hibernate.
Don’t be afraid of that. First I was scared by wearing too.
Now I use SSD’s in almost all of my systems for many years.
Nowadays I simply don’t care the wearing.
I had almost brand new SSD failing. I have a very old SSD with life left 0%, still works (though I don’t use it in a system, but it’s my Ventoy drive).
Any drive can fail at any time, and according to Mr. Murphy, it is going to fail in that moment, when it causes the most possible pain.
So have backups of your data, be prepared to the drives failing - it may happen any time.
As for the swap, I’m comfortable with a dedicated swap partition, so I do use one, and yes, on SSD.
I bought my Dell G3 laptop 2 and a half year ago. That time it wasn’t new, and it still has its original SSD. There’s no sign of the nvme to be dying or failing. Anyway, if it would, I’d just replace.
The thing about a swap partition is, if your system has a sufficient amount of RAM for your uses it will only be written to very occasionally, if at all. Pages are only pushed out to swap when the system is asked to allocate more memory than it has free. And once a page is swapped out, it won’t be swapped back in unless it’s needed.
It’s that second one that really saves you, because modern software (both applications and even daemons / background tools) are frequently guilty of glomming huge expanses of system memory for things they will never access again. And since pages are queued for transfer to disk based on how recently they’ve been used, over time as your system occasionally gets tight on memory, those allocated-but-unnecessary areas of RAM will be the ones that get moved to the swap volume. Once they’re offloaded, they can just stay there forever.
It’s a different story if your system is so memory-starved that it regularly ends up thrashing. (An ugly worst-case state where it begins madly shuffling pages back and forth between RAM and swap as it desperately tries to clear up enough space for new allocations. Once all of the unnecessary pages are offloaded, if there still isn’t enough room it will begin offloading parts of memory it does actually need, which it then almost immediately has to load back in to RAM because the owner of that memory now wants to access it.)
Thrashing can easily bring a system to its knees, which is why many distros now include an “OOM killer” as part of their install — that’s a daemon that watches for out-of-memory conditions, and begins hunting for the most memory-hogging processes it can terminate with extreme prejudice. Which is the only way to really get things back under control.
Thrashing CAN also be extremely hard on an SSD, for sure. But I’d argue that if you’re regularly experiencing thrashing, you shouldn’t be worried about your SSD’s wear meter. You should be worrying about upgrading your system’s RAM, because it’s clearly insufficient.
And once you have enough RAM, you won’t have to worry about your SSD anymore!
Now, my previous comment aside, you also shouldn’t be afraid to keep your swap space on a spinning-rust drive. Speed should NOT be a major concern when it comes to a swap volume, because if the system ever needs speedy access to the pages in swap you’ve already got bigger problems.
In the ideal (but also, ideally, normal) case, like I said the stuff that gets pushed to swap is dumped there precisely because it’s the least-accessed data in RAM. And with luck, most of it won’t ever be brought back into memory. You could swap to floppy disks and it wouldn’t severely impact the system’s responsiveness, until it started thrashing. (And then you’d be completely screwed.)
The OOM Killer is built right into the kernel. Need to admit, I have never seen that oom killer finish in a sane time, so I agree, having such a daemon helps to keep an overloaded system getting back to life - and avoid a reboot.
I use early oom for that purpose.
I know I am a strange user, but I regularly run a single program that uses all of my 64GB of ram and then thrashes. It is multiplying large matrices. I let it thrash, and it completes the job , but takes a long time.
I use 2 x 200Gb swap spaces on 2 separate HDD’s. It uses both.
My motherboard will not support any more ram.
I guess my only option is a new computer… 256Gb of ram should be enough, and faster ram (mine is ddr3) would help too.
I wrote the program. I am working on its memory requirements, but it is difficult… sparse matrix techniques do not help.
What I need is a technique for using an entire SSD as addressable ram… not swapping pages back and forth , but direct use as part of ram.
I have the admittedly bad habit of having LOTS of open browser tabs (as in hundreds) in the two browsers that I use, plus other things… My big machine w/ 48Gb of ram it isn’t much of an issue, as far as I can tell… My home machine only has 16Gb and it seems to go into ‘flog mode’ quite often judging by the drive light… It also frequently shuts down one of my browsers. I’m thinking that having a largish swap area on an SSD would allow it to swap out whichever browser I’m not using in a reasonable length of time… Given that small (~1-200GB) SSD’s are only about USD$10, I figure putting a swap partition on one of those drives is a cheap option, even if it dies semi-regularly… (of course I’d love to get a newer set of hardware to upgrade the machines but..)
(I also find it ironic that I now think of 100GB as small, considering my first PC was a 386 w/ 1Mb of RAM and a ‘huge’ 20Mb Seagate 251-1 MFM hard drive…)
That seems reasonable to me. It will swap inactive pages, not the whole browser at once.
Is there no way you can close one browser without losing its tabs? There might be a preferences setting for that.
Yeah. Which is worthless, because it isn’t the kernel’s job to monitor userspace. That’s what the init daemon is for. (Or, in any modern Linux system, what systemd is for.) The kernel’s monitoring alone never takes severe enough action to have any real benefit, which is why userspace OOM killers are becoming practical necessities, with the ballooning size of modern applications.
(Google Chrome alone, on my machine… I only have 9 tabs open right now, but between those and the extensions, Chrome is already sucking up ~4 GB of RAM. And two VSCode windows with one** open file** each are somehow even bigger than that.)
I was going to make that same comment. Just this past week I noticed that one of our instances didn’t have any swap file or swap partition allocated. I read up on the topic via Copilot and then I allocated a swap file and used a swappiness value of 10. This ranges from 0 to 100 where 0 is no swapping and 100 is aggressive swapping.
One thing you could consider is using some sort of cloud instance, like an AWS EC2 instance, but there are cheaper options. You could run it only for the length of time you need to do your calculation and then stop it or terminate it. It might not add up to much cost and your calculations might run tons faster depending on the instance type and size you use.
That sounds like a couple of my co-workers. Everyone works differently, but I typically have one or two tabs open. When I’m investigating something, I may open ten tabs, and that would be a lot, but then discard all of them when I’m done reading. I just don’t know how to rationalize dozens or hundreds of tabs.
I thought the kernel’s memory management module controlled ram usage, including swapping. I dont think the init process is involved, except maybe if a user process has to be stopped to save space. I have never observed a process being killed for that reason, it might be put to sleep maybe, or given a low priority?
The kernel’s vm manager is ultimately in control of all system memory (physical and virtual), and makes all decisions regarding allocations, swap queueing and migration, etc.
But it does that without a view of the userspace — IOW, it knows that a given page of memory has been allocated, how frequently it’s accessed, when it was accessed, etc. But it barely cares which process the memory belongs to, and it (meaning the vm manager) doesn’t know or care about things like which PIDs are part of the same process group, or which other PIDs are running as the same user, or anything like that. It has no “holistic” view of userspace, and that kind of information (as it turns out) is critical to making useful decisions about how to manage memory pressure, especially when the system starts to get into an unstable state.
Otherwise, if you’re the kernel trying to reduce memory pressure, maybe you kill off one of Chrome’s 30 active PIDs but leave the other 29 running. So now you’ve destabilized Chrome by terminating only part of its runtime. (And who knows how important that particular part happened to be?) Plus, because the application as a whole is still running, it immediately quickly re-launches that terminated process and makes a thrashing system thrash even harder.
Only the userspace process manager (or some delegate running under its purview) has sufficient altitude to observe the entirety of the system runtime state and make well-informed decisions about how to manage it, particularly in times of crisis. EarlyOOM is one such delegate. GitHub - rfjakob/earlyoom: earlyoom - Early OOM Daemon for Linux
