我们有进程对大文件进行后台写入.我们希望那些对其他流程的影响最小.

这是在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”进程.

也可以看看

编辑：

在同一设备下有一个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做的不同！

事实上,在SL​​ES11下,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在说什么.