It's always annoyed me that the memory allocation for VMs is so static. If I allocate 16GB to a VM, it will fill these 16GB with its own filesystem cache, even when the host could make a better use of that memory (like using it for other VMs). There's virtio-balloon, but it has to be adjusted manually.
I slap $400 worth of memory in my workstation and I can load large datasets or piles of VMs without worrying that some mistake on my part is going to generate a huge bill on my part.
It's pretty common for me to run 60-80GB worth of VMs during the working day, so not using could is a pretty massive savings for me.
When not working on these tools, it was all just buffer cache for Linux while the actual processes were easily living in 8 GB or so. Even today, I'd comfortably live in 16 GB on a laptop, except once in a while miss the option to just do sloppy large allocations for a single task instead of worrying about chunking, IO, and careful access order.
Another reason was to enable me to hack with performance optimizations like mounting freqent read/write files into memory (tmpfs). Putting Chrome's cache there for example can be a noticeable increase in performance.
Another reason was just for the sheer badassness of having so much RAM
https://www.sqlite.org/appfileformat.html
> Conclusion
> SQLite is not the perfect application file format for every situation. But in many cases, SQLite is a far better choice than either a custom file format, a pile-of-files, or a wrapped pile-of-files. SQLite is a high-level, stable, reliable, cross-platform, widely-deployed, extensible, performant, accessible, concurrent file format. It deserves your consideration as the standard file format on your next application design.
This is why my 128Gb of ram is ECC. Long running programs are most at risk of memory errors.
OTOH, a 16TB per socket server would be quite a beast.
With 64GB, I mount /tmp and ~/.cache as tmpfs, which speeds up web browsing and code compilation, but with more capacity I would mount /var or even / into RAM.
Granted, NVMe drives are so fast these days that the improvement of using RAM for storage is likely not noticeable. Plus there's the problem of persistence. If you're OK with volatile storage for your use case, then this won't be an issue. Otherwise, you need some way to ensure data is persisted.
Perhaps these RAM advancements will make hybrid DRAM/NAND drives cheaper and more performant.
the neat thing is that these programs sync back periodically so the contents are preserved
this gives you both the speed of ram, eventual persistence, and reduced wear down on ssds
On environments with log shipping, having /var/log as a tmpfs makes a lot of sense.