Aerospike-Fehler: Alle Batch-Warteschlangen sind voll

Question

Ich betreibe einen Aerospike-Cluster in Google Cloud. Nach der Empfehlung auf this post habe ich auf die letzte Version (3.11.1.1) aktualisiert und alle Server neu erstellt. In der Tat, verursacht diese Änderung meines 5-Server in einer viel geringeren CPU-Last zu betreiben (es vor rund 75% Last war, jetzt ist es auf 20%, wie zeigt in der Grafik unten:

Weil empfehlen

All batch queues are full

ich diesen discussion about the topic gefunden, die sich ändern. dieser geringen Last, ich die Clustergröße auf 4 Servern zu reduzieren entschieden Als ich das tat, meine Anwendung gestartet wird folgende Fehler erhalten Parameter batch-index-threads und batch-max-unused-buffers mit dem Befehl

asadm -e "asinfo -v 'set-config:context=service;batch-index-threads=NEW_VALUE'"

ich viele Kombinationen von Werten (Batch-Index-Threads mit 2,4,8,16) und keiner von ihnen hat das Problem gelöst, und auch die Änderung der batch-index-threads param versucht . Nichts löst mein Problem. Ich bekomme weiterhin den All batch queues are full Fehler.

Hier ist meine aerospace.conf relevanten Informationen:

service { 
    user root 
    group root 
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1. 
     paxos-recovery-policy auto-reset-master 
    pidfile /var/run/aerospike/asd.pid 
    service-threads 32 
    transaction-queues 32 
    transaction-threads-per-queue 4 
    batch-index-threads 40 
    proto-fd-max 15000 
    batch-max-requests 30000 
    replication-fire-and-forget true 
} 

ich 300GB SSD-Festplatten auf diesen Servern verwenden.

Answer 1

Eine kurze Notiz, die Sie kann oder auch nicht gehören:

A common mistake we have seen in the past is that developers decide to use 'batch get' as a general purpose 'get' for single and multiple record requests. The single record get will perform better for single record requests.

Es ist möglich, dass Sie durch das Netzwerk zwischen den Clients und Servern eingeschränkt werden. Die Reduzierung von 5 auf 4 Knoten reduzierte das Zuschlagrohr. Durch das Entfernen eines Knotens werden außerdem Clustermigrationen gestartet, die zusätzliche Netzwerklast hinzufügen.

Answer 2

Ich würde den batch-max-buffer-per-queue Config-Parameter betrachten.

Maximum number of 128KB response buffers allowed in each batch index queue. If all batch index queues are full, new batch requests are rejected.

In Verbindung mit diesem Wert von dem Standard von 255 erhöhen Sie auch die batch-max-unused-buffers-batch-index-threads x batch-max-buffer-per-queue + 1 (mindestens) wollen erhöhen. Wenn Sie das nicht tun, werden neue Puffer ständig erstellt und zerstört, da die Anzahl der freien (unbenutzten) Puffer kleiner ist als die, die Sie verwenden. In dem Moment, in dem die Batch-Antwort bedient wird, versucht das System, die Puffer auf die maximal unbenutzte Anzahl zu reduzieren. Sie werden sehen, dass dies in der batch_index_created_buffers Metrik konstant steigt.

Denken Sie daran, dass Sie genügend DRAM dafür haben müssen. Wenn Sie zum Beispiel erhöhen die batch-max-buffer-per-queue-320 werden Sie

40 (`batch-index-threads`) x 320 (`batch-max-buffer-per-queue`) x 128K = 1600MB 

Aus Gründen der Leistung verbrauchen die batch-max-unused-buffers sollte auf 13000 eingestellt werden, die einen maximalen Speicherverbrauch von 1625MB (1.59GB) pro Knoten hat.