Technologieaustausch

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

Die ELK-Optimierung kann unter folgenden Gesichtspunkten durchgeführt werden:

• Linux-Kernel-Optimierung
• JVM-Optimierung
• ES-Konfigurationsoptimierung
• Architekturoptimierung (Filebeat/Fluentd ersetzt Logstash, fügt Kafka als Nachrichtenwarteschlange hinzu)

Eigenschaften von ES als Protokollspeicher:

• Hohes gleichzeitiges Schreiben
• Lese weniger
• Akzeptieren Sie die Verzögerung innerhalb von 30 Sekunden
• Kann einen teilweisen Verlust von Protokolldaten tolerieren

Logstash-Optimierung

① Erhöhen Sie den Serverspeicher und den JVM-Heapspeicher

② Verwenden Sie mehrere Instanzen für den Lastausgleich

③Verwenden Sie Filebeat anstelle von Logstash, um Protokolldaten zu sammeln

Elasticsearch-Optimierung

(1) Optimieren Sie den Index von ElasticSearch

①Optimieren Sie 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"

②Aktualisierung optimieren

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

③Zusammenführung optimieren

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"

④Einstellungen optimieren

Sie müssen zuerst den Index schließen, ihn dann ausführen und ihn schließlich nach Erfolg öffnen.

• Index schließen

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

• Ändern Sie die Indexeinstellungen

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"}'

• Index öffnen

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

(2) Optimieren Sie die Thread-Pool-Konfiguration

Der Schreib-Thread-Pool ist voll, wodurch Aufgaben abgelehnt werden und einige Daten nicht geschrieben werden können. Nach der oben genannten Optimierung ist die Anzahl der Ablehnungen stark zurückgegangen, es gibt jedoch immer noch Fälle von Jobablehnungen. Daher müssen wir auch den Schreib-Thread-Pool optimieren.

Der Schreib-Thread-Pool verwendet einen Thread-Pool fester Art, dh die Anzahl der Kern-Threads entspricht dem maximalen Thread-Wert. Die Anzahl der Threads entspricht standardmäßig der Anzahl der CPU-Kerne. Der maximal einstellbare Wert kann nur die Anzahl der CPU-Kerne plus 1 sein. Bei einer 16-Kern-CPU ist dies beispielsweise die maximale Anzahl möglicher Threads eingestellt werden soll, ist 17.

Optimierung

• Die Anzahl der Threads wird auf 17 geändert, was der Gesamtzahl der CPU-Kerne plus 1 entspricht
• Die Warteschlangenkapazität erhöht sich. Die Aufgabe der Warteschlange besteht zu diesem Zeitpunkt darin, Spitzen zu beseitigen. Die Erhöhung der Warteschlangenkapazität selbst führt jedoch nicht zu einer Erhöhung der Verarbeitungsgeschwindigkeit, sondern fungiert nur als Puffer. Darüber hinaus darf die Warteschlangenkapazität nicht zu groß sein, da sonst zu viel Heap-Speicher belegt wird, wenn viele Aufgaben im Rückstand sind.

Ändern Sie die Datei „elasticsearch.yml“, um die Konfiguration hinzuzufügen

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

(3) Sperren Sie den Speicher und verhindern Sie, dass die JVM Swap verwendet

Swap-Swap-Partition: Wenn der physische Speicher des Systems nicht ausreicht, muss ein Teil des Speicherplatzes im physischen Speicher für die Nutzung durch das aktuell laufende Programm freigegeben werden. Der freigegebene Speicherplatz stammt möglicherweise von einigen Programmen, die längere Zeit nicht ausgeführt wurden. Der freigegebene Speicherplatz wird vorübergehend in Swap gespeichert. Wenn diese Programme ausgeführt werden, werden die gespeicherten Daten von Swap im Speicher wiederhergestellt. Auf diese Weise führt das System immer dann einen Swap durch, wenn der physische Speicher nicht ausreicht.

Die Swap-Swap-Partition wirkt sich sehr nachteilig auf die Leistung und Knotenstabilität aus und muss deaktiviert werden. Dies führt dazu, dass die Speicherbereinigung nur Minuten statt Millisekunden dauert und dazu führen kann, dass Knoten langsam reagieren oder sogar vom Cluster getrennt werden.

Die Swap-Partitionsmethode kann nicht zum Implementieren von ES verwendet werden

1) Swap im Linux-System deaktivieren (vorübergehend wirksam)

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

2) Reduzieren Sie die Verwendung von Swap in Linux-Systemen so weit wie möglich (dauerhaft wirksam)

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

3) Bootstrap.memory_lock aktivieren

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

(4) Reduzieren Sie die Anzahl der Shards und Kopien

1) Sharding

Die Größe des Index hängt von der Größe der Shards und Segmente ab. Wenn die Shards zu klein sind, kann dies zu einem erhöhten Overhead führen. Dies führt zu einer großen Anzahl von E/A-Vorgängen und beeinträchtigt die Schreibleistung.
Da die Größe jedes unserer Indizes unter 15 G liegt und der Standardwert 5 Shards beträgt, sind nicht so viele erforderlich, daher haben wir sie auf 3 angepasst.

"index.number_of_shards": "3"

2) Anzahl der Exemplare

Reduzieren Sie die Anzahl der Cluster-Kopier-Shards. Zu viele Kopien führen zu einer internen Schreiberweiterung des ES. Die Anzahl der Kopien ist standardmäßig 1. Wenn ein Knoten, auf dem sich ein Index befindet, ausfällt, verfügt ein anderer Computer mit einer Kopie über die Indexsicherungsdaten, sodass die Indexdaten normal verwendet werden können. Das Schreiben von Daten in eine Kopie wirkt sich jedoch auf die Schreibleistung aus. Für Protokolldaten ist 1 Kopie ausreichend. Bei Indizes mit großen Datenmengen können Sie die Anzahl der Kopien auf 0 setzen, um die Auswirkungen auf die Leistung zu reduzieren.

"index.number_of_replicas": "1"

Zusammenfassen

Logstash-Optimierungsmethode:

① Erhöhen Sie den Serverspeicher und den JVM-Heapspeicher

② Verwenden Sie mehrere Instanzen für den Lastausgleich

③Verwenden Sie Filebeat anstelle von Logstash, um Protokolldaten zu sammeln

ElasticSearch-Optimierungsmethode:

① Optimieren Sie den Index: Optimieren Sie fsync und erhöhen Sie das Intervall zum Leeren der Festplatte entsprechend

② Optimieren Sie die Konfiguration des Schreib-Thread-Pools, um die Ablehnung von Aufgaben zu reduzieren: Ändern Sie die ES-Konfigurationsdatei elasticsearch.yml und stellen Sie den Schreib-Thread auf die Anzahl der CPU-Kerne + 1 ein

③Sperren Sie den Speicher und verhindern Sie, dass ES Swap verwendet: swapoff -a, Swap schließen

④Reduzieren Sie die Anzahl der Index-Shards und -Kopien entsprechend