0
-2

写mmap内存变慢的原因

DongHao 发表于 2012年02月27日 16:17 | Hits: 4587
Tag: 操作系统 | bergwolf | 吴峰光 | mmap | page_mkwrite | writeback
有很多系统读写大文件时用的是这个办法:将大文件mmap到内存,然后直接对内存读写。这样就化read/write为memcpy操作,代码开发上很简便。被修改的内存页由kernel负责挑个时间写入硬盘,程序员不用操心。

但是,最近一些使用了taobao kernel(基于redhat6-2.6.32)的机器,上面那些使用mmap的应用变慢了。我们上线查看,才发现mmap文件里有很多脏页,kernel的writeback机制就不停的将这些脏页写往硬盘,结果造成了大量的io(从iostat看,除了几秒的间歇,io util几乎保持在100%),而如果换回2.6.18内核,就没有这个问题(io util不超过20%,而且很稀疏)。

为了简化应用模型,我们做了一个mmap_press程序模拟应用的写操作,内容很简单,就是mmap一块256MB的内存,然后在256MB的范围内随机的写,一次写8个字节,一共写25亿次,在rhel5(kernel-2.6.18)上,这个程序运行只需要374秒,而在我们的内核上,则要805秒才能完成,慢了两倍多。再换upstream的内核,一样慢,这个问题应该是一直有的。

看来自从writeback改成per bdi的以后,脏页写回的力度是大大加强了。加强是有原因的:越快写回脏页,页面新数据丢失的肯能就越少。但问题是,现在writeback的太频繁了,结果消耗了大量io,拖慢了应用。

能不能找个办法通知writeback子系统,让它每隔60秒或两分钟才开始写脏页,这样至少很多相邻的脏页能被合并成一次io,可以变大量小io为几个大io,速度会快很多。于是我们找到了这个参数 /proc/sys/vm/dirty_expire_centisecs ,默认值是3000,即30秒,也就是说,脏页要过了30秒才会被写往硬盘....等一等,这和我们观察到的完全不一样啊!?我们从iostat看到的是io util一直保持在100%,只有几秒的停歇,几秒啊,不是30秒。

多猜无益,writeback子系统可是相当大的一块,于是我们联系了Intel的吴峰光,他第二天就给出了两个patch,我们将其移植到2.6.32内核后(12),效果很明显,writeback不再是不停的制造io,而是5~6秒的集中io以后,就停下来大约30秒(这次符合dirty_expire_centisecs参数的默认值了),然后再开始5~6秒的集中io,如此循环。我们重新跑mmap_press程序,耗费时间是390秒,已经非常接近2.6.18的速度了。

感谢吴峰光同学的帮助。

大概看了一下吴峰光patch的注释:之前writeback在回写完一个文件后,会从头再查找一遍脏页,如果有脏页则继续回写;现在改成,回写到文件尾后,直接停下来,直到脏页expire(也就是30秒后了)再开始从头检查脏页并回写(这是我对patch的解释,肯定有纰漏之处,有兴趣的同学还是直接看一下patch)。原来如此,咱们的mmap操作有大量的随机写,产生了大量分散的脏页,writeback每次从头检查文件都发现脏页,结果每次都要从头开始回写,就这么不停的转着圈的回写,造成io几乎一直保持在100%。

但我还是有一个疑问:应用写内存只是一个内存操作,writeback写脏页只是一个硬盘操作,为什么硬盘操作会拖慢内存操作呢?最后万能的马涛同学给出了答案:应用对页面的写会触发内核的page_mkwrite操作,这个操作里面是会lock_page的,如果page正在被写往硬盘,那这时候它已经被writeback给lock了,page_mkwrite的lock_page会被阻塞,结果应用写内存的操作就顿住了,所以,越是频繁的writeback,越是会拖慢应用对mmap内存的写操作。


=== 2012.2.29 ===

Bergwolf:
nitpicky一下:) writeback的时候page只是会被mark成PG_WRITEBACK,而不是被lock住。所以page_mkwrite的等待很可能是在wait_for_page_writeback上而不是lock_page上。

RobinDong: 
我看了一下upstream的代码,以ext4文件系统的mmap为例,writeback时,write_cache_pages里先lock_page(mm/page-writeback.c 2241行),再调用ext4_writepage来写单个页面,ext4_writepage里调用block_write_full_page来把页面mark成PG_WRITEBACK。我这里看来,是先lock后mark。
另外,在我们这边的2.6.32老内核里,__block_page_mkwrite里没有调用wait_on_page_writeback,这个是去年五月份才加进去的。所以,2.6.32 mmap变慢的原因应该还是lock_page的争抢。

Bergwolf:
page_mkwirte应该只在page第一次被写的时候调用,线上应用的page应该都是在内存中了,为什么你们认为page_mkwrite和writeback有竞争呢?你的测试代码是新建一个sparse文件,有试过对一个已经在内存中的dense文件测试吗?

RobinDong:
我们用的就是已经在内存中的dense文件,之前我也以为只有page第一次进入内存时才有do_page_fault才有page_mkwrite,但是马涛哥颠覆了我的世界观——writeback完成后的page,在被写的时候就会调用page_mkwrite——代码路径我们今早也找到了。
在write_cache_pages里,lock_page以后会调用clear_page_dirty_for_io(page),然后一路

--> clear_page_dirty_for_io(page)
--> page_mkclean(page)
--> page_mkclean_file(page)
--> page_mkclean_one(page)

下来,一直到page_mkclean_one(page),里面会做pte_wrprotect(entry),也就是把pte置为“写保护”,这样做是故意的,当应用写这个page时,就会因为碰了“写保护”页面而触发do_page_fault,即使这个page已经是在内存中了。

-->do_page_fault
--> handle_mm_fault
--> handle_pte_fault

handle_pte_fault这段代码:

        if (flags & FAULT_FLAG_WRITE) {
                if (!pte_write(entry))
                        return do_wp_page(mm, vma, address,
                                        pte, pmd, ptl, entry);
                entry = pte_mkdirty(entry);
        }

如果用户是在尝试写页面(FAULT_FLAG_WRITE),且pte是写保护的(!pte_write(entry)),那么就调用do_wp_page,而do_wp_page里面对可写且共享的vma里的page,会依次调用page_mkwrite。

原文链接: http://donghao.org/2012/02/mmapauaeaayaooo.html

-2     0

我要给这篇文章打分:

可以不填写评论, 而只是打分. 如果发表评论, 你可以给的分值是-5到+5, 否则, 你只能评-1, +1两种分数. 你的评论可能需要审核.

评价列表(3)

  • -1 guest voted at 2012-02-28 09:12:56

  • +0 strongpapa voted at 2012-02-28 10:56:25

    我想起去年测过这个问题,不同的是当时我是写了一个内核模块来测的。大规模的mmap,应该是搜索应用吧?呵呵
  • -1 ideawu voted at 2012-02-28 12:20:50

    确实写得不是很清晰...