audin(a)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.