真尼玛服了，把 elasticsearch 内存扩充到 9G，每次 query 时间成功延迟到 5 秒以上了

[Reign]

昨天的帖子： https://www.v2ex.com/t/410623 ， 先来讲一下历程，mysql 共 30 个字段，一个 article 主字段，其余 29 个字段都是机器翻译改文章的内容，最初用的 xunsearch 索引 50 万数据，查询时间在 1 秒徘徊，太慢，用 elasticsearch 索引这 50 万行数据，还是 1 秒左右徘徊，想到 ES 默认内存是 1G，于是扩充到 9G （服务器 i5+16G+2T HDD ）,这下好了单次查询时间，试了很多次，都在 5 秒以上，哪怕我搜索一个单字段而不是搜索所有字段，比如：article_cn 这个字段，还是 5 秒，好的时候 3 秒或者 2 秒

我当时在想，9 个 G 也够把所有数据存到内存中了吧，结果现实还是很骨感，ES 可不可以把所有数据都存到内存中？

而且我发现 ES 一个奇怪的特点，就是有一个冷却期，如果你短时间频繁的搜索各种不同的关键词，query 时间会慢慢减少，如果你很久不搜索，再次搜索时，query 时间会很长。昨晚我试了很多次，逐渐降低到 1s 之内，今早一起来，query 时间又恢复到 8 秒了。。。

[Livid]

ELK 的很多问题真的只能靠堆硬件解决……

[sampeng]

@Livid 3 台 64G 的？ 66666...这个每天多少数据啊?

[lyc1116]

es 索引用的是堆外内存, 尽量少给 JVM 分配内存。 另外可以在启动时开启 preload，会把索引 mmap 到物理内存里。

[Livid]

@sampeng 3 台 128G / E5-2630 v2 双路。只分配了一半。

[est]

不开个 64G 内存你敢用 ES ？

[MartinWu]

@gouchaoer 长知识了。。

[st2udio]

我们 ES 用了 5 台 48 核心 128G 的机器。。

[jowuIM]

@est 才 50w 的数据。。。。

[Tinngi]

看看是不是 GC 问题。
@vus520 如果不是 term 或者 fuzzy 这样的底层搜索，都需要分词的。search analyzer 就是用来指定搜索的分词器。

[amd00]

这个问题你 4g 内存比 9g 内存性能高其实可以参考这个地方 https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#_give_less_than_half_your_memory_to_lucene @Reign 只给系统的一半，也就是你占用 mysql 5g 剩下 11g 分一半给 elasticsearch 性能比 11g 都分给 elasticsearch 高

[zuo]

为了获取更好的性能，通常 elasticsearch 会建议留一半的内存给 Lucene 做 cache，这样就可以将数据 mapping 到内存中，避免 search 的时候产生 I/O

[YMB]

@gouchaoer 贼鸡儿溜

[512557852]

@Livid 为什么配了 64G，不是说超过 32G 是浪费性能吗？

[likuku]

@512557852 浪费？内存向来是多多益善的吧

[ewBuyVmLZMZE]

内存全给 ES，没有剩余内存给 Lucese，能快么？ ES 只是壳，主要是集群之类的特性，你不能把内存全分配了，至少留一半给 Lucense

[aiyo218]

@likuku 对 ES 来说，还真不是越多越好，31G 正好。

[512557852]

@aiyo218 确切的说在 java 1.8 中，使用 CMS 是 32766MB，G1 是 32736M，比 32G 少一点。

[fatpa]

@Livid 曾为了扛下时延 10s 内大概 1000w 每分钟的数据量，堆了 10 来台 128G 的 ssd 集群，特别难过

[hayao650]

https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
看下这篇

[wukairobin]

并不是越大越好，因为 lucene 也是要吃内存的 你一点不留给 lucene，意味着全文索引很慢很慢