英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
本书基于 Elasticsearch 2.x 版本，有些内容可能已经过时。
堆内存:大小和交换edit
Elasticsearch 默认安装后设置的堆内存是 1 GB。对于几乎任何一个部署来说，这个数字通常都太小了。 如果你正在使用这些默认堆内存配置，您的集群很可能配置得不正确。
有两种方式可以修改 Elasticsearch 的堆内存大小。最简单的一个方法就是指定环境变量ES_HEAP_SIZE。
服务进程在启动时会读取这个变量，并相应地设置堆的大小。
比如，你可以用下面的命令设置它：
export ES_HEAP_SIZE=10g
此外，可以在启动进程时使用 JVM 标识传递堆内存大小，如果你觉得这样更简单的话：
通常来说，设置环境变量ES_HEAP_SIZE，比显式的设置-Xmx -Xms更好一点。
把你的内存的（少于）一半给 Luceneedit
一个常见的问题是给 Elasticsearch 配置的内存太大了。 假设你有一台 64 GB 内存的机器，天啊，你要把 64 GB 内存全都给 Elasticsearch。因为越多越好啊！
当然，内存对于 Elasticsearch 来说绝对是重要的，它可以被许多内存数据结构用来提供更快的操作。 但是说到这里，还有另外一个内存消耗大户非堆内存 (off-heap)：Lucene。
Lucene 被设计为可以利用操作系统底层来缓存内存数据结构。 Lucene 的段是分别存储在单个文件中的。 因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统底层也会把这些段缓存起来，以便更快的访问。 这些段包括倒排索引(inverted index, 用于全文搜索)和 doc values (用于聚合)。
Lucene 的性能取决于和操作系统的交互。 如果你把所有的内存都分配给 Elasticsearch 的堆内存，那将不会有剩余的内存给 Lucene。 这将严重地影响性能。
标准的建议是把可用内存的 50％ 给 Elasticsearch 的堆内存，剩下的 50％留着。它也不会被浪费，Lucene 会很乐意吃掉剩下的内存。
如果你不需要对 analyzed字符串 做聚合计算（例如，不需要 fielddata ）可以考虑降低堆内存。 堆内存越小，可以从 Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）获得更好的性能。
不要超过 32 GB！edit
不给 Elasticsearch 分配大量内存还有另外一个原因。 事实上，当内存小于 32 GB 时, HotSpot JVM 会采用一个对象指针压缩技巧。
在 Java 中，所有的对象都分配在堆上，并通过一个指针进行引用。 普通对象指针（OOP）指向这些对象，通常为 CPU 字长 的大小：32 位或 64 位，取决于你的处理器。 指针引用的就是这个 OOP 值的确切的字节位置。
对于 32 位系统，意味着堆内存大小最大为 4 GB。 对于 64 位的系统，可以使用更大的内存，但是 64 位的指针意味着更大的空间浪费，因为你的指针本身大了。 比浪费空间更糟糕的是，在主内存和各级缓存（例如 LLC，L1 等）之间移动数据的时候，更大的指针会占用更多的带宽。
Java 使用一个叫作压缩指针（compressed oops）的技术来解决这个问题。 指针不再指向对象在内存中的确切位置，而是表示 偏移量 。 这意味着 32 位的指针可以引用 40 亿个 对象 ，而不是 40 亿个字节。 最终，这意为着堆内存可以增长到 32 GB 的物理大小，但仍然用的是 32 位的指针。
一旦越过那个神奇的 ~32 GB 的边界，指针就会切回普通的对象指针。 每个对象的指针都变长了，就会使用更多的 CPU 内存带宽，也就是说你实际上失去了更多的内存。 事实上，当堆内存到达 40–50 GB 的时候，有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存。
这个故事的寓意是：即便你有足够的内存，也尽量不要超过 32 GB。因为它浪费了内存，降低了 CPU 的性能，还要让 GC 应对大内存。
到底需要低于 32 GB多少，来设置我的 JVM？edit
遗憾的是，这要看情况。
确切的划分要根据 JVM 和 平台(操作系统)而定。
如果你想安全的使用它，那么将堆内存设置为31 GB可能是安全的。
另外，你可以在你的 JVM 设置里添加 -XX:+PrintFlagsFinal 用来验证 JVM 的临界值，
并且检查 UseCompressedOops 的值是否为 true。
这将让您找到你的平台和 JVM 的确切的临界值。
例如，我们在一台安装 Java 1.7 的 MacOSX 上测试，可以看到指针压缩在被禁用之前，最大堆内存大约是在 32600 mb（~31.83 gb）：
$ JAVA_HOME=`/usr/libexec/java_home -v 1.7` java -Xmx32600m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops := true
$ JAVA_HOME=`/usr/libexec/java_home -v 1.7` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops = false
相比之下，同一台机器安装 Java 1.8，可以看到指针压缩在被禁用之前，最大堆内存大约是在 32766 mb（~31.99 gb）：
$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops := true
$ JAVA_HOME=`/usr/libexec/java_home -v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops
bool UseCompressedOops = false
这个例子告诉我们，影响内存指针压缩使用的临界值，是会根据 JVM 的不同而变化的。 所以从其他地方获取的例子，需要谨慎使用，并确保要根据你的配置和JVM来检查系统。
如果使用的是 Elasticsearch v2.2.0，启动日志其实会告诉你 JVM 是否正在使用内存指针压缩。 你会看到像这样的日志消息：
[2015-12-16 13:53:33,417][INFO ][env] [Illyana Rasputin] heap size [989.8mb], compressed ordinary object pointers [true]
这表明内存指针压缩正在被使用。如果没有，日志消息会显示 [false] 。
Swapping 是性能的坟墓edit
这是显而易见的，但是还是有必要说的更清楚一点：内存交换到磁盘对服务器性能来说是 致命 的。 想想看：一个内存操作必须能够被快速执行。
如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 现在, 再加上其他的10微秒操作的延迟。 不难看出 swapping 对于性能是多么可怕。
最好的办法就是在你的操作系统中完全禁用 swap。这样可以暂时禁用：
sudo swapoff -a
如果需要永久禁用，你可能需要修改/etc/fstab文件，具体请参考你的操作系统文档。
如果你并不打算完全禁用 swap，也可以选择降低swappiness的值。
这个值决定操作系统交换内存的频率。
这可以防止正常情况下发生交换，但仍允许操作系统在内存紧急的情况下发生交换。
对于大部分Linux操作系统，可以在 sysctl 中这样配置：
|
|
最后，如果上面的方法都不适用，你应该开启 mlockall。
它的作用就是允许 JVM 锁住其内存，防止被操作系统对其进行交换。在配置文件 elasticsearch.yml 中，设置如下：
bootstrap.mlockall: true