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

IO 负担过重？

贴 mapping 啊

@dangyuluo
'mappings' => [
'blog' => [
'properties' => [
'article_en' => [
'type'=>'text',
'analyzer'=>'english'
],
'article_zh' => [
'type'=>'text',
'analyzer'=>'ik_max_word'
],
'article_ru' => [
'type'=>'text',
'analyzer'=>'russian',
],
'article_ja' => [
'type'=>'text',
'analyzer'=>'kuromoji',
],
'article_de' => [
'type'=>'text',
'analyzer'=>'german',
],
'article_es' => [
'type'=>'text',
'analyzer'=>'spanish',
],
'article_fr' => [
'type'=>'text',
'analyzer'=>'french',
],
'article_pt' => [
'type'=>'text',
'analyzer'=>'portuguese',
],
'article_it' => [
'type'=>'text',
'analyzer'=>'italian',
],
'article_pl' => [
'type'=>'text',
'analyzer'=>'polish',
],
'article_tr' => [
'type'=>'text',
'analyzer'=>'turkish',
],
'article_nl' => [
'type'=>'text',
'analyzer'=>'dutch',
],
'article_ko' => [
'type'=>'text',
'analyzer'=>'openkoreantext-analyzer',
],
'article_cs' => [
'type'=>'text',
'analyzer'=>'czech',
],
'article_ar' => [
'type'=>'text',
'analyzer'=>'arabic',
],
'article_vi' => [
'type'=>'text',
],
'article_id' => [
'type'=>'text',
'analyzer'=>'indonesian',
],
'article_no' => [
'type'=>'text',
'analyzer'=>'norwegian',
],
'article_el' => [
'type'=>'text',
'analyzer'=>'greek',
],
'article_sv' => [
'type'=>'text',
'analyzer'=>'swedish',
],
'article_ro' => [
'type'=>'text',
'analyzer'=>'romanian',
],
'article_hu' => [
'type'=>'text',
'analyzer'=>'hungarian',
],
'article_da' => [
'type'=>'text',
'analyzer'=>'danish',
],
'article_th' => [
'type'=>'text',
'analyzer'=>'thai',
],
'article_sk' => [
'type'=>'text',
],
'article_fi' => [
'type'=>'text',
'analyzer'=>'finnish',
],
'article_bg' => [
'type'=>'text',
'analyzer'=>'bulgarian',
],
'article_he' => [
'type'=>'text',
],
'article_lt' => [
'type'=>'text',
'analyzer'=>'lithuanian',
],
'article_uk' => [
'type'=>'text',
'analyzer'=>'ukrainian',
],
'article_hr' => [
'type'=>'text',
],
'article_sr' => [
'type'=>'text',
],
'article_ca' => [
'type'=>'text',
'analyzer'=>'catalan',
],
'article_sl' => [
'type'=>'text',
],
'article_lt' => [
'type'=>'text',
'analyzer'=>'latvian',
],
'article_es' => [
'type'=>'text'
],
]
]
]

搜索：
$params =
[
'index' => 'blahblah',
'type' => 'blog',
'body' =>
[
'from'=>$page,
'size'=>30,
'query' =>
[
'query_string'=>
[
'query'=>$item,
"default_operator"=>"AND"
]
]
]
];

es 要改配置的，配置是不是默认的？

小伙子工作全靠猜啊。

vmstat, iostat, top, mpstat 分析分析瓶颈啊？

@janxin 只改了内存为 9G
ps aux | grep elasticsearch
elastic+ 4268 1.8 62.8 19521528 10358908 ? Ssl 10:15 1:09 /bin/java -Xms9g -Xmx9g

我猜，你用这么多分词器，每一次搜索都要初始化这些分词器然后对你的搜索语句进行分词，可能在这里耗时间比较多。
你可以试验一下几个分词器的时间。这种情况我觉得可以考虑把不同的语言放在不同的 nodes 上

小伙子，好好定性定量分析一下，说不定问题早就解决了

@dangyuluo 你是在逗我，在查询的时候再进行分词？

@bzzhou +1
利用工具定位问题比代码能力重要，现在提个 issue 都会要求贴环境和日志的

变慢应该是冷启动命中问题，不太熟悉 es，但是应该能用日志把一些热词装进内存

我没记错的话，官方推荐的 ES 配置内存是 16GB，现在业界用 ES 的公司和 Team 多了去了，都用着很开心，为啥你怨气这么多呢

明显是你对 ES 不熟悉啊，多去看看手册吧，你这全靠猜啊。。。。

lz 的做法是对的，如果 lz 问个问题：为啥我的 es 这么慢，有大神帮忙看看么？
估计没人理他

然后 lz 出来大骂 es 垃圾，如果我用 xunsearch 的话速度还比这更快，然后就一堆人出来说：
你这个 mapping 这样写 balabala 就 ok 了，然后 lz 问题解决了

@gouchaoer #15 想起来 the social network 里面的场景了。。。

这招学习到了

@gouchaoer 666

虽然我没实际用过 ES，不过有看过一点官方文档。LZ 这加了 ES 内存反倒慢了，让我忽然想到，ES 底层是 Lucene 呀，真正大部分查询的活儿是 Lucene 在干，你把 ES 内存调那么高, Lucene 表示被压榨了，不开心。。。 不知道说的对不对，如有错误请真正的大神指正：)

@anofac 正解

内存不是核心问题。。。曾经一个 case。就算内存加到 64G 页没什么卵用。index 和分词没搞好，都是浮云。我也没用工具测。只是一眼就看出 jvm 的内存有多少吃多少，就算加到天际又又何用
主要是 mapping。mapping 搞太多分词了。。如果只用一个分词先试一下。如果没问题，那就针对这个问题去解决。
个人猜想可以冗余存储。每个语法一个 index。这样会不会快很多。在一个索引下创建 n 个分词器进行分词处理。这个 index 会不会膨胀的太厉害？

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

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

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

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

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

@gouchaoer 长知识了。。

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

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

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

这个问题你 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 高

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

@gouchaoer 贼鸡儿溜

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

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

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

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

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

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

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

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