前一阵子公司一部门有人叫帮忙调查,说他们write系统调用基本上是个位数微秒就返回,或者说几十us,但偶尔出现几次write系统调用达到几百毫秒和情况。大家都知道,通过vfs进行write,都是写写到page cache中,然后内核线程再定期同步到磁盘。写到内存应该是很快的才对。刚开始,我做了许多设想,1)磁盘IO太重,内存中的脏数据达到一定比率后write必须同步写到磁盘;2)那些耗时长的write是使用direct io,绕过了page cache;3、刚刚好write一个page时,read也在读同一page,那个page被lock了,write要等它。后来每一种假设又都被自己推翻了。以下是通过vfs进行write系统调用的图:

前几天,使用systemtap进行一步步的定位,最后把可疑的点锁定在__block_write_begin这个函数中(fs/buffer.c)。

先说明下这个函数是干什么的。generic_perform_write函数是把数据写入磁盘的主要处理函数。它先调用address_space_operations. write_begin(其中会调用我们上文提到的__block_write_begin函数),接下来把数据拷贝到上一步分配出来的page中,最后调用address_space_operations.write_end。上面所说的write_begin和write_end会具体根据不同的file system调用不同的函数,拿ext4来说,它的函数如下(有dellay allocation的话):

static const struct address_space_operations ext4_da_aops = {

         .readpage                 = ext4_readpage,

         .readpages               = ext4_readpages,

         .writepage                = ext4_writepage,

         .writepages              = ext4_writepages,

         .write_begin            = ext4_da_write_begin,

         .write_end                = ext4_da_write_end,

         .bmap                        = ext4_bmap,

         .invalidatepage                = ext4_da_invalidatepage,

         .releasepage            = ext4_releasepage,

         .direct_IO                 = ext4_direct_IO,

         .migratepage           = buffer_migrate_page,

         .is_partially_uptodate  = block_is_partially_uptodate,

         .error_remove_page      = generic_error_remove_page,

};

可以看到,ext4的write_begin是ext4_da_write_begin。Ext4_da_write_begin会先分配一个页框,然后调用__block_write_begin分配缓冲区(为什么要分配缓冲区这里就不说明了)。那么,__block_write_begin分配缓冲区而已,为什么有时候要耗时那么长呢?先看看代码:

int __block_write_begin(struct page *page, loff_t pos, unsigned len,

get_block_t *get_block)

{

  ......

  if (!buffer_uptodate(bh) && !buffer_delay(bh) &&

    !buffer_unwritten(bh) &&

     (block_start < from || block_end > to)) {

  ll_rw_block(READ, 1, &bh); //这里指定read操作,提交BIO

  *wait_bh++=bh;

  }

......

/*

* If we issued read requests - let them complete.

*/

  while(wait_bh > wait) { //这里等待io操作完成

  wait_on_buffer(*--wait_bh);

  if (!buffer_uptodate(*wait_bh))

  err = -EIO;

  }

}

  

write的基本单位是块(由磁盘文件系统定义,默认为4K)。这样的话,page cache中一个page(刚好也为4K)刚好就是一个块。比如说write的地址是512,长度是20,page cache就分配了一个能写 0~4095的页page frame,这个page frame刚好对应一个磁盘块,假如把要write的数据拷贝到这个page frame的 512~531,这样的话0~511和532~4095是空的。但是下次write back的时候会把整块数据都写入磁盘,所以需要把这一整块的数据都先从磁盘中读出来,写入page cache中,以防止0~511和532~4095被误写。这个读操作应该就是耗时长的原因了。

write 系统调用耗时长的原因的更多相关文章

  1. redis 间断性耗时长问题解决

    我发现开发项目用的redis 隔一两分钟就出现 耗时问题,长达五秒.一开始以为是 redis 服务器不稳定,但运维测试发现redis稳定的,在高并发下最大耗时也就只有100毫秒左右,怎么也不可能达到5 ...

  2. [WCF] - 访问任意方法耗时长问题之解决

    问题 访问 WCF 任意方法耗时都很长(15s+) 原因 当执行语句 log4net.Config.XmlConfigurator.Configure(); 时需要连接到 log4net 对应的数据库 ...

  3. Microsoft Dynamics CRM 4.0导入组织(Import Organization)时间过长的原因总结

    952934    How to move the Microsoft Dynamics CRM 4.0 deployment http://support.microsoft.com/default ...

  4. SSH远程连接连接其他主机,等待时间过长的原因。

    ssh远程连接登录到其他主机,输入登录用户名,等待时间很长时间,然后才出现输入密码的提示.导致这样时间过长,太慢了的原因有两个.(1)当使用ssh远程登录到某个IP时,这个IP的主机系统会读取/etc ...

  5. wrHDL编译中软核代码初始化及编译耗时长的问题

    问题的提出整个WR的ISE工程比较大,编译时间很长,导致开发效率低.通过分析发现,ISE在综合的时候大量的时间都花在了初始化DPRAM上.调研发现Xilinx提供了BMM文件和DATA2MEM工具,可 ...

  6. file_get_contents微信头像等待时间过长的原因

    UPDATE 2016/05/13 stackoverflow上的解决方法:http://stackoverflow.com/questions/3629504/php-file-get-conten ...

  7. pycharm索引index时间很长的原因

    pycharm进行索引index的目的时代码自动补全,当引入新的插件时,就会增加索引时间,插件越多,索引时间越长 没有好的解决办法,除非增加硬件:或者不使用代码自动补全功能

  8. 查看耗时长,CPU 100% 的SQL

    [session_id], [request_id], [start_time] AS '开始时间', [status] AS '状态', [command] AS '命令', dest.[text] ...

  9. saltstack执行state.sls耗时长的坑

    一直用的 jenkins + saltstack 自动化构建发布项目,一共也就不超过20台服务器,奈何运行时间越来越慢,并且负载越来越高(这里大部分都是使用state模块),但是不用state模块效率 ...

随机推荐

  1. 转载SQL_trace 和10046使用

    SQL_TRACE是Oracle提供的用于进行SQL跟踪的手段,是强有力的辅助诊断工具.在日常的数据库问题诊断和解决中,SQL_TRACE是非常常用的方法.本文就SQL_TRACE的使用作简单探讨,并 ...

  2. 编辑器——sublime

    在这里只介绍自己经常使用的编辑器sublime 第一:安装node插件[出处:http://www.bubuko.com/infodetail-798008.html] 1.下载Nodejs插件,下载 ...

  3. Jackson /常用注解/ annotation(转)

    1.@JsonAutoDetect 自动检测,(作用在类上)来开启/禁止自动检测. fieldVisibility:字段的可见级别 ANY:任何级别的字段都可以自动识别 NONE:所有字段都不可以自动 ...

  4. 部署apollo-client到maven私服上时遇到的问题及排查过程

    场景回顾: 应用客户端如果需要接入到Apollo配置服务中心的话,需要引用apollo-client的依赖包使之与config-server保持连接,从而可以及时的收到更新之后的配置信息. 1.将ap ...

  5. 64. Minimum Path Sum(最小走棋盘 动态规划)

    Given a m x n grid filled with non-negative numbers, find a path from top left to bottom right which ...

  6. JQuery如何实现双击事件时不触发单击事件,解决鼠标单双击冲突问题

    在jQuery的事件绑定中,如果元素同时绑定了单击事件(click)和双击事件(dblclick),那么执行单击事件(click)时,不会触发双击事件(dblclick), 执行双击事件(dblcli ...

  7. 论文笔记:OverFeat: Integrated Recognition, Localization and Detection using Convolutional Networks

    2014 ICLR 纽约大学 LeCun团队 Pierre Sermanet, David Eigen, Xiang Zhang, Michael Mathieu, Rob Fergus, Yann ...

  8. JVM内存区域划分Eden Space\Survivor Space\Tenured Gen\Perm Gen

    JVM区域分heap区和非heap区. 1)heap区:Eden Space(伊甸园),Survivor Space(幸存者区),Tenured Gen(老年代-养老区). 2)非heap区:Code ...

  9. Zookeeper环境安装

    源码包下载: http://archive.apache.org/dist/zookeeper/zookeeper-3.4.10 集群环境: master 192.168.1.99 slave1 19 ...

  10. 一.复习GCC编译器的用法

    1.复习GCC编译器的用法 欲善其工,那么要先利其器.在这个C语言巩固与提高的阶段中,如果想要更好的达成预期目标,首先就要熟练掌握GCC编译器的用法.以下是GCC相关知识: GCC使用语法 gcc 选 ...