Elasticsearchインデクシングのパフォーマンスを測ってみた

Elasticsearchインデクシングのパフォーマンスを測ってみた

1. 1. Elasticsearch インデクシングの パフォーマンスを 測ってみた 黒澤亮二
2. 2. 自己紹介 • 黒澤亮二 @rjkuro • 日本IBM • Elasticsearch暦 1年 • 最近の興味： 分散データベース NoSQL Search/Analysis 並列処理
3. 3. disclaimer • パフォーマンスは環境に大きく依存します • できるだけ一般的な傾向を測定するようにしてい ますが、あくまで一例としてご理解ください • 本資料は私自身の見解であり、必ずしも私の所属 する組織の立場、戦略、意見を代表するものでは ありません。
4. 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. 5. Advent Calender書きました
6. 6. 結論：インデクシングを 早く終わらせるためにすべき事 • 複数セッションからデータを送信するといい • シャード数/ノード数=1がベスト レプリカあると重い • refresh intervalはデフォルトよりちょっと長めに • bulk size小さすぎないように注意 • 不要なら_allや_sourceを削減
7. 7. ただし注意事項 • キューがあふれるとデータが捨てられる • 1.x系はデフォルトでthrottlingが有効なので注意 • REST apiで一回に送れる 最大サイズ100MB (デフォルト) • クラウド環境ではネットワークレイテンシに注意
8. 8. かいつまんで計測結果を紹介
9. 9. 複数セッションでデータを送信して スループット向上
10. 10. ただし送りすぎ注意 32セッション以上ではデータ欠損
11. 11. データ欠損時 何が起きているか？
12. 12. 各ノードにbulk処理用の thread poolとqueueがある
13. 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. 14. ちなみに
15. 15. ここでいう「リクエスト数」 = bulk requestをshardごとに分解したもの をカウント 1 nodeに50 shardあったら、 あっという間にqueueがあふれる！
16. 16. シャードの個数については
17. 17. ノード内のシャード数が多いと オーバーヘッド増加 overallocation推奨されることが多いがindexパフォーマンス的にはマイナス 遅くなってしまう
18. 18. もちろんレプリカ少ない方がいい primary shardに書き込んだ後に、各replica shardでも書き込みを実行 → 待たされる
19. 19. refresh intervalとsegment merge
20. 20. refresh interval デフォルトより少し長めがいい
21. 21. なぜかというと
22. 22. refresh intervalが長いと background mergeが少ない bulk処理完了 マージはバック グラウンドで続く
23. 23. ちなみにこのグラフ、 interval = 1sのとき
24. 24. Merge Throttling(速度制限）も 起こっている
25. 25. Throttlingがあると 徐々にスループットが悪化 1.7.3で測定 Throttlingは2.0から自動化されてユーザーがon/off切り替えできなくなっています
26. 26. バルクのサイズは？
27. 27. Max未満で小さすぎなければOK 小さすぎ
28. 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. 29. index設計時に
30. 30. _allや_source削減で 処理を減らしてスループット向上
31. 31. まとめ • インデクシングパフォーマンスの傾向/注意事項を 紹介しました • その他にもいろいろ測っているので興味があれば 懇親会で！