第14回Elasticsearch勉強会　LTの資料です。

1. Elasticsearch
インデクシングの
パフォーマンスを
測ってみた
黒澤亮二

2. 自己紹介
• 黒澤亮二 @rjkuro
• 日本IBM
• Elasticsearch暦 1年
• 最近の興味：
分散データベース
NoSQL
Search/Analysis
並列処理

3. disclaimer
• パフォーマンスは環境に大きく依存します
• できるだけ一般的な傾向を測定するようにしてい
ますが、あくまで一例としてご理解ください
• 本資料は私自身の見解であり、必ずしも私の所属
する組織の立場、戦略、意見を代表するものでは
ありません。

4. インデクシングのパフォーマンス
特性を調べてみた
• LogstashやBeatsを使わず自力でJavaで
• ElasticsearchにHTTP RESTで直接データを送信
• Node client/Transport clientは使っていません
• Elasticsearch 1.7.3
• 3 nodes x (32 CPU cores, 10GB memory, local SSD)
• Standard analyzer
• Text data avg. size 6KB
• シナリオごとにconfigurationを多少調整しています

5. Advent Calender書きました

6. 結論：インデクシングを
早く終わらせるためにすべき事
• 複数セッションからデータを送信するといい
• シャード数/ノード数=1がベスト
レプリカあると重い
• refresh intervalはデフォルトよりちょっと長めに
• bulk size小さすぎないように注意
• 不要なら_allや_sourceを削減

7. ただし注意事項
• キューがあふれるとデータが捨てられる
• 1.x系はデフォルトでthrottlingが有効なので注意
• REST apiで一回に送れる
最大サイズ100MB (デフォルト)
• クラウド環境ではネットワークレイテンシに注意

8. かいつまんで計測結果を紹介

9. 複数セッションでデータを送信して
スループット向上

10. ただし送りすぎ注意
32セッション以上ではデータ欠損

11. データ欠損時
何が起きているか？

12. 各ノードにbulk処理用の
thread poolとqueueがある

13. queueのデフォルトサイズは50
あふれるとエラーコード429
(Too Many Requests)
{
"index": {
"_index": "test",
"_type": "document",
"_id": "1",
"status": 429,
"error": "EsRejectedExecutionException[rejected execution
(queue capacity 50) on
org.elasticsearch.action.support.replication.TransportShardRe
plicationOperationAction$PrimaryPhase$1@73f30700]"
}
}
queue capacity変更可だがThread Poolのパラメータ変更は非推奨

14. ちなみに

15. ここでいう「リクエスト数」 =
bulk requestをshardごとに分解したもの
をカウント
1 nodeに50 shardあったら、
あっという間にqueueがあふれる！

16. シャードの個数については

17. ノード内のシャード数が多いと
オーバーヘッド増加
overallocation推奨されることが多いがindexパフォーマンス的にはマイナス
遅くなってしまう

18. もちろんレプリカ少ない方がいい
primary shardに書き込んだ後に、各replica shardでも書き込みを実行 → 待たされる

19. refresh intervalとsegment merge

20. refresh interval
デフォルトより少し長めがいい

21. なぜかというと

22. refresh intervalが長いと
background mergeが少ない
bulk処理完了
マージはバック
グラウンドで続く

23. ちなみにこのグラフ、
interval = 1sのとき

24. Merge Throttling(速度制限）も
起こっている

25. Throttlingがあると
徐々にスループットが悪化
1.7.3で測定
Throttlingは2.0から自動化されてユーザーがon/off切り替えできなくなっています

26. バルクのサイズは？

27. Max未満で小さすぎなければOK
小さすぎ

28. バルクサイズのmaxは100MB
クライアント側ではエラーの原因
分かりにくいので注意
javax.ws.rs.ProcessingException: java.io.IOException: Error writing to server
at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:286)
at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684)
at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:681)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:681)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:437)
at org.glassfish.jersey.client.JerseyInvocation$Builder.post(JerseyInvocation.java:343)
サーバーから一方的に切断され
たようなエラーになる

29. index設計時に

30. _allや_source削減で
処理を減らしてスループット向上

31. まとめ
• インデクシングパフォーマンスの傾向/注意事項を
紹介しました
• その他にもいろいろ測っているので興味があれば
懇親会で！