Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Elasticsearch
インデクシングの
パフォーマンスを
測ってみた
黒澤亮二
自己紹介
• 黒澤亮二 @rjkuro
• 日本IBM
• Elasticsearch暦 1年
• 最近の興味:
分散データベース
NoSQL
Search/Analysis
並列処理
disclaimer
• パフォーマンスは環境に大きく依存します
• できるだけ一般的な傾向を測定するようにしてい
ますが、あくまで一例としてご理解ください
• 本資料は私自身の見解であり、必ずしも私の所属
する組織の立場、戦略、意見を代表する...
インデクシングのパフォーマンス
特性を調べてみた
• LogstashやBeatsを使わず自力でJavaで
• ElasticsearchにHTTP RESTで直接データを送信
• Node client/Transport clientは使っ...
Advent Calender書きました
結論:インデクシングを
早く終わらせるためにすべき事
• 複数セッションからデータを送信するといい
• シャード数/ノード数=1がベスト
レプリカあると重い
• refresh intervalはデフォルトよりちょっと長めに
• bulk si...
ただし注意事項
• キューがあふれるとデータが捨てられる
• 1.x系はデフォルトでthrottlingが有効なので注意
• REST apiで一回に送れる
最大サイズ100MB (デフォルト)
• クラウド環境ではネットワークレイテンシに注意
かいつまんで計測結果を紹介
複数セッションでデータを送信して
スループット向上
ただし送りすぎ注意
32セッション以上ではデータ欠損
データ欠損時
何が起きているか?
各ノードにbulk処理用の
thread poolとqueueがある
queueのデフォルトサイズは50
あふれるとエラーコード429
(Too Many Requests)
{
"index": {
"_index": "test",
"_type": "document",
"_id": "1",
"stat...
ちなみに
ここでいう「リクエスト数」 =
bulk requestをshardごとに分解したもの
をカウント
1 nodeに50 shardあったら、
あっという間にqueueがあふれる!
シャードの個数については
ノード内のシャード数が多いと
オーバーヘッド増加
overallocation推奨されることが多いがindexパフォーマンス的にはマイナス
遅くなってしまう
もちろんレプリカ少ない方がいい
primary shardに書き込んだ後に、各replica shardでも書き込みを実行 → 待たされる
refresh intervalとsegment merge
refresh interval
デフォルトより少し長めがいい
なぜかというと
refresh intervalが長いと
background mergeが少ない
bulk処理完了
マージはバック
グラウンドで続く
ちなみにこのグラフ、
interval = 1sのとき
Merge Throttling(速度制限)も
起こっている
Throttlingがあると
徐々にスループットが悪化
1.7.3で測定
Throttlingは2.0から自動化されてユーザーがon/off切り替えできなくなっています
バルクのサイズは?
Max未満で小さすぎなければOK
小さすぎ
バルクサイズのmaxは100MB
クライアント側ではエラーの原因
分かりにくいので注意
javax.ws.rs.ProcessingException: java.io.IOException: Error writing to server
...
index設計時に
_allや_source削減で
処理を減らしてスループット向上
まとめ
• インデクシングパフォーマンスの傾向/注意事項を
紹介しました
• その他にもいろいろ測っているので興味があれば
懇親会で!
Upcoming SlideShare
Loading in …5
×

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

3,910 views

Published on

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

Published in: Engineering

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

×