This question topically touched on this, but running on 64-bit Linux, I have a set of data caching JVMs as well as wanting a large web cache. Each cache today is configured to in gross fit in system memory (24GB) and persist to disk in LRU.

I'm curious however the performance if we **over-**allocated the cache processes and set up a SSD for a high-priority Linux swap. I'm wondering if the Linux kernel may be a little smarter/faster than our simplistic LRU process?

I'm concerned with over-allocating JVM heap and having heap pages swap by the kernel as to GC it would have to traverse said pages regularly.

5 Answers 5


I would suggest that SSDs are not good for a swap partition because their performance degrades over time with a large number or writes. This has to do with the fact that SSDs have a limited lifetime of writes, and therefore all kinds of tricks are played to minimize the number of times a single sector is rewritten.

  • Has this been addressed in recent SSD controllers?
    – Jé Queue
    Dec 17, 2009 at 23:19
  • 1
    Well the limited lifetime number of writes is a technical limitation, so I don't think it will go away completely. My understanding is that some controllers are much better than others on the performance, but my reading is somewhat out of date. Either way I would worry that the lifecycle of an SSD drive being used as swap space would be dissapointingly low. Dec 18, 2009 at 22:08
  • If you're expecting to write a lot to the cache you have to just underprovision the disk. For example, if you have 500 GB SSD, partition only 400 GB and never ever touch the last 100 GB. This allows drive wear leveling algorithm to have lots of extra space to deal with cell wearing. Enterprise versions of SSDs are basically the same thing with extra space enforced by the firmware. Jan 7, 2018 at 19:28

I'm afraid I'm going to disagree with the other responses. Yes, an SSD will only take something like 100K writes. For a 100GB drive, that means writing 10^16 bytes, or a steady stream of 100MB/s for 3000 years. Even if load balancing is so bad that you only get 1% of that...well. Also, performance degradation is taken care of with discard support, and modern drives don't degrade noticeably with use.

Yes, having more servers and RAM is even better, but while you get 100GBytes of SSD for maybe $200 these days, a server with 100GBytes of RAM will cost you about 100x that - just for the RAM. Power consumption will likely also be a factor of 100.

I think SSD would be great for swap, going from a handful of IOPS to tens of thousands is just what you need. But: I'm only opinionating here - I'd love to see real numbers based on SSD swapping.

Edit: to answer the OP, I agree the kernel is likely to be smarter than you (no offense! :-), so you could try to overallocate with your old rotating disk, too.

  • 1
    It could be that Linux's swap algorithm isn't tuned to SSDs, but on the other hand, it doesn't seem tuned to rotating media either - I get max 5% of available disk bandwidth (measured with iostat) when my server is thrashing... it looks like paging doesn't even try to do IO in larger chunks, but I suppose there is a good reason.
    – Ketil
    Feb 22, 2011 at 14:47

My guess is your performance won't scale with your cost and efforts. My gut tells me you may be MUCH better off with additional servers packed full of RAM if you can partition your data cache in a way that makes sense.

SSD has the benefit of near zero latency (comparatively) in retrieving data, but the various buses that connect it with main memory or the network are going to slow it down considerably.

  • It really depends on the size of the cache needed. If the size is less than around 120 GB then it probably makes sense to get enough RAM. Otherwise, a RAID of good quality SSDs may be a pretty good option. For example, software RAID of multiple M.2 drives will be pretty fast. Forget about using a single PCI-X card if you need lots of bandwidth. (Where lots of bandwidth is more than 2000 MB/s.) Jan 7, 2018 at 19:30

In addition to the two other very good responses, you may want to look at KSM as a way of combining identical data in ram. It was merged into linux for the 2.6.32 release.


Let's see now:

100GB x 100K writes = 10000TB which can be written to the SSD. 10000TB / 100MB/s = 10Ms until the SSD is worn out. 10Ms = 2778h = 116days Let's say we have a super controller which eliminates almost all hot spots, and we get 90 days...

90 days != 3000 years

  • 1
    While accurate, it doesn't actually answer the question.
    – sysadmin1138
    Oct 3, 2011 at 23:52
  • 1
    Not really accurate, cos' he forgot a zero, just think that he just said that he can write to disk 10 petabytes in 116 days with a throughput of just 100Megabytes a second. That would be 10000/116/24/60=0,06TB a minute. That's 1GB per second, not 100MB. So we are talking more about 1160 days (3 years). Also, today, SSDs are more like 1 to 5 million write cycles, that 100K data is more like from 10 years ago, so that would be like 10k to 50k days (27 to 137 years).
    – Andor
    Apr 1, 2012 at 18:04
  • 1
    But even with the old data (100K writes, 3 years), that's a more than enough life for a drive that's not going to contain critical data and you can just swap and power on again when it fails.
    – Andor
    Apr 1, 2012 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.