ElasticSearch：堆大小与swap设置

译自ES官方对于JVM参数的建议，原文见： https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html

堆空间的配置方法

ElasticSearch的默认设置中，给服务分配了1GB的堆空间。对于大多数实例来说，这个值都太小了。如果你使用默认的堆空间大小，那么你的集群配置是有问题的。

有两种方式可以修改ElasticSearch的堆大小。最容易的一种就是设置一个叫 ES_HEAP_SIZE 的环境变量。当系统服务启动时，它会读到这个环境变量并将它应用于堆。

你可以执行以下命令行：

export ES_HEAP_SIZE=10g

还有另一种方式，你可以在启动ElasticSearch的命令上带参数，如果觉得这样更方便的话：

./bin/elasticsearch -Xmx10g -Xms10g 

一般来说，如果你不需要特别设置-Xmx和-Xms的话，比较推荐使用ES_HEAP_SIZE环境变量。

把内存留一半给Lucene

有一个常见的现象：给堆分配太大空间了。比如说你有一台64GB的机器——这已经是让人赞叹的配置，而你想把这64GB的内存全部给ElasticSearch。越多越好不是吗？

对于ElasticSearch来说，堆空间很重要。它用到很多内存中的数据结构来保证应用的快速响应。但是，ElasticSearch中有一个很重要的部分是不用堆内存的：Lucene。

Lucene在设计上主要使用了基于底层操作系统内存的数据结构。Lucene段（segment）就保存在各个文件中。因为段是不可变的，这些文件永远不会改变。这非常有利于使用内存来缓存，底层操作系统乐于将经常被访问的段放在内存里来加快访问速度。

Lucene的性能依赖于与操作系统的这种互动。如果你把所有的可用内存都给了ElasticSearch对，留给Lucene的内存就不够了。这将严重影响全文搜索的性能。

标准建议是：50%的可用内存给ElasticSearch堆，剩下的50%保持自由——它们不会闲置，Lucene会愉快地吞噬掉这些留下来的内存。

别超过32GB！

不分配过于庞大的堆空间给ElasticSearch还有另一个原因。如我们所知，JVM的对象指针压缩只能在堆小于32GB的场景下使用。

在Java中，所有的对象都在堆中分配，并通过一个指针引用。普通对象指针（OOP - Ordinary object pointers）会指向这些对象，指针的长度是CPU的本地字长：32bit或64bit，这取决于处理器。引用指针里存储的是一个确切的内存地址。

在32位操作系统中，这意味这堆的最大大小是4GB。对于64位系统来说，堆可以很大，但是64位指针意味着会占用更多的空间，因为指针长度更长了。比浪费空间更糟糕的是，更长的指针在主存储和高速缓存之间移动时，需要占用更大的带宽（LLC，L1等等）。

Java使用了一种被称为压缩指针的方法来解决这个问题。压缩指针指的是，不再用指针指向内存中的精确地址，而是将引用指向一个对象偏移量（object offsets）。这意味着一个32位的指针可以指向40亿的对象，而不是40亿位（byte）。最终，这意味着在指针压缩的情况下，堆依然采用32位指针，但允许增长到32GB的物理大小。

一旦超过了这个神奇的30-32GB的边界，指针会切换会普通对象指针（oop）。指针的大小增长，更多的CPU至内存带宽使用，你在大量的损失调有效内存。实际上，一个40至50GB的堆相当于一个32GB的使用了引用压缩的堆。

这个故事的寓意是：即使你有空闲的内存，也尽量避免越过32GB的堆边界。这会浪费内存，降低CPU性能，并让GC和大堆做斗争。

swap（交换区）是性能终结者

这应该显而易见了，但仍然需要明确的写出来：把内存换成硬盘将毁掉服务器的性能，想象一下：涉及内存的操作是需要快速执行的。如果介质从内存变为了硬盘，一个10微秒的操作变成需要10毫秒。而且这种延迟发生在所有本该只花费10微秒的操作上，就不难理解为什么交换区对于性能来说是噩梦。

最好的选择是禁用掉操作系统的交换区。可以用以下命令：

sudo swapoff -a

来禁用，你可能还需要编辑_/etc/fstab文件。细节可以参考你的操作系统文档。

如果实际环境不允许禁用掉swap，你可以尝试降低swappiness。此值控制操作系统使用交换区的积极性。这可以防止在正常情况下使用交换区，但仍允许操作系统在紧急情况下将内存里的东西放到交换区。

对于大多数Linux系统来说，这可以用_sysctl值来配置：

vm.swappiness = 1
* 将此值配置为1会比0好，在kernal内核的某些版本中，0可能会引起OOM异常。

最后，如果两种方法都不可用，你应该在ElasticSearch的配置中启用mlockall.file。这允许JVM锁定其使用的内存，而避免被放入操作系统交换区。

在elasticsearch.yml中，做如下设置：

bootstrap.mlockall: true