这是在SLES11 SP4上实现的测试.服务器有大量内存,允许它创建4GB的脏页.
> dd if=/dev/zero of=todel bs=1048576 count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied,3.72657 s,1.2 GB/s > dd if=/dev/zero of=zer oflag=sync bs=512 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied,16.6997 s,0.0 kB/s real 0m16.701s user 0m0.000s sys 0m0.000s > grep Dirty /proc/meminfo Dirty: 4199704 kB
这是我到目前为止的调查：
> SLES11 SP4(3.0.101-63)
>输入ext3(rw,nosuid,nodev,noatime)
>截止日程安排程序
>当时超过120GB的可回收内存
> dirty_ratio设置为40％,dirty_background_ratio设置为10％,30s到期,5s回写
这是我的问题：
>在测试结束时有4GB脏内存,我得出结论,在上面的测试中没有调用IO调度程序.是对的吗？
>因为在第一个dd完成后缓慢持续,我得出结论这个问题也与内核分配内存无关,或者在dd填充缓冲区时发生任何“写入时复制”(dd总是从同一个buf写入).
>有没有办法更深入地调查被阻止的内容？有趣的柜台值得关注吗？关于争用来源的任何想法？
>我们正在考虑减少dirty_ratio值,或者在同步模式下执行第一个dd.还有其他调查方向吗？将第一个dd同步存在缺点吗？我担心它将优先于其他执行异步写入的“legits”进程.
也可以看看
https://www.novell.com/support/kb/doc.php?id=7010287
limit linux background flush (dirty pages)
http://yarchive.net/comp/linux/dirty_limits.html
编辑：
在同一设备下有一个ext2文件系统.在这个设备上,根本没有冻结！唯一的性能影响发生在刷新脏页面期间,同步调用可能需要0.3秒,因此与我们使用ext3文件系统的情况相差甚远.
EDIT2：
在@Matthew Ife评论之后,我尝试在没有O_TRUNC的情况下进行同步写入打开文件,你不会相信结果！
> dd if=/dev/zero of=zer oflag=sync bs=512 count=1 > dd if=/dev/zero of=todel bs=1048576 count=4096 > dd if=/dev/zero of=zer oflag=sync bs=512 count=1 conv=notrunc 1+0 records in 1+0 records out 512 bytes (512 B) copied,0.000185427 s,2.8 MB/s
dd用参数打开文件：
open("zer",O_WRONLY|O_CREAT|O_TRUNC|O_SYNC,0666) = 3
使用notrunc选项进行更改,现在就是
open("zer",O_WRONLY|O_CREAT|O_SYNC,0666) = 3
并且同步写入立即完成！
好吧,它对我的用例并不完全令人满意(我在this fashion做了一个msync.但是我现在能够跟踪写和msync做的不同！
最后编辑：我简直不敢相信：
https://www.novell.com/support/kb/doc.php?id=7016100
事实上,在SLES11下,dd正在打开文件
open("zer",O_WRONLY|O_CREAT|O_DSYNC,0666) = 3
和O_DSYNC == O_SYNC！
结论：
对于我的用例,我应该使用
dd if=/dev/zero of=zer oflag=dsync bs=512 count=1 conv=notrunc
在SLES11下,运行oflag = sync将真正运行oflag = dsync,无论strace在说什么.
解决方法
>最初使用fallocate创建大文件然后写入其中.
>将dirty_background_bytes设置得低得多(比如1GiB)并使用CFQ作为调度程序.请注意,在此测试中,在大运行的中间运行小的可能是更好的表示.
因此,对于选项1,您可能会发现避免所有data = ordered语义,因为块分配已经(并且很快)完成,因为它是通过fallocate预分配的,并且在写入之前设置了元数据.测试是否真的如此,这将是有用的.我有一些信心,虽然它会提高性能.
对于选项2,您可以使用更多的ionice.截止日期明显快于CFQ,尽管CFQ尝试组织每个进程的IO,这样您就可以发现它可以让您通过每个进程更好地共享IO.
我在某处读到(现在找不到源代码)dirty_background_ratio将阻止针对单个提交过程的写入(有效地使大进程变慢)以防止一个进程使所有其他进程挨饿.
鉴于我现在可以找到的关于这种行为的信息很少,我对此工作的信心不足.
哦：我应该指出,fallocate依赖于范围,你需要使用ext4.
