Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

Mmap fs可能让大索引访问变得缓慢

Elasticsearch | 作者 kennywu76 | 发布于2018年08月13日 | | 阅读数:6952

在一年多以前,我写过Elasticsearch 5 入坑指南一文,其中提到将生产的某个ES集群从2.4升级到5.0以后, 冷数据结点搜索性能变差,对大索引进行搜索的时候,io read会长时间飙高,导致系统load很重,甚至到无法响应的程度。
 
通过进一步分析,用Linux下的Sar -B命令,可以看到有大量的数据被pagein到内存。 虽然通过“试”的方法,定位到这个问题和5.0开始使用的mmap fs有关联,并且通过更改为nio fs以后得到解决,但问题的底层根源一直没找到。 
 
近期有空重新去看了一下这个问题, 在Github上发现一个对os底层更熟悉的人提交并分析了类似的问题 Avoid file cache trashing on Linux with mmapfs by using madvise 。  细读之后,感觉该文抓到了问题的本质,以下基于该文做个总结:
  1. mmap fs对比nio fs,省去了磁盘io上的系统调用,并且不需要在jvm内部做io缓存,也减轻了GC压力。 所以通常来说,mmapfs的性能应该更高。 这也是为什么lucene推荐使用mmap fs,并且ES从5.0开始做为默认的store配置的原因。
  2. 然而,mmap系统调用,在内核层面默认会有一个2MB的预读大小设置,也就是说,当映射了一个大文件以后,即使读取其中1k个字节,mmap也会预读取2MB的数据到缓存。 这种策略是基于文件的访问大多数是顺序的假设。
  3. 在ES这个特定的应用场景,如果某数据结点上索引不是很大,系统剩余缓存也足够,一般不会有问题。但是如果是大数据应用场景,典型的如海量的日志ELK应用,则可能对大索引的搜索聚合,产生较多的随机磁盘访问。 从而mmap的预读策略,可能会导致大量的无用数据从磁盘读取到系统缓存。 在系统可用的缓存不是非常宽裕的情况下,某些极端场景下,会导致热数据被过于频繁的踢出内存,再反复读入,让磁盘IO不堪重负。
  4. Lucene有一个NativePosixUtil.madvise(buffer,NativePosixUtil.RANDOM)的native调用,可以用于指导内核对mmap过的文件做读取的时候,禁用预读。 上文作者将该调用hack进lucene代码,做搜索对比测试。 结论是对于磁盘io和cache的消耗,niofs都要好于mmapfs,而patch过的mmapfs则比niofs更好。
  5. 作者的测试仅限于搜索,对于其他类型的io操作,如写入,merge没有做过详尽测试,因此不清楚利弊。
  6. ES官方开发人员认为这是一个有趣的发现,值得深入去探究。对于用户报告的mmap fs性能比nio fs更差的问题,猜测可能是在大索引读取的场景下,预读带来的额外开销,抵消了相对niofs节省的系统调用等开销。 
  7. ES官方提到Lucene已经有一种类似功能的store,叫做NativeUnixDirectory(显然ES目前还没有对这种store的支持),用户动手能力强的话,应该可以利用这个store自己写一个ES plugin。 另外提到JAVA 10提供了O_DIRECT to streams / channels ,似乎官方打算等这个出来以后再看怎么处理这个问题。
  8. 要注意,这个预读是mmap层面的,和块设备的预读是两回事。 我们曾经尝试过使用 blockdev --setra 这个linux命令取消块设备预读,证实无法解决这个问题。

 
结论: 如果ES结点上会存放海量的索引数据,经常会有大索引(如1TB+)的搜索聚合操作,使用NIOFS会更安全,可以避免很多怪异的性能问题。
 

[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/754


2 个评论

能公布一些搜索方面具体的性能损耗的数据对比吗
原文链接里有作者做的对比测试, 主要是对比集中store设置产生的磁盘io次数,和对page cache的占用量,请参考文中的数据。 我自己没有做过严格的对比测试, 但是在实际生产环境上,对海量数据的日志集群,做过系统负载监控数据的对比。 对同样一个大索引进行搜索聚合,当使用mmap fs的时候,产生的的磁盘读要显著高于niofs,系统负载高很多,换成niofs有显著改善。

要回复文章请先登录注册