Elasticsearchパフォーマンスの５つの基本
概要
フランスで行われたElasticのMeetupの動画がYoutubeにあがっていました。
公式だと、こちらのページで紹介されています。
フランスで行われているとはいえ、発表は英語でされています。
しかも、Youtubeなので自動字幕に翻訳機能をかませれば、日本語字幕を表示させて何となく話していることが分かるようにもなります。
せっかく視聴したので、メモをとったログをここに置いておくことにします。
OS編
ストレージ
パフォーマンスに関するところで基本のキ。
- ディスクのパフォーマンスのベースラインを取得しておく（スループット、レイテンシ）
- ベースラインを他のノードと比較してみることで、問題が分かることがある
- ネットワークのファイルシステムは使わないで。（ストレージの仮想化も含みます）
ディスクパフォーマンスチューニングについて。
- できることなら、SSDを使おう
- HDDの方なら、index.merge.scheduler.max_thread.countを１に。SSDならデフォルト値でおｋ
- RAIDを組むのであれば、RAID 0 （ストライピング）で最大パフォーマンスが出る
メモリ
- ファイルシステムのキャッシュはElasticsearchにとって重要である。（可能であれば、メモリの半分以上をFSキャッシュにあてるのを推奨）
- スワッピングが起きるのを計測する
- OSのメモリだけでなく、JVMもモニタリングする必要がある
CPU
CPUも他のメトリクスと比較する必要があるため計測する必要がある。
- GC
- Thread pools
- Index throttle time
- ES performance metrics
CGroup throttlingのモニタリングも忘れないでください
JVM
Heapは大きすぎても、小さすぎてもダメ！
小さすぎると・・・
- OutOfMemoryがおきる可能性がある
- 短い間隔でメモリに負荷がかかり、スパイクがおきる
- 頻繁な小さなGCによる停止（Elasticsearch自体のスループットの低下）
- 使用できるIndexバッファやキャッシュが減る
- Aggregationのパフォーマンスリミットに良くない影響が起きるかもしれない
大きすぎると・・・
Cluster State
以下を確認してみよう。
GET /_cluster/state
アプリケーション
Elasticsearch自体のパフォーマンスについて。
Kibanaのモニタリングの画面で、Elasticsearchのクラスタ状況が確認できる。
- クエリに対するキャッシュがあれば検索のレイテンシは小さい（が、ここではどんなクエリがキャッシュされるのか、されないのかについては触れない）
- 負荷が高まって受け付けられない状態になると、リクエストはReject（拒否）される
- リクエストを処理するのに使うバッファも、HeapSizeから取得するので、Heapメモリ大事
Logging
- ログにはさまざまな情報が含まれている。
- パフォーマンスを分析するには、時系列のグラフを確認するのが良い。（変化を確認することができるから）
- OSの層からアプリケーションの層まで、いろんな観点で見られるようなモニタリングのツールがあると便利（Elastic APM）
最後に
Finally, We're hiring...
