主页 / server / 问题 / 126413
Accepted
korkman
Asked: 2010-03-26 13:48:28 +0800 CST

限制 Linux 后台刷新（脏页）

  • 772

Linux 上的后台刷新发生在待处理的写入数据过多（可通过 /proc/sys/vm/dirty_background_ratio 调整）或挂起写入超时（/proc/sys/vm/dirty_expire_centisecs）时。除非达到另一个限制 (/proc/sys/vm/dirty_ratio)，否则可能会缓存更多写入的数据。进一步的写入将阻塞。

理论上，这应该创建一个后台进程写出脏页，而不会干扰其他进程。实际上，它确实会干扰任何进行非缓存读取或同步写入的进程。很糟糕。这是因为后台刷新实际上以 100% 的设备速度写入，此时任何其他设备请求都会被延迟（因为路上的所有队列和写入缓存都已填满）。

有没有办法限制刷新过程每秒执行的请求数量，或者以其他方式有效地优先考虑其他设备 I/O？

performance hard-drive linux

4 个回答

  1. Best Answer

    在使用 sysbench 进行大量基准测试后，我得出了以下结论：

    为了生存（在性能方面）一种情况

    • 一个邪恶的复制过程淹没了脏页
    • 并且存在硬件写入缓存（可能也没有）
    • 每秒同步读取或写入 (IOPS) 至关重要

    只需转储所有电梯、队列和脏页缓存。脏页的正确位置是在该硬件写入缓存的 RAM 中。

    尽可能低地调整dirty_ratio（或新的dirty_bytes），但要注意顺序吞吐量。在我的特定情况下，15 MB 是最佳的 ( echo 15000000 > dirty_bytes)。

    这更像是一种破解而不是解决方案，因为千兆字节的 RAM 现在仅用于读取缓存而不是脏缓存。为了让脏缓存在这种情况下正常工作，Linux 内核后台刷新器需要对底层设备接受请求的速度进行平均，并相应地调整后台刷新。不容易。

    用于比较的规格和基准：

    在将零写入磁盘时进行测试dd，sysbench 显示出巨大的成功，将 10 个线程 fsync 写入 16 kB 从 33 提高到 700 IOPS（空闲限制：1500 IOPS）和单线程从 8 到 400 IOPS。

    在没有负载的情况下，IOPS 不受影响（~1500）并且吞吐量略有下降（从 251 MB/s 到 216 MB/s）。

    dd称呼：

    dd if=/dev/zero of=dumpfile bs=1024 count=20485672

    对于 sysbench，test_file.0 准备好不稀疏：

    dd if=/dev/zero of=test_file.0 bs=1024 count=10485672

    sysbench 调用 10 个线程：

    sysbench --test=fileio --file-num=1 --num-threads=10 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run

    sysbench 调用一个线程：

    sysbench --test=fileio --file-num=1 --num-threads=1 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run

    较小的块大小显示出更大的数字。

    --file-block-size=4096 1 GB 脏字节：

    sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 30 Write, 30 Other = 60 Total
Read 0b  Written 120Kb  Total transferred 120Kb  (3.939Kb/sec)
      0.98 Requests/sec executed

Test execution summary:
      total time:                          30.4642s
      total number of events:              30
      total time taken by event execution: 30.4639
      per-request statistics:
           min:                                 94.36ms
           avg:                               1015.46ms
           max:                               1591.95ms
           approx.  95 percentile:            1591.30ms

Threads fairness:
      events (avg/stddev):           30.0000/0.00
      execution time (avg/stddev):   30.4639/0.00

    --file-block-size=4096 15 MB 脏字节：

    sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 13524 Write, 13524 Other = 27048 Total
Read 0b  Written 52.828Mb  Total transferred 52.828Mb  (1.7608Mb/sec)
    450.75 Requests/sec executed

Test execution summary:
      total time:                          30.0032s
      total number of events:              13524
      total time taken by event execution: 29.9921
      per-request statistics:
           min:                                  0.10ms
           avg:                                  2.22ms
           max:                                145.75ms
           approx.  95 percentile:              12.35ms

Threads fairness:
      events (avg/stddev):           13524.0000/0.00
      execution time (avg/stddev):   29.9921/0.00

    --file-block-size=4096 在空闲系统上具有 15 MB 的脏字节：

    sysbench 0.4.12：多线程系统评估基准

    Running the test with following options:
Number of threads: 1

Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  0 Read, 43801 Write, 43801 Other = 87602 Total
Read 0b  Written 171.1Mb  Total transferred 171.1Mb  (5.7032Mb/sec)
 1460.02 Requests/sec executed

Test execution summary:
      total time:                          30.0004s
      total number of events:              43801
      total time taken by event execution: 29.9662
      per-request statistics:
           min:                                  0.10ms
           avg:                                  0.68ms
           max:                                275.50ms
           approx.  95 percentile:               3.28ms

Threads fairness:
      events (avg/stddev):           43801.0000/0.00
      execution time (avg/stddev):   29.9662/0.00

    测试系统：

    • Adaptec 5405Z（即 512 MB 带保护的写缓存）
    • 英特尔至强 L5520
    • 6 GiB RAM @ 1066 MHz
    • 主板 Supermicro X8DTN（5520 芯片组）
    • 12 个希捷梭子鱼 1 TB 磁盘
      • Linux 软件 RAID 10 中的 10
    • 内核 2.6.32
    • 文件系统 xfs
    • Debian 不稳定

    总而言之，我现在确信这种配置在空闲、高负载甚至全负载情况下对于数据库流量会表现良好，否则这些流量会被顺序流量饿死。顺序吞吐量高于两个千兆链路无论如何都可以提供的吞吐量，因此减少一点也没问题。

    • 23

  2. 尽管调整内核参数可以解决问题，但实际上您的性能问题可能是 Adaptec 5405Z 控制器上的错误导致的，该错误已在 2012 年 2 月 1 日的固件更新中修复。发行说明说“修复了固件在高 I/O 压力期间可能挂起的问题。” 也许像您那样分散 I/O 足以防止触发此错误，但这只是一个猜测。

    以下是发行说明：http: //download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf

    即使您的特定情况并非如此，我认为这可能会使将来遇到此帖子的用户受益。我们在 dmesg 输出中看到了一些类似以下的消息，最终导致我们进行固件更新：

    aacraid: Host adapter abort request (0,0,0,0)
[above was repeated many times]
AAC: Host adapter BLINK LED 0x62
AAC0: adapter kernel panic'd 62.
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000000
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028

    以下是具有高 I/O 挂起修复的固件的发行说明中列出的 Adaptec RAID 控制器的型号：2045、2405、2405Q、2805、5085、5405、5405Z、5445、5445Z、5805、 5805Q、5805Z、5805ZQ、51245、51645、52445。

    • 3

  3. 包含“WBT”的内核：

    块层的改进，LWN.net

    通过写回节流，[块层] 尝试使用从 CoDel 网络调度程序借来的策略在没有过多 I/O 延迟的情况下获得最大性能。CoDel 跟踪观察到的网络数据包的最小延迟，如果超过阈值，它就会开始丢弃数据包。在 I/O 子系统中不赞成丢弃写入，但遵循类似的策略，即内核监控读取和写入的最小延迟，如果超过阈值，它开始降低后台回写量那正在做。此行为是在 4.10 中添加的；Axboe 表示已经看到了相当好的结果。

    WBT 不需要切换到新的 blk-mq 块层。也就是说，它不适用于 CFQ 或 BFQ I/O 调度程序。您可以将 WBT 与截止日期 / mq-deadline / noop / none 调度程序一起使用。我相信它也适用于新的“kyber”I/O 调度程序。

    除了缩放队列大小以控制延迟外，WBT 代码还将后台写回请求的数量限制为计算的队列限制的比例。

    运行时配置位于/sys/class/block/*/queue/wbt_lat_usec.

    要查找的构建配置选项是

    /boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT=y
/boot/config-4.20.8-200.fc29.x86_64:# CONFIG_BLK_WBT_SQ is not set
/boot/config-4.20.8-200.fc29.x86_64:CONFIG_BLK_WBT_MQ=y

    WBT 的作者 100% 确认了您的问题陈述 - 干得好 :-)。

    [PATCHSET] 块：缓冲写回限制

    从一开始，我们的后台缓冲写回就很糟糕。当我们进行后台缓冲写回时，它应该对前台活动几乎没有影响。这就是后台活动的定义......但据我所知，重缓冲写入器的行为并非如此。例如，如果我做这样的事情：

    $ dd if=/dev/zero of=foo bs=1M count=10k

    在我的笔记本电脑上，然后尝试启动 chrome，在缓冲写回完成之前它基本上不会启动。或者，对于面向服务器的工作负载，安装大 RPM（或类似的）会对数据库读取或同步写入产生不利影响。当这种情况发生时，我会让人们对我大喊大叫。

    可以在此处找到最近一些测试的结果：

    https://www.facebook.com/axboe/posts/10154074651342933

    有关补丁集的详细说明，请参阅以前的帖子。

    • 1

  4. /proc/meminfo 中 Dirty 的平均值是多少？这通常不应超过您的 /proc/sys/vm/dirty_ratio。在专用文件服务器上，我将dirty_ratio 设置为非常高的内存百分比（90），因为我永远不会超过它。你的dirty_ration太低了，当你击中它时，一切都崩溃了，提高它。

    • 0

相关问题