前一阵子公司一部门有人叫帮忙调查,说他们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. mysql在线手册汇总

    1. MySQL官网 http://www.mysql.com/ • Reference Manual ▶ MySQL 5.0 Reference Manual:http://dev.mysql.co ...

  2. isEnable() 和 isDisplayed() 和 isSelected()

    isEnable().isDisplayed()和isSelected() 1.以上三个为布尔类型的函数 2.isEnable用于存储input.select等元素的可编辑状态,可以编辑返回true, ...

  3. PKU 1655 Balancing Act(树+树的重心)

    #include<cstdio> #include<cstring> #include<algorithm> #define maxn 20005 using na ...

  4. 某个php爬虫程序分析--来自wooyun

    乌云漏洞编号: WooYun-2014-68061 作者:hkAssassin 爬虫程序源码: <?php header("content-type:text/html;charset ...

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

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

  6. TOSCA自动化测试工具--How to modify windows

    1.页面窗口(高亮的部分是我们需要的所有窗口) 2.窗口可以任意拖拽到任何地方 3.窗口可以并列显示 任务栏点击按钮可以继续拖动 放到自己想放的地方 4.收起preview,调整宽窄 5.保存当前wi ...

  7. Python中正则模块re.compile、re.match及re.search函数用法

    import rehelp(re.compile)'''输出结果为:Help on function compile in module re: compile(pattern, flags=0) C ...

  8. Java Calendar类总结

    在实际项目当中,我们经常会涉及到对时间的处理,例如登陆网站,我们会看到网站首页显示XXX,欢迎您!今天是XXXX年....某些网站会记录下用户登陆的时间,比如银行的一些网站,对于这些经常需要处理的问题 ...

  9. WeX5基础

    最近在研究微信app开发,使用的是WeX5,在这里把一些基础知识点记录下来,忘记了可以翻阅查看. 一:开发后端服务 1.建立数据源:窗口--首选项--studio配置--数据源--增加--数据源类型选 ...

  10. 20145312 《Java程序设计》第九周学习总结

    20145312 <Java程序设计>第九周学习总结 学习笔记 Chapter 16整合数据库 16.1 JDBC入门 16.1.1 JDBC简介 SUN公司为了简化.统一对数据库的操作, ...