elasticsearch分配内存的配置：

    1、设置变量的形式: export ES_HEAP_SIZE=32G   该形式比拟好    2、启动es时增加启动差数: -Xmx 32G -Xms 32G  ,Xmx和Xms的大小最好一样，避免程序在运行时扭转大小。

es最大调配32G内存的起因：

1、内存对于Elasticsearch来说相对是重要的，用于更多的内存数据提供更快的操作。而且还有一个内存耗费小户-Lucene

Lucene的设计目标是把底层OS里的数据缓存到内存中。Lucene的段是别离存储到单个文件中的，这些文件都是不会变动的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的拜访。

Lucene的性能取决于和OS的交互，如果你把所有的内存都调配给Elasticsearch，不留一点给Lucene，那你的全文检索性能会很差的。

最初规范的倡议是把50%的内存给elasticsearch，剩下的50%也不会没有用途的，Lucene会很快吞噬剩下的这部分内存。不要超过32G

2、不调配大内存给Elasticsearch，事实上jvm在内存小于32G的时候会采纳一个内存对象指针压缩技术。

在java中，所有的对象都调配在堆上，而后有一个指针援用它。指向这些对象的指针大小通常是CPU的字长的大小，不是32bit就是64bit，这取决于你的处理器，指针指向了你的值的准确地位。

对于32位零碎，内存最大可应用4G。64零碎能够应用更大的内存。然而64位的指针意味着更大的节约，因为你的指针自身大了。节约内存不算，更蹩脚的是，更大的指针在主内存和缓存器之间挪动数据的时候，会占用更多的带宽。

java 应用一个叫内存指针压缩的技术来解决这个问题。它的指针不再示意对象在内存中的准确地位，而是示意偏移量。这意味着32位的指针能够援用40亿个对象，而不是40亿个字节。最终，也就是说堆内存长到32G的物理内存，也能够用32bit的指针示意。

一旦你越过那个神奇的30-32G的边界，指针就会切回一般对象的指针，每个对象的指针都变长了，就会应用更多的CPU内存带宽，也就是说你实际上失去了更多的内存。事实上当内存达到40-50GB的时候，无效内存才相当于应用内存对象指针压缩技术时候的32G内存。

这段形容的意思就是说：即使你有足够的内存，也尽量不要超过32G，因为它节约了内存，升高了CPU的性能，还要让GC应答大内存。

swapping是性能的坟墓

这是不言而喻的，然而还是有必要说的更分明一点，内存替换到磁盘对服务器性能来说是致命的。想想看一个内存的操作必须是疾速的。如果内存替换到磁盘上，一个100微秒的操作可能变成10毫秒，再想想那么多10微秒的操作时延累加起来。不难看出swapping对于性能是如许可怕。最好的方法就是在你的操作系统中齐全禁用swapping。这样能够临时禁用：

sudo swapoff -a

为了永恒禁用它，你可能须要批改/etc/fstab文件