Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 1 down vote accepted

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.

share|improve this answer
Has this been addressed in recent SSD controllers? – Xepoch Dec 17 '09 at 23:19
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. – Catherine MacInnes Dec 18 '09 at 22:08

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.

share|improve this answer

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.

share|improve this answer
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 '11 at 14:47

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.

share|improve this answer

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

share|improve this answer
While accurate, it doesn't actually answer the question. – sysadmin1138 Oct 3 '11 at 23:52
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 '12 at 18:04
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 '12 at 18:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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