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

2,678 views

Published on

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

Published in: Engineering
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,678
On SlideShare
0
From Embeds
0
Number of Embeds
471
Actions
Shares
0
Downloads
8
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

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

×