乐趣区

关于elasticsearch:ES最大内存为什么设置为32G

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 文件 
退出移动版