2016-09-13 12 views
0

アマゾンECS上のドッカーコンテナ内でエラスティックサーチを実行しています。ヒープが時間とともにわずかに増加することがわかりました。私たちが最初に気づいたのは、70%を上回ってリクエストを破棄し始めたときでした(indices.breaker.total.limit)。ヒープサイズを増加させる弾性サーチ

私は決して減少するヒープを見たことはない、魚のような感じです!

これまでのところ、インスタンスサイズを増やして、30Gメモリのインスタンスを実行しています。ヒープはメモリの半分に設定され、ES_HEAP_SIZE = 14g(Xmx = Xms = 14g)です。

似たような経験をしている人はいますか?それはElasticsearchのバグですか?または、間違った構成のみですか?

Elasticsearchの版:1.5.1

> curl localhost:9200/_cat/fielddata?v 

id      host   ip   node   total position deal_status heading.sortorder org_relationlastmodified deal_value deal_probability 1_ZipCodeVisit_0 tag employer_tag 1_CityVisit_0 dateofregistration temperature uniqueId _type quick_ratio org_relation employer_relationlastmodified turnover turnover_per_employee deal_source employer_relation deal_statusdate 1_custom_1466 average_salary_per_employee deal_orderdate 0_NumberOfEmployeesRange_20 1_LegalForm_0 1_custom_1816 0_WorksiteType_100 0_LineOfBusiness_2 equity_ratio profitmargin 0_LineOfBusiness_1 0_CountyVisit_40 0_NumberOfEmployeesRange_22 0_MunicipalityVisit_61 0_LegalForm_110 dividends 1_custom_1744 0_MunicipalityVisit_60 responsiblecoworker result_before_tax 
XMTlkdnsToKvMHqgApMBAg 5dc819096905 172.17.0.2 Hitman  729.8mb 8.1mb  1.1mb   261.5mb     1.7mb 305.3kb   849.1kb   20.9mb 6.4mb  1.3mb  19.3mb    12.3mb   0b 283.7mb 9.6mb  5.1mb  810.5kb      632.2kb 11.6mb     4.1mb  150.8kb   566.4kb   568.6kb  34.1kb      4.2mb  973.5kb      5.7mb   4.6mb  37.4kb    4.9mb    8.1mb  4.7mb  4.2mb    9.2mb   3.3mb      4.2mb    802.9kb   3.9mb  4.3mb  37.7kb     7.5mb    2.4mb    5mb 
dHAoWkHMQKSnwAB0KrJRJw 8ffc068518f9 172.17.0.2 Moira Brandon 718.9mb 8.2mb  1.1mb   261.5mb     1.3mb  124kb   793.3kb   19.6mb 6.4mb   1mb  19.1mb    10.2mb   0b 283.8mb 9.6mb  5.2mb  714.7kb      791.3kb 8.8mb     3.4mb   0b   422.6kb   83.9kb  16.8kb      4.6mb  989.4kb      5.6mb   4.5mb   0b    5.2mb    7.9mb  4.1mb  4.3mb    9mb   3.2mb      4.3mb      0b   3.8mb  4.3mb   0b     7.1mb    2.5mb    4.4mb 

[更新2016年10月24日] 我々はバージョン2.4.0にアップデートしているが、我々はまだ同じ問題が発生します。 GCを強制すると、ヒープは約4%に解放されます。これは、新しいインスタンスと同じ値です。

73%のヒープを持つインスタンスの例は、JVM MEMは古いものは約10gであることを示し、わからないことは

jvm mem heap percent 73% 
"young": "used_in_bytes" : 199026920 
"survivor": "used_in_bytes" : 2422528 
"old":  "used_in_bytes" : 10754631392 

GCを何トリガー普通のことですか?ヒープを70%以上に増やす必要がありますか?

+0

'curl' localhost:9200/_cat/fielddata?v''から得た出力で質問を更新できますか? – Val

答えて

0

これはおそらくこれに関連しています種別: pre 2.Xバージョンの既知の動作は、主に木場に影響しますが、私はelasticsearchも推測します。

このgithubの問題を参照してください: https://github.com/elastic/kibana/issues/5170

それは基本的に、このノードの問題に帰着あなたのケースで同じであってもよい:https://github.com/nodejs/node/issues/2683

また、理想的ではありませんESで設定することも。 elasticsearch設定でこの通常の容疑者を探してください:

bootstrap.mlockall: true 

シャード/レプリカがたくさんありますか?木場を使っていますか?

+0

mlockallはfalseに設定されています。はい、私たちはキバナを実行していますが、別のドッカーインスタンス(別のec2インスタンス上)でも実行されています。私たちは2.4へのアップグレードに取り組んでいますが、まだ問題があるかどうかを見てみましょう。シャードサイズがデフォルト(5)である2つのノード(Master、worker)があります。 – spunk

関連する問題