On Sun, 20 Dec 2010, Luke S Crawford wrote: > Thanks for sharing your experience. > > [email protected] writes: >> in terms of a flash-based cache, I would have some concerns. >> >> another is the write speed, flash is relatively slow to write to, I >> would not expect it to have nearly the performance of battery-backed >> ram. > > This is true, but it's ridiculously better than disk, at least > the good SSDs are, especially for random writes, and when you cram > a bunch of virtuals on a server with four spindles, it's all random. > > From my point of view, more slower cache is much better than less > faster cache, just because my spinning disk is positively glacial > when it comes to random access.
having any cache drastically improves the write situation as the writes can be combined and written more efficantly. however, the way that the SSDs get these good write speeds is to be working ahead so that they have erased sectors to write to at all times, and they have multiple flash chips that they can access in parallel so that when one is eraseing you can write to the others (and unfortunantly, they also tend to cheat with volitile cache, somthing to watch out for) with only 1G of flash, you won't have these luxuries available, so there is a good chance that you will stall while writing to the cache. Having fast SSD drives behind a slow cache may actually be slower than accessing the fast drives directly (even if it would be faster than accessing rotating drives directly) also remember that while more cache is better, the benifits can taper off drastically. for write caches, once you get to where all your writes are accepted instantly (with the writes out to disk happening in the background), more write cache won't help. for read caches, once your working set is in the cache, more cache doesn't help much (and also remember that read caches are served perfectly well by OS ram caches, the big reason for having large write caches in the drive subsystem is to improve write speeds) >> the battery backed cache can also give you huge performance >> improvements for workloads that do fsyncs to make sure the data is >> safe on disk (mail servers and database servers commonly do this) as >> they usually are faster than doing the same I/O without a cache and >> without fsync. > > Yeah. persistent cache, for me, is the primary reason I'm thinking > of hardware raid. My understanding is that it can take a big bite out > of the read-calculate-write overhead of raid5, which gives me more > spindles for reads (caching doesn't help nearly as much for reads, when > you have a large amount of data being read, relative to cache size) > > My understanding is that persistent disk caches also help make random > writes a little bit more sequential. right, the same functionality creates the advantage in both cases, the application can write in small chunks, do it's fsync and be confident the data is safe, but thesewrites can then be combined and re-ordered on a larger time scale by the controller card. David Lang _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
