在做进程安全监控的时候，拍脑袋决定的，如果发现一个进程在D状态时，即TASK_UNINTERRUPTIBLE（不可中断的睡眠状态），时间超过了8min，就将系统panic掉。恰好DB组做日志时，将整个log缓存到内存中，最后刷磁盘，结果系统就D状态了很长时间，自然panic了，中间涉及到Linux的缓存写回刷磁盘的一些机制和调优方法，写一下总结。

目前机制需要将脏页刷回到磁盘一般是以下情况：

  1. 脏页缓存占用的内存太多，内存空间不足；
  2. 脏页已经更改了很长时间，时间上已经到了临界值，需要及时刷新保持内存和磁盘上数据一致性；
  3. 外界命令强制刷新脏页到磁盘
  4. write写磁盘时检查状态刷新

内核使用pdflush线程刷新脏页到磁盘，pdflush线程个数在2和8之间，可以通过/proc/sys/vm/nr_pdflush_threads文件直接查看，具体策略机制参看源码函数__pdflush。

一、内核其他模块强制刷新

先说一下第一种和第三种情况：当内存空间不足或外界强制刷新的时候，脏页的刷新是通过调用wakeup_pdflush函数实现的，调用其函数的有do_sync、free_more_memory、try_to_free_pages。wakeup_pdflush的功能是通过background_writeout的函数实现的：

static void background_writeout(unsigned long _min_pages)
{
     long min_pages = _min_pages;
     struct writeback_control wbc = {
         .bdi = NULL,
         .sync_mode = WB_SYNC_NONE,
         .older_than_this = NULL,
         .nr_to_write = 0,
         .nonblocking = 1,
    };
 
    for ( ; ; ) {
         struct writeback_state wbs;
         long background_thresh;
         long dirty_thresh;
 
         get_dirty_limits(&wbs, &background_thresh, &dirty_thresh, NULL);
         if (wbs.nr_dirty + wbs.nr_unstable < background_thresh
             && min_pages <= 0)
             break;
         wbc.encountered_congestion = 0;
         wbc.nr_to_write = MAX_WRITEBACK_PAGES;
         wbc.pages_skipped = 0;
         writeback_inodes(&wbc);
         min_pages -= MAX_WRITEBACK_PAGES - wbc.nr_to_write;
         if (wbc.nr_to_write > 0 || wbc.pages_skipped > 0) {
              /* Wrote less than expected */
              blk_congestion_wait(WRITE, HZ/10);
              if (!wbc.encountered_congestion)
                  break;
         }
   }
}

background_writeout进到一个死循环里面，通过get_dirty_limits获取脏页开始刷新的临界值background_thresh，即为dirty_background_ratio的总内存页数百分比，可以通过proc接口/proc/sys/vm/dirty_background_ratio调整，一般默认为10。当脏页超过临界值时，调用writeback_inodes写MAX_WRITEBACK_PAGES（1024）个页，直到脏页比例低于临界值。

二、内核定时器启动刷新

内核在启动的时候在page_writeback_init初始化wb_timer定时器，超时时间是dirty_writeback_centisecs，单位是0.01秒，可以通过/proc/sys/vm/dirty_writeback_centisecs调节。wb_timer的触发函数是wb_timer_fn，最终是通过wb_kupdate实现。

static void wb_kupdate(unsigned long arg)
{
    sync_supers();
    get_writeback_state(&wbs);
    oldest_jif = jiffies - (dirty_expire_centisecs * HZ) / 100;
    start_jif = jiffies;
    next_jif = start_jif + (dirty_writeback_centisecs * HZ) / 100;
    nr_to_write = wbs.nr_dirty + wbs.nr_unstable +
    (inodes_stat.nr_inodes - inodes_stat.nr_unused);
    while (nr_to_write > 0) {
        wbc.encountered_congestion = 0;
        wbc.nr_to_write = MAX_WRITEBACK_PAGES;
        writeback_inodes(&wbc);
        if (wbc.nr_to_write > 0) {
            if (wbc.encountered_congestion)
                blk_congestion_wait(WRITE, HZ/10);
            else
                break; /* All the old data is written */
        }
        nr_to_write -= MAX_WRITEBACK_PAGES - wbc.nr_to_write;
    }
    if (time_before(next_jif, jiffies + HZ))
    next_jif = jiffies + HZ;
    if (dirty_writeback_centisecs)
    mod_timer(&wb_timer, next_jif);
 }

上面的代码没有拷贝全。内核首先将超级块信息刷新到文件系统上，然后获取oldest_jif作为wbc的参数只刷新已修改时间大于dirty_expire_centisecs的脏页，dirty_expire_centisecs参数可以通过/proc/sys/vm/dirty_expire_centisecs调整。

三、WRITE写文件刷新缓存

用户态使用WRITE函数写文件时也有可能要刷新脏页，generic_file_buffered_write函数会在将写的内存页标记为脏之后，根据条件刷新磁盘以平衡当前脏页比率，参看balance_dirty_pages_ratelimited函数：

void balance_dirty_pages_ratelimited(struct address_space *mapping)
{
    static DEFINE_PER_CPU(int, ratelimits) = 0;
    long ratelimit;
 
    ratelimit = ratelimit_pages;
    if (dirty_exceeded)
        ratelimit = 8;
 
    /*
     * Check the rate limiting. Also, we do not want to throttle real-time
     * tasks in balance_dirty_pages(). Period.
     */
    if (get_cpu_var(ratelimits)++ >= ratelimit) {
        __get_cpu_var(ratelimits) = 0;
        put_cpu_var(ratelimits);
        balance_dirty_pages(mapping);
        return;
    }
    put_cpu_var(ratelimits);
}
balance_dirty_pages_ratelimited函数通过ratelimit_pages调节刷新（调用balance_dirty_pages函数）的次数，每ratelimit_pages次调用才会刷新一次，具体刷新过程看balance_dirty_pages函数：

static void balance_dirty_pages(struct address_space *mapping)
{
    struct writeback_state wbs;
    long nr_reclaimable;
    long background_thresh;
    long dirty_thresh;
    unsigned long pages_written = 0;
    unsigned long write_chunk = sync_writeback_pages();
 
    struct backing_dev_info *bdi = mapping->backing_dev_info;
 
    for (;;) {
        struct writeback_control wbc = {
            .bdi        = bdi,
            .sync_mode  = WB_SYNC_NONE,
            .older_than_this = NULL,
            .nr_to_write    = write_chunk,
        };
 
        get_dirty_limits(&wbs, &background_thresh,
                    &dirty_thresh, mapping);
        nr_reclaimable = wbs.nr_dirty + wbs.nr_unstable;
        if (nr_reclaimable + wbs.nr_writeback <= dirty_thresh)
            break;
 
        if (!dirty_exceeded)
            dirty_exceeded = 1;
 
        /* Note: nr_reclaimable denotes nr_dirty + nr_unstable.
         * Unstable writes are a feature of certain networked
         * filesystems (i.e. NFS) in which data may have been
         * written to the server's write cache, but has not yet
         * been flushed to permanent storage.
         */
        if (nr_reclaimable) {
            writeback_inodes(&wbc);
            get_dirty_limits(&wbs, &background_thresh,
                    &dirty_thresh, mapping);
            nr_reclaimable = wbs.nr_dirty + wbs.nr_unstable;
            if (nr_reclaimable + wbs.nr_writeback <= dirty_thresh)
                break;
            pages_written += write_chunk - wbc.nr_to_write;
            if (pages_written >= write_chunk)
                break;      /* We've done our duty */
        }
        blk_congestion_wait(WRITE, HZ/10);
    }
 
    if (nr_reclaimable + wbs.nr_writeback <= dirty_thresh && dirty_exceeded)
        dirty_exceeded = 0;
 
    if (writeback_in_progress(bdi))
        return;     /* pdflush is already working this queue */
 
    /*
     * In laptop mode, we wait until hitting the higher threshold before
     * starting background writeout, and then write out all the way down
     * to the lower threshold.  So slow writers cause minimal disk activity.
     *
     * In normal mode, we start background writeout at the lower
     * background_thresh, to keep the amount of dirty memory low.
     */
    if ((laptop_mode && pages_written) ||
         (!laptop_mode && (nr_reclaimable > background_thresh)))
        pdflush_operation(background_writeout, 0);
}

函数走进一个死循环，通过get_dirty_limits获取dirty_background_ratio和dirty_ratio对应的内存页数值，当24行做判断，如果脏页大于dirty_thresh，则调用writeback_inodes开始刷缓存到磁盘，如果一次没有将脏页比率刷到dirty_ratio之下，则用blk_congestion_wait阻塞写，然后反复循环，直到比率降低到dirty_ratio；当比率低于dirty_ratio之后，但脏页比率大于dirty_background_ratio，则用pdflush_operation启用background_writeout，pdflush_operation是非阻塞函数，唤醒pdflush后直接返回，background_writeout在有pdflush调用。

如此可知：WRITE写的时候，缓存超过dirty_ratio，则会阻塞写操作，回刷脏页，直到缓存低于dirty_ratio；如果缓存高于background_writeout，则会在写操作时，唤醒pdflush进程刷脏页，不阻塞写操作。

四，问题总结

导致进程D状态大部分是因为第3种和第4种情况：有大量写操作，缓存由Linux系统管理，一旦脏页累计到一定程度，无论是继续写还是fsync刷新，都会使进程D住。

系统缓存相关的几个内核参数 (还有2个是指定bytes的，含义和ratio差不多)：

  1. /proc/sys/vm/dirty_background_ratio

该文件表示脏数据到达系统整体内存的百分比，此时触发pdflush进程把脏数据写回磁盘。

缺省设置：10

当用户调用write时，如果发现系统中的脏数据大于这阈值（或dirty_background_bytes ），会触发pdflush进程去写脏数据，但是用户的write调用会立即返回，无需等待。pdflush刷脏页的标准是让脏页降低到该阈值以下。

即使cgroup限制了用户进程的IOPS，也无所谓。2. /proc/sys/vm/dirty_expire_centisecs
该文件表示如果脏数据在内存中驻留时间超过该值，pdflush进程在下一次将把这些数据写回磁盘。

缺省设置：3000（1/100秒）3. /proc/sys/vm/dirty_ratio
该文件表示如果进程产生的脏数据到达系统整体内存的百分比，此时用户进程自行把脏数据写回磁盘。

缺省设置：40

当用户调用write时，如果发现系统中的脏数据大于这阈值（或dirty_bytes ），需要自己把脏数据刷回磁盘，降低到这个阈值以下才返回。

注意，此时如果cgroup限制了用户进程的IOPS，那就悲剧了。4. /proc/sys/vm/dirty_writeback_centisecs
该文件表示pdflush进程的唤醒间隔，周期性把超过dirty_expire_centisecs时间的脏数据写回磁盘。

缺省设置：500（1/100秒）

系统一般在下面三种情况下回写dirty页:1. 定时方式: 定时回写是基于这样的原则:/proc/sys/vm/dirty_writeback_centisecs的值表示多长时间会启动回写线程,由这个定时器启动的回写线程只回写在内存中为dirty时间超过(/proc/sys/vm/dirty_expire_centisecs / 100)秒的页(这个值默认是3000,也就是30秒),一般情况下dirty_writeback_centisecs的值是500,也就是5秒,所以默认情况下系统会5秒钟启动一次回写线程,把dirty时间超过30秒的页回写,要注意的是,这种方式启动的回写线程只回写超时的dirty页，不会回写没超时的dirty页,可以通过修改/proc中的这两个值，细节查看内核函数wb_kupdate。
2. 内存不足的时候: 这时并不将所有的dirty页写到磁盘,而是每次写大概1024个页面,直到空闲页面满足需求为止

3. 写操作时发现脏页超过一定比例:
当脏页占系统内存的比例超过/proc/sys/vm/dirty_background_ratio 的时候,write系统调用会唤醒pdflush回写dirty page,直到脏页比例低于/proc/sys/vm/dirty_background_ratio,但write系统调用不会被阻塞,立即返回.

当脏页占系统内存的比例超/proc/sys/vm/dirty_ratio的时候, write系统调用会被被阻塞,主动回写dirty page,直到脏页比例低于/proc/sys/vm/dirty_ratio

大数据量项目中的感触：

1 如果写入量巨大，不能期待系统缓存的自动回刷机制，最好采用应用层调用fsync或者sync。如果写入量大，甚至超过了系统缓存自动刷回的速度，就有可能导致系统的脏页率超过/proc/sys/vm/dirty_ratio， 这个时候，系统就会阻塞后续的写操作，这个阻塞有可能有5分钟之久，是我们应用无法承受的。因此，一种建议的方式是在应用层，在合适的时机调用fsync。

2 对于关键性能，最好不要依赖于系统cache的作用，如果对性能的要求比较高，最好在应用层自己实现cache，因为系统cache受外界影响太大，说不定什么时候，系统cache就被冲走了。

3 在logic设计中，发现一种需求使用系统cache实现非常合适，对于logic中的高楼贴，在应用层cache实现非常复杂，而其数量又非常少，这部分请求，可以依赖于系统cache发挥作用，但需要和应用层cache相配合，应用层cache可以cache住绝大部分的非高楼贴的请求，做到这一点后，整个程序对系统的io就主要在高楼贴这部分了。这种情况下，系统cache可以做到很好的效果。

磁盘预读：

关于预读摘录如下两段：

预读算法概要

1.顺序性检测

为了保证预读命中率，Linux只对顺序读(sequential read)进行预读。内核通过验证如下两个条件来判定一个read()是否顺序读：

◆这是文件被打开后的第一次读，并且读的是文件首部；

◆当前的读请求与前一（记录的）读请求在文件内的位置是连续的。

如果不满足上述顺序性条件，就判定为随机读。任何一个随机读都将终止当前的顺序序列，从而终止预读行为（而不是缩减预读大小）。注意这里的空间顺序性说的是文件内的偏移量，而不是指物理磁盘扇区的连续性。在这里Linux作了一种简化，它行之有效的基本前提是文件在磁盘上是基本连续存储的，没有严重的碎片化。

2.流水线预读

当程序在处理一批数据时，我们希望内核能在后台把下一批数据事先准备好，以便CPU和硬盘能流水线作业。Linux用两个预读窗口来跟踪当前顺序流的预读状态：current窗口和ahead窗口。其中的ahead窗口便是为流水线准备的：当应用程序工作在current窗口时，内核可能正在ahead窗口进行异步预读；一旦程序进入当前的ahead窗口，内核就会立即往前推进两个窗口，并在新的ahead窗口中启动预读I/O。

3.预读的大小

当确定了要进行顺序预读(sequential readahead)时，就需要决定合适的预读大小。预读粒度太小的话，达不到应有的性能提升效果；预读太多，又有可能载入太多程序不需要的页面，造成资源浪费。为此，Linux采用了一个快速的窗口扩张过程：

◆首次预读： readahead_size = read_size * 2; // or *4

预读窗口的初始值是读大小的二到四倍。这意味着在您的程序中使用较大的读粒度（比如32KB）可以稍稍提升I/O效率。

◆后续预读： readahead_size *= 2;

后续的预读窗口将逐次倍增，直到达到系统设定的最大预读大小，其缺省值是128KB。这个缺省值已经沿用至少五年了，在当前更快的硬盘和大容量内存面前，显得太过保守。

#blockdev –setra 2048 /dev/sda

当然预读大小不是越大越好，在很多情况下，也需要同时考虑I/O延迟问题。

其他细节：

1. pread 和pwrite
在多线程io操作中，对io的操作尽量使用pread和pwrite，否则，如果使用seek+write/read的方式的话，就需要在操作时加锁。这种加锁会直接造成多线程对同一个文件的操作在应用层就串行了。从而，多线程带来的好处就被消除了。

使用pread方式，多线程也比单线程要快很多，可见pread系统调用并没有因为同一个文件描述符而相互阻塞。pread和pwrite系统调用在底层实现中是如何做到相同的文件描述符而彼此之间不影响的？多线程比单线程的IOPS增高的主要因素在于调度算法。多线程做pread时相互未严重竞争是次要因素。

内核在执行pread的系统调用时并没有使用inode的信号量，避免了一个线程读文件时阻塞了其他线程；但是pwrite的系统调用会使用inode的信号量，多个线程会在inode信号量处产生竞争。pwrite仅将数据写入cache就返回，时间非常短，所以竞争不会很强烈。

2. 文件描述符需要多套吗？
在使用pread/pwrite的前提下，如果各个读写线程使用各自的一套文件描述符，是否还能进一步提升io性能？

每个文件描述符对应内核中一个叫file的对象，而每个文件对应一个叫inode的对象。假设某个进程两次打开同一个文件，得到了两个文件描述符，那么在内核中对应的是两个file对象，但只有一个inode对象。文件的读写操作最终由inode对象完成。所以，如果读写线程打开同一个文件的话，即使采用各自独占的文件描述符，但最终都会作用到同一个inode对象上。因此不会提升IO性能。