技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

ELK の最適化は次の側面から実行できます。

• Linuxカーネルの最適化
• JVMの最適化
• ES構成の最適化
• アーキテクチャの最適化 (filebeat/fluentd が logstash を置き換え、kafka をメッセージキューとして結合)

ログストレージとしての ES の特徴:

• 高い同時書き込み
• 読む量を減らす
• 30 秒以内の遅延を受け入れる
• 部分的なログ データの損失を許容できる

Logstash の最適化

①サーバーメモリとJVMヒープメモリを増やす

② 負荷分散のために複数のインスタンスを使用する

③logstashではなくfilebeatを利用してログデータを収集する

エラスティックサーチの最適化

(1) ElasticSearchのインデックスを最適化する

①fsyncの最適化

为了保证不丢失数据，就要保护 translog 文件的安全:
Elasticsearch 2.0 之后，每次写请求(如 index 、delete、update、bulk 等)完成时，都会触发fsync将 translog 中的 segment 刷到磁盘，然后才会返回 200 OK 的响应；或者: 默认每隔5s就将 translog 中的数据通过fsync强制刷新到磁盘。
该方式提高数据安全性的同时，降低了一点性能。
==> 频繁地执行 fsync 操作，可能会产生阻塞导致部分操作耗时较久。 如果允许部分数据丢失，可设置异步刷新 translog 来提高效率，还有降低 flush 的阀值， 优化如下：
"index.translog.durability": "async",
"index.translog.flush_threshold_size":"1024mb",
"index.translog.sync_interval": "120s"

②最適化リフレッシュ

写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。
默认 1 秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。 对于日志搜索来说，实时性要求不是那么高，设置为 5 秒或者 10s；对于 SkyWalking，实时性要求更低一些，我们可以设置为 30s。
设置如下：
"index.refresh_interval":"5s"

③最適化マージ

index.merge.scheduler.max_thread_count 控制并发的 merge 线程数，如果存储是并发性能较好的 SSD，可以用系统默认的 max(1, min(4, availableProcessors / 2))，当节点配置的 cpu 核数较高时，merge 占用的资源可能会偏高，影响集群的性能，普通磁盘的话设为1，发生磁盘 IO 堵塞。设置 max_thread_count 后，会有 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许 3 个线程。
设置如下：
"index.merge.scheduler.max_thread_count":"1"

④設定の最適化

まずインデックスを閉じてから実行し、成功したら最後にインデックスを開く必要があります。

• インデックスを閉じる

curl -XPOST 'http://localhost:9200/_all/_close'

• インデックス設定を変更する

curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{"index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "10s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}'

• インデックスを開く

curl -XPOST 'http://localhost:9200/_all/_open'

(2) スレッドプール構成の最適化

書き込みスレッド プールがいっぱいであるため、タスクが拒否され、一部のデータを書き込むことができません。上記の最適化後、拒否の数は大幅に減りましたが、依然としてタスクが拒否される場合があります。したがって、書き込みスレッド プールも最適化する必要があります。

書き込みスレッド プールは、固定タイプのスレッド プールを使用します。つまり、コア スレッドの数は最大スレッド値と同じです。デフォルトでは、スレッドの数は CPU コアの数と同じになります。設定できる最大値は、CPU コアの数に 1 を加えた値のみです。たとえば、16 コアの CPU の場合、設定できるスレッドの最大数は次のとおりです。設定されるのは 17 です。

最適化

• スレッド数は、CPU コアの合計数に 1 を加えた 17 に変更されます。
• キューの容量が増加します。このときのキューの役割はピークを排除することです。ただし、キュー容量自体を増やしても処理速度は向上せず、バッファとして機能するだけです。さらに、キューの容量は大きすぎることはできません。大きすぎると、多くのタスクがバックログになったときにヒープ メモリが占​​有されすぎます。

elasticsearch.yml ファイルを変更して構成を追加します

# 线程数设置
thread_pool:
  write:
    # 线程数默认等于cpu核数，即16  
    size: 17
    # 因为任务多时存在任务拒绝的情况，所以加大队列大小，可以在间歇性任务量陡增的情况下，缓存任务在队列，等高峰过去逐步消费完。
    queue_size: 10000

(3) メモリをロックし、JVM がスワップを使用できないようにします。

スワップ スワップ パーティション: システムの物理メモリが十分ではない場合、現在実行中のプログラムが使用できるように物理メモリの領域の一部を解放する必要があります。解放された領域は、長期間動作しなかったプログラムによって発生する場合があります。解放された領域は、それらのプログラムが実行される直前に、スワップからメモリに復元されます。このように、物理メモリが不足した場合、システムは常にスワップを実行します。

スワップ スワップ パーティションはパフォーマンスとノードの安定性に非常に悪影響を与えるため、無効にする必要があります。これにより、ガベージ コレクションが数ミリ秒ではなく数分間継続し、ノードの応答が遅くなったり、クラスターから切断されたりする可能性があります。

ES の実装にはスワップ パーティション方式は使用できません

1) Linux システムでスワップをオフにする (一時的に有効)

执行命令 sudo swapoff -a
可以临时禁用 Swap 内存，但是操作系统重启后失效

2) Linux システムでのスワップの使用をできる限り減らす (永続的に有効)

执行下列命令
echo "vm.swappiness = 1" >> /etc/sysctl.conf
正常情况下不会使用 Swap，除非紧急情况下才会 Swap。

3) bootstrap.memory_lock を有効にする

config/elasticsearch.yml 文件增加配置
#锁定内存，不让 JVM 写入 Swap，避免降低 ES 的性能
bootstrap.memory_lock: true

(4) シャードとコピーの数を減らす

1) シャーディング

インデックスのサイズは、フラグメントとセグメントのサイズによって異なります。フラグメントが小さすぎると、オーバーヘッドが増加する可能性があり、フラグメントが頻繁にマージされる可能性があります。その結果、多数の IO 操作が発生し、書き込みパフォーマンスに影響を与えます。
各インデックスのサイズは 15G 未満であり、デフォルトは 5 シャードであるため、それほど多くのシャードは必要ないため、3 に調整しました。

"index.number_of_shards": "3"

2) 部数

クラスターのコピー シャードの数を減らしてください。コピーが多すぎると、ES の内部書き込みが拡張されます。デフォルトのコピー数は 1 です。インデックスが配置されているノードがダウンした場合、コピーを持つ別のマシンにインデックスのバックアップ データが保持されるため、インデックス データは正常に使用できます。ただし、コピーにデータを書き込むと、書き込みパフォーマンスに影響します。ログデータの場合は 1 コピーで十分です。 大量のデータを含むインデックスの場合、コピー数を 0 に設定して、パフォーマンスへの影響を軽減できます。

"index.number_of_replicas": "1"

要約する

Logstash の最適化方法:

①サーバーメモリとJVMヒープメモリを増やす

② 負荷分散のために複数のインスタンスを使用する

③logstashではなくfilebeatを利用してログデータを収集する

ElasticSearch の最適化方法:

① インデックスの最適化: fsync を最適化し、ディスクフラッシュの間隔を適切に増やします。

② タスクの拒否を減らすために書き込みスレッド プールの設定を最適化します。ES 設定ファイル elasticsearch.yml を変更し、書き込みスレッドを CPU コア数 + 1 に設定します。

③メモリをロックし、ES がスワップを使用できないようにします: swapoff -a, close swap

④インデックスのシャード数やコピー数を適切に削減する