限制linux后台刷新（脏页）

如果写入的数据过多（通过/ proc / sys / vm / dirty_background_ratio进行调整）或挂起写入超时（/ proc / sys / vm / dirty_expire_centisecs），则会在linux中进行背景刷新。除非有另一个限制（/ proc / sys / vm / dirty_ratio），否则可能会caching更多的写入数据。进一步的写入会阻止。

理论上讲，这应该创build一个后台进程，写出脏页面而不会干扰其他进程。在实践中，它会干扰任何进行非caching读取或同步写入的进程。厉害。这是因为后台刷新实际上是以100％的设备速度写入的，并且此时的任何其他设备请求将被延迟（因为路上的所有队列和写入caching都已被填充）。

有没有办法限制冲洗过程执行的每秒请求数量，否则有效地优先处理其他设备I / O？

经过与sysbench的许多基准testing，我得出这样的结论：

为了生存（performance明智）的情况下

一个邪恶的复制过程泛滥脏页
和硬件写caching存在（可能也没有）
而每秒同步读取或写入（IOPS）是至关重要的

只需转储所有的电梯，队列和脏页面caching。 脏页面的正确位置在该硬件写caching的RAM中。

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

这比解决scheme更糟糕，因为千兆字节的RAM现在只用于读取caching而不是脏caching。为了使脏caching在这种情况下很好地工作，Linux内核的后台刷新器需要平均以什么速度下层设备接受请求并相应地调整背景刷新。不容易。

用于比较的规格和基准：

经过dd'ing零磁盘testing，sysbench显示了巨大的成功 ，提升了10个线程的fsync在33到700 IOPS（空闲限制：1500 IOPS）和单线程从8到400 IOPS 16 kb的写入。

空载时，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调用1个线程：

 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 dirty_bytes：

 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

– 文件块大小= 4096与15 MB dirty_bytes：

 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

– 空闲系统上的文件块大小= 4096，有15 MB dirty_bytes：

sysbench 0.4.12：multithreading系统评测基准

 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

testing系统：

Adaptec 5405Z（这是512 MB的写caching保护）
英特尔至强L5520
6个GiB RAM @ 1066 MHz
主板Supermicro X8DTN（5520芯片组）
12希捷梭鱼1 TB磁盘
- 10在Linux软件突袭10
内核2.6.32
文件系统xfs
debian不稳定

总而言之，我现在确信，这种configuration在空闲，高负载甚至满负载的情况下，对于否则会被顺序stream量限制的数据库stream量，将会performance良好。顺序吞吐量高于两个千兆链路可以交付，所以没有问题，减less一点。

感谢您阅读和评论！

尽pipe调整内核参数可以避免这个问题，但实际上，性能问题可能是由于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， 5805Q，5805Z，5805ZQ，51245,51645,52445。

你在/ proc / meminfo中脏的平均值是多less？这通常不应该超过你的/ proc / sys / vm / dirty_ratio。在专用的文件服务器上，我把dirty_ratio设置为非常高的内存百分比（90），因为我永远不会超过它。你的肮脏感太低了，当你打的时候，所有的东西都会扯出来，举起来。