问题的描述
本地镜像在不同物理机之间的传输，这里是通过自研的工具rsc，包含rsc_client和rsc_server。
rsc_server对收到的数据的处理不当，对IO可能产生不理想的结果：
（1）当Bps或者iops 过高时，可能使dm-0的util过高，甚至100%，影响上面虚机的IO；
（2）当传输过程中Bps过低时，会使得传输镜像过慢，影响效率，甚至导致创建虚机失败。
dm-0是物理机上的数据盘，有通过多快盘做raid。
以下在rsc_server的IO优化过程中，对不同方案测试结果的比较和分析。
无限速方案
测试环境为:
测试镜像： Windows 2008 64位 EN
镜像文件为qcow2格式，总共40G，实际占用空间20G。
宿主机:
172.27.162.108 –> 172.27.172.226（V3）
172.28.160.151–> 172.28.161.86（V4）
rsc_server端，接收到数据时，write到cache，就立刻返回。当cache满时，由系统一次性flush到磁盘。会使磁盘util=100%，持续10~20s，导致影响到客户虚机的IO性能。
限速方案
不同方案的测试和比较：
（1）对rsc_server进程的IO限速；
（2）对flush进程的IO限速；
（3）每次write时都sync；
（4）收到一定数量的包，调用fsync
其中对进程的限速是通过cgroup。
对rsc_server进程的IO限速
设置写到磁盘的限速参数：Bps=40MB/s，iops=15000。
把rsc_server进程PID添加到限速的tasks里。
无法限制住磁盘的IO。
原因：将cache刷到磁盘时，是由flush进程执行的，并不是rsc_server本身。所以考虑到将flush进程限速。
对flush 进程的IO限速
把flush进程的PID加入tasks里，可以限制磁盘到40M/s。
带来的问题，会影响所有通过flush来刷磁盘的操作：
1 宿主机的磁盘dm-0上，其他会将数据写到cahe就返回的操作都受到影响，如jbd2服务。jbd2(journaling block device 2)是ext4文件系统的服务，可以完成数据备份和恢复。
2 虚机内部
每次write时都sync
每次write都sync到磁盘，可以绕过从cache flush到磁盘的过程,也就不会产生flush过程中产生的IO过大的问题。
但每次write都sync带来写磁盘性能过低,落盘速度5M/s左右,util为98%~100%。
每收到10个64K的包，调用一次fsync
考虑到每次write都sync，影响磁盘性能，考虑减少sync的次数。改成累积到一定数量的包后，再调用fsync的方案。
172.27.162.108 –> 172.27.172.226( V3 )
172.28.160.151–> 172.28.161.86( V4 )
可以结果：
（1）写入IO得到很大提高，在30M/s ~ 200M/s之间，受宿主机影响较大；
（2）传输过程中，IO一直很稳定，util保持在40%或70%，也没有看到flush进程的出现，说明IO落地是由fsync执行；
使标准镜像（小于40G）都能在20分钟内传完，扩容过的镜像也不影响虚机的创建。
小插曲：
前面由于代码bug， 在每第10个64K包sync了n次。n为该64K的包，在跳过0的空洞后，拆成的小包的个数。sync次数过多导致IO性能过低，测试数据为6M/s左右。
172.28.160.151–> 172.28.161.86（V4）
strace的查看结果：
strace -T -p 21712( rsc_server进程PID ) -o test_rsc_server.txt
IO性能过低。
最终方案
“每收到10个64K的包，调用一次fsync”，由于宿主机的磁盘性能不同，不排除依然可能会有IO打满的情况，因为此时cache到磁盘的过程，是由rsc_server自己控制的，所以可以通过cgroup对rsc_server限速。
172.27.162.108 –> 172.27.172.226( V3 )
限速： rsc_server写入dm-0的 Bps=60M/s。
结果：rsc_server的落盘速度稳定在60M/s。
因此最终的方案是“fsync + cgroup限速”。