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