系统技术非业余研究

我在之前的博文提过Flashcache的cache是以set为单位管理的，每个set默认2M。 当单个set里面的脏页数量超过dirty_thresh_pct的时候，就会启动背景工作队列来把超过设置的脏页回写到后备磁盘去。 这里有别的同学对flashcache设计文档的翻译.

参看dirty_thresh_pct的文档解释：

dev.flashcache..dirty_thresh_pct = 20
Flashcache will attempt to keep the dirty blocks in each set
under this %. A lower dirty threshold increases disk writes,
and reduces block overwrites, but increases the blocks
available for read caching.

Flashcache之所以这样做的目的是当它在处理用户IO请求需要cache块的时候，保证马上可以拿的出来。因为读写的时候，如果需要的cache块不能满足的话，flashcache选择简单的绕过cache机制，直接走uncache io, 同时启动页面回收，一下子收回超过设置部分的页面，对性能有很大的损失。
特别是顺序写的时候，写一圈，再回绕在写的场合，性能特别差，就是这个原因。

那么如何保持一定量的可用cache块就很重要。通常cache数据都有冷热点，而且和时间很大关系。flashcache对冷热的判断是透过LRU类似的算法来判断的，这个是基于使用频度的维度。但是缺乏时间维度的判断。

新版本的flashcache引入了fallow_delay参数来解决这个问题，如果一个脏页超过fallow_delay秒，默认15分钟，都没有重新被访问到，那么数据就会被回写。 回写后，作为候选页面可以被新的cache重新利用。
Read more…

flashcache是facebook释放出来的开源的混合存储方案,用ssd来做cache提升IO设备的性能.很多硬件厂商也有类似的方案，比如说LSI raid卡. 但是这个方案是免费的软件方案，而且经过产品的考验，具体参见：
主页：https://github.com/facebook/flashcache
开源混合存储方案(Flashcache)： http://blog.yufeng.info/archives/1165
Flashcache新版重大变化： http://blog.yufeng.info/archives/1429

但是flashcache在使用中很多人会有个误区，导致性能很低。首先我们看下flashcache的设计背景和适用场景：

Introduction :
============
Flashcache is a write back block cache Linux kernel module. This
document describes the design, futures ideas, configuration, tuning of
the flashcache and concludes with a note covering the testability
hooks within flashcache and the testing that we did. Flashcache was
built primarily as a block cache for InnoDB but is general purpose and
can be used by other applications as well.

它是为数据库这样的应用的离散读写优化。如果你用在了顺序读写，就有非常大的性能问题。
那么为什么呢？我来分析下：

flashcache把内部的cache空间分成很多set, 是以set而不是整体为单位提供cache以及flush后备操作. 也就是说当一个set里面的dirty page达到一个预设的值的时候，就需要把这么dirty page 淘汰并且flush到后备设备去，以便腾出空间给更热的数据使用。
那么每个set多大呢？

To compute the target set for a given dbn
target set = (dbn / block size / set size) mod (number of sets)
Once we have the target set, linear probe within the set finds the
block. Note that a sequential range of disk blocks will all map onto a
given set.

set默认是 512*4k = 2M大小，也就是说如果你的这个set刚好是一个文件所在的块，而且每次这个文件都不停的顺序写，很快这个set都变成dirty, 那么flashcache就选择马上刷，这样加速效果就没有了。

幸好作者Mohan认识到了这个问题，提供了解决方案：

见https://github.com/facebook/flashcache/blob/master/doc/flashcache-sa-guide.txt 中的章节Tuning Sequential IO Skipping for better flashcache performance

引入了配置参数来解决这个问题：

dev.flashcache..skip_seq_thresh_kb:
Skip (don’t cache) sequential IO larger than this number (in kb).
0 (default) means cache all IO, both sequential and random.
Sequential IO can only be determined ‘after the fact’, so
this much of each sequential I/O will be cached before we skip
the rest. Does not affect searching for IO in an existing cache.

这样你可以把太大的顺序操作给过滤掉了，大大提升性能。

祝玩得开心！

facebook释出的flashcache见 https://github.com/facebook/flashcache， 也可以参考我之前写的 ppt 如何使用，或者参考我们的dba写的详细使用和配置，见 这里, 这里, 这里

7月20号，作者Mohan做了重大的改变，极大的提高了易用性。

1) Integration of all 3 caching modes (writeback, writethrough and
writearound) into the main flashcache module. Flashcache utilities
have been modified to add support for this as well.

2) Total Overhaul of the flashcache sysctls. Creates per-cache device
sysctl sets, so each individual cache device can be tuned differently.

之前的flashcache版本分成writeback和writethrough独立的版本，开发和维护倾向于writeback，导致很多特性writethrough跟不上，用起来就很不爽。现在好了。

随着磁盘越来越多，每个磁盘cache就非常的必要，因为每个cache的用途不同，需要做的策略也会很大不同。

这个版本更新非常重要。

祝玩得开心！