audin@okb-1.org wrote:
Ramdisks have no place beyond MS/PC-DOS, Knoppix, and OS install floppies. Why dedicate a gob of memory to a ram disk when you can achieve similar performance with the OS's caching facility while also allowing that memory to be conscripted for other uses should the need arise?
Caching algorithms tend to use a least recently used algorithm. When larger blocks of data are read from storage, the least recently read fine grained data is flushed.
The cost of reading fine grained data is very high. This cost can be avoided by keeping fine grained data in ramdisk, unless some prioritising can be set up to avoid the fine grained data being flushed for much longer than the coarse grained data.
A 1Mb piece of data may take Seek + Transfer = I/O cost 8.5ms + 20ms = 28ms
a 10K piece of data may take 8.5ms + 0.2ms = 8.7ms
We can calculate this in terms of I/O blocking cost per given data size: 10k chunks (fine grained - eg article database) cost 870ms/Mb 1Mb Chunks (Coarse Grained- eg program code, media files) cost 28ms/Mb
Fine grained data is far more I/O costly than coarse grained data.
Is there another way to prioritise the fine grained data other than ramdisk? If so, this may be the key to a far more efficient system.
Flash devices have rather serious write-cycle limitations. As mysql does not do anything to avoid hot spots, such a setup would likely not last long.
We would need to know how hot the hotspots tend to be before implementing such a solution. Typical r/w on modern flash tend to be 1m-10m cycles.