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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Elasticsearch 参考文档

› Elasticsearch: The Definitive Guide

› elasticseaerch-analysis-ik

这是一个创建于 2559 天前的主题，其中的信息可能已经有所发展或是发生改变。

昨天的帖子： 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 秒了。。。

第 1 条附言 · 2017-12-01 16:03:15 +08:00

刚刚把内存设为 4G，query 时间控制在了 500ms 之内了，这是为啥？？？目前 16G 内存，mysql 耗掉了 5G 内存，剩下 11G 内存，我当时就在想给 9G 给 ES，剩下 2G 跑系统没一点问题吧，为啥内存给 ES 越多反而越慢？

query

搜索

冷却期

时间

40 条回复 • 2018-06-19 17:07:47 +08:00

yonka

2017-12-01 11:00:08 +08:00

IO 负担过重？

dangyuluo

2017-12-01 11:10:03 +08:00

贴 mapping 啊

Reign

2017-12-01 11:15:49 +08:00

@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'
],
]
]
]

Reign

2017-12-01 11:17:25 +08:00

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

janxin

2017-12-01 11:18:04 +08:00

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

owenliang

2017-12-01 11:19:13 +08:00

小伙子工作全靠猜啊。

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

Reign

2017-12-01 11:19:36 +08:00

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

dangyuluo

2017-12-01 11:31:44 +08:00

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

bzzhou

2017-12-01 13:19:00 +08:00

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

vus520

2017-12-01 14:19:28 +08:00

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

JohnSmith

2017-12-01 14:20:29 +08:00 via Android

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

jowuIM

2017-12-01 14:38:44 +08:00

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

armstrong

2017-12-01 14:45:19 +08:00

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

zhengxiaowai

2017-12-01 15:37:19 +08:00

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

gouchaoer

2017-12-01 15:40:23 +08:00

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

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

misaka19000

2017-12-01 15:44:37 +08:00

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

这招学习到了

jowuIM

2017-12-01 15:48:53 +08:00

@gouchaoer 666

anofac

2017-12-01 16:02:42 +08:00 via Android

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

czjxy881

2017-12-01 16:13:07 +08:00

@anofac 正解

sampeng

2017-12-01 16:16:38 +08:00

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

Livid

MOD

2017-12-01 16:18:54 +08:00

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

sampeng

2017-12-01 16:22:48 +08:00

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

lyc1116

2017-12-01 16:29:40 +08:00

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

Livid

MOD

2017-12-01 16:38:11 +08:00

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

est

2017-12-01 16:43:51 +08:00

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

MartinWu

2017-12-01 16:56:57 +08:00

@gouchaoer 长知识了。。

st2udio

2017-12-01 17:13:58 +08:00

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

jowuIM

2017-12-01 17:27:12 +08:00

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

Tinngi

2017-12-01 17:51:50 +08:00

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

amd00

2017-12-01 18:56:56 +08:00

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