Fehlerbehebung bei RabbitMQ-Leistungsproblemen: Langsamkeit und hohe CPU-Auslastung

RabbitMQ ist ein robuster, weit verbreiteter Nachrichtenbroker, aber wie jedes verteilte System kann es zu Leistungseinbußen kommen, die sich oft als allgemeine Langsamkeit oder übermäßige CPU-Auslastung äußern. Die Identifizierung der Ursache – ob in der Netzwerkkonfiguration, der Festplatten-I/O oder der Anwendungslogik – ist entscheidend für die Aufrechterhaltung der Systemgesundheit und niedriger Latenzzeiten.

Dieser Leitfaden dient als praktisches Handbuch zur Fehlerbehebung für die Diagnose und Behebung häufiger Leistungsengpässe in Ihrer RabbitMQ-Bereitstellung. Wir werden kritische Überwachungspunkte untersuchen und umsetzbare Schritte zur Optimierung des Durchsatzes und zur Stabilisierung der CPU-Last bereitstellen, um sicherzustellen, dass Ihr Nachrichtenbroker unter Druck zuverlässig funktioniert.

Erste Triage: Identifizierung des Engpasses

Bevor Sie in tiefgreifende Konfigurationsänderungen eintauchen, ist es wichtig, genau zu bestimmen, wo der Engpass auftritt. Hohe CPU-Auslastung oder Langsamkeit deuten normalerweise auf einen von drei Bereichen hin: Netzwerksättigung, intensive Festplatten-I/O oder ineffiziente Anwendungsinteraktionen mit dem Broker.

1. Überwachung der RabbitMQ-Gesundheit

Der erste Schritt ist die Nutzung der integrierten Überwachungstools von RabbitMQ, hauptsächlich des Management-Plugins.

Wichtige zu beobachtende Metriken:

Nachrichtenraten: Achten Sie auf plötzliche Spitzen in den Veröffentlichungs- oder Zustellraten, die die nachhaltige Kapazität des Systems überschreiten.
Warteschlangenlängen: Schnell wachsende Warteschlangen zeigen an, dass Verbraucher hinter den Produzenten zurückbleiben, was oft zu erhöhtem Speicher-/Festplattendruck führt.
Kanal-/Verbindungsaktivität: Hohe Fluktuation (häufiges Öffnen und Schließen von Verbindungen/Kanälen) verbraucht erhebliche CPU-Ressourcen.
Festplattenalarme: Wenn sich die Festplattenauslastung dem konfigurierten Schwellenwert nähert, verlangsamt RabbitMQ die Nachrichtenzustellung bewusst, um Datenverlust zu verhindern (Flusskontrolle).

2. Überprüfung des Betriebssystems

RabbitMQ läuft auf der Erlang-VM, die empfindlich auf Ressourcenkonflikte auf Betriebssystemebene reagiert. Verwenden Sie Standardtools, um die Systemgesundheit zu bestätigen:

CPU-Auslastung: Verwenden Sie top oder htop. Verbraucht der rabbitmq-server-Prozess den größten Teil der CPU? Wenn ja, untersuchen Sie die Aufschlüsselung der Erlang-Prozesse (siehe Abschnitt unten).
I/O-Wartezeit: Verwenden Sie iostat oder iotop. Hohe I/O-Wartezeiten deuten oft auf langsame Festplatten hin, insbesondere wenn die Persistenz stark genutzt wird.
Netzwerklatenz: Verwenden Sie ping zwischen Produzenten, Verbrauchern und den Broker-Knoten, um allgemeine Netzwerkinstabilität auszuschließen.

Tiefergehende Analyse: Hohe CPU-Auslastung

Hohe CPU-Auslastung in RabbitMQ wird häufig auf intensive Operationen zurückgeführt, die von der Erlang-VM oder spezifischer Protokollaktivität verarbeitet werden.

Verständnis der Erlang-Prozesslast

Die Erlang-Laufzeitumgebung verwaltet Prozesse effizient, aber bestimmte Aufgaben sind CPU-intensiv. Wenn die CPU-Auslastung des RabbitMQ-Servers bei 100% über alle Kerne hinweg liegt, untersuchen Sie, welche Erlang-Prozessgruppe dafür verantwortlich ist.

Protokoll-Handler (AMQP/MQTT/STOMP)

Wenn viele Clients ständig Verbindungen auf- und abbauen oder große Mengen kleiner Nachrichten veröffentlichen, steigen die CPU-Kosten für Authentifizierung, Kanaleinrichtung und Paketverarbeitung erheblich. Häufiger Verbindungswechsel ist ein großer CPU-Killer.

Bewährte Praxis: Bevorzugen Sie dauerhafte, langlebige Verbindungen. Verwenden Sie auf der Client-Seite Verbindungspooling, um den Overhead wiederholter Handshake- und Einrichtungsphasen zu minimieren.

Warteschlangenindizierung und persistente Nachrichten

Wenn Warteschlangen stark genutzt werden, insbesondere wenn Nachrichten persistent sind (auf die Festplatte geschrieben werden), kann die CPU-Last aus folgenden Gründen ansteigen:

Festplatten-I/O-Verwaltung: Koordination von Festplattenschreibvorgängen und Leeren von Puffern.
Nachrichtenindizierung: Verfolgen der Nachrichtenpositionen innerhalb der Warteschlangenstruktur, insbesondere in hochgradig dauerhaften, durchsatzstarken Warteschlangen.

Drosselung und Flusskontrolle

RabbitMQ implementiert eine Flusskontrolle, um sich selbst zu schützen, wenn Ressourcen knapp werden. Wenn ein Knoten einen hohen Wasserstand für Speicher oder Festplattenplatz erreicht, wendet er eine interne Drosselung an, die sich für Produzenten als Langsamkeit äußern kann.

Wenn Sie sehen, dass zahlreiche Nachrichten aufgrund der Flusskontrolle blockiert werden, besteht die sofortige Lösung darin, Ressourcen freizugeben (z. B. sicherstellen, dass Verbraucher aktiv sind, oder den Festplattenplatz erhöhen). Die langfristige Lösung ist die Skalierung des Clusters oder die Optimierung des Verbraucherdurchsatzes.

Fehlerbehebung bei langsamen Verbrauchern und Warteschlangenaufbau

Langsamkeit wird von der Anwendungsschicht oft wahrgenommen, wenn Verbraucher nicht mit der Eingangsrate Schritt halten können. Dies ist normalerweise ein Problem auf der Verbraucherseite oder ein Netzwerkproblem zwischen dem Verbraucher und dem Broker.

Bestätigungsstrategie des Verbrauchers

Die Art und Weise, wie Verbraucher Nachrichten bestätigen, hat tiefgreifende Auswirkungen auf den Durchsatz und die CPU-Auslastung des Brokers.

Manuelle Bestätigung (manual ack): Bietet Zuverlässigkeit, erfordert jedoch, dass der Verbraucher den Erhalt bestätigt. Wenn der Verbraucher hängt, behält RabbitMQ die Nachricht, was möglicherweise den Speicher blockiert und Verzögerungen für andere Nachrichten in dieser Warteschlange verursacht.
Automatische Bestätigung (auto ack): Maximiert zunächst den Durchsatz, aber wenn der Verbraucher nach Erhalt einer Nachricht, aber vor deren Verarbeitung abstürzt, geht die Nachricht für immer verloren.

Wenn Sie manuelle Bestätigungen verwenden und Verlangsamungen feststellen, überprüfen Sie die Anzahl der Unbestätigten Nachrichten im Management-Plugin. Wenn diese Zahl hoch ist, sind die Verbraucher entweder langsam oder bestätigen nicht.

Optimierung der Vorabrufanzahl

Die qos-Einstellung (Quality of Service), insbesondere die Vorabrufanzahl, bestimmt, wie viele Nachrichten ein Verbraucher unbestätigt halten kann.

Wenn die Vorabrufanzahl zu hoch eingestellt ist (z. B. 1000), kann ein einzelner langsamer Verbraucher einen massiven Rückstand aus der Warteschlange ziehen und andere, möglicherweise schnellere Verbraucher in derselben Warteschlange aushungern.

Beispiel: Wenn ein Verbraucher nur 10 Nachrichten/s verarbeitet, ist die Einstellung von prefetch_count auf 100 verschwenderisch und konzentriert die Last unnötig.

# Beispiel für das Setzen einer angemessenen Vorabrufanzahl (z. B. 50)
# Verwendung einer Client-Bibliothek-Äquivalent (Konzeptionelle Darstellung)
channel.basic_qos(prefetch_count=50)

Netzwerklatenz zwischen Verbraucher und Broker

Wenn der Verbraucher schnell ist, aber lange braucht, um über das Netzwerk empfangene Nachrichten zu bestätigen, liegt das Problem wahrscheinlich an der Latenz oder Netzwerksättigung zwischen dem Verbraucher und dem RabbitMQ-Knoten, mit dem er verbunden ist.

Test: Verbinden Sie den Verbraucher vorübergehend mit dem Broker auf demselben Rechner (localhost), um Netzwerkvariablen auszuschließen. Wenn sich die Leistung drastisch verbessert, konzentrieren Sie sich auf die Netzwerkoptimierung (z. B. dedizierte NICs, Überprüfung zwischengeschalteter Firewalls).

Festplatten-I/O und Auswirkungen der Persistenz

Die Festplattenleistung ist oft die harte Grenze für die Leistung, insbesondere bei Warteschlangen mit hoher Haltbarkeit.

Persistente Nachrichten und Haltbarkeit

Dauerhafte Exchanges und Warteschlangen: Unerlässlich, um Verluste beim Neustart des Brokers zu verhindern, verursachen jedoch Metadaten-Overhead.
Persistente Nachrichten: Als persistent gekennzeichnete Nachrichten müssen auf die Festplatte geschrieben werden, bevor der Broker eine Bestätigung an den Produzenten sendet. Langsame Festplatten führen direkt zu einem langsamen Produzentendurchsatz.

Wenn Ihre Last hauptsächlich aus transienten (nicht persistenten) Nachrichten besteht, stellen Sie sicher, dass die Warteschlange selbst nicht dauerhaft ist, oder, praktischer, markieren Sie die Nachrichten als transient, wenn Datenverlust für diese spezifische Nutzlast akzeptabel ist. Transiente Nachrichten sind viel schneller, da sie im RAM bleiben (vorbehaltlich Speicherdruck).

Spiegelungs-Overhead

In einem Hochverfügbarkeits-Cluster (HA) repliziert die Warteschlangenspiegelung Daten über Knoten hinweg. Obwohl dies für die Fehlertoleranz unerlässlich ist, fügt die Spiegelung eine erhebliche Schreiblast zum Cluster hinzu. Wenn die Festplattenlatenz hoch ist, kann diese Last die I/O-Kapazität sättigen und alle Operationen verlangsamen.

Optimierungstipp: Für Warteschlangen, die einen hohen Schreibdurchsatz erfordern, aber geringfügige Datenverluste während eines Failovers tolerieren können (z. B. Logging-Streams), sollten Sie die Verwendung von ungespiegelten Warteschlangen auf einer Reihe hochverfügbarer Knoten oder die Verwendung von Lazy Queues in Betracht ziehen, wenn die Warteschlangenlänge voraussichtlich extrem groß wird (Lazy Queues verschieben unverbrauchte Nachrichten früher auf die Festplatte, um RAM zu sparen).

Trennung von Broker-Problemen und Anwendungsproblemen

RabbitMQ wird oft für Latenzen verantwortlich gemacht, die woanders ihren Ursprung haben. Eine Webanfrage läuft aus, ein Job wird spät fertig, oder eine nachgelagerte Datenbank ist langsam, und die Warteschlange ist das am einfachsten zu bemerkende Element, da ihre Tiefe sichtbar ist. Bevor Sie den Broker optimieren, entscheiden Sie, ob RabbitMQ langsam ist oder ob RabbitMQ Ihnen nur zeigt, dass die Verbraucher langsam sind.

Beginnen Sie mit drei Zahlen für die betroffene Warteschlange:

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers \
  message_stats.publish_details.rate message_stats.deliver_get_details.rate \
  message_stats.ack_details.rate

Wenn messages_ready wächst, während Verbraucher vorhanden sind und Bestätigungen langsam sind, halten die Verbraucher nicht Schritt. Der Broker ist möglicherweise gesund. Wenn messages_unacknowledged wächst, erhalten Verbraucher Nachrichten, schließen sie aber nicht ab oder bestätigen sie nicht. Wenn Veröffentlichungsbestätigungen langsam werden, während Festplatten- oder Speicheralarme aktiv sind, übt der Broker Gegendruck aus. Wenn die CPU hoch ist und die Verbindungszahlen steigen, könnte das Client-Verhalten die Ursache sein.

Diese Unterscheidung ist wichtig, weil das Hinzufügen von RAM zu RabbitMQ keinen Verbraucher behebt, der zwei Sekunden damit verbringt, für jede Nachricht eine langsame API aufzurufen. Die Erhöhung der Verbraucherreplikate wird keinen Broker beheben, der durch Festplattenschreibvorgänge gedrosselt wird. Die Änderung des Vorabrufs wird keinen Produzenten beheben, der für jede Veröffentlichung eine neue TCP-Verbindung öffnet.

Verbindungs- und Kanalwechsel

Hohe CPU-Auslastung durch RabbitMQ ist oft banal: Zu viele Clients öffnen und schließen wiederholt Verbindungen. Der AMQP-Verbindungsaufbau ist nicht kostenlos. Er umfasst TCP-Setup, optionale TLS-Aushandlung, Authentifizierung, Tuning und Kanalaushandlung. Wenn eine Anwendung für jede Nachricht, jede HTTP-Anfrage oder jeden kurzen Job eine Verbindung öffnet, gibt RabbitMQ CPU für Setup-Arbeiten aus, anstatt Nachrichten zu verschieben.

Überprüfen Sie Verbindungsalter und -anzahlen:

rabbitmqctl list_connections name user peer_host state channels connected_at
rabbitmqctl list_channels connection number user vhost

Wenn Sie einen konstanten Strom kurzlebiger Verbindungen vom selben Dienst sehen, beheben Sie den Client. Halten Sie Verbindungen langlebig. Verwenden Sie Kanäle angemessen. Die meisten Dienste sollten während des Starts eine Verbindung herstellen und bis zum Herunterfahren wiederverwenden, mit Wiederverbindungslogik für Fehler. Erstellen Sie in Webanwendungen keine Broker-Verbindung innerhalb des Request-Handlers, es sei denn, Ihr Framework verfügt über einen sehr bewussten Verbindungspool.

TLS macht den Wechsel teurer. TLS ist für die Produktion in Ordnung, aber wiederholte Handshakes können unter Last sichtbar werden. Die Wiederverwendung von Verbindungen ist immer noch die Lösung.

Vorabruf, der zur Arbeit passt

Vorabruf ist kein magischer Durchsatzregler. Er steuert, wie viele unbestätigte Nachrichten ein Verbraucher halten kann. Der richtige Wert hängt von der Verarbeitungszeit, der Nachrichtengröße und der Fairness zwischen den Verbrauchern ab.

Ein Vorabruf von 1 ist einfach und fair, kann aber Verbraucher unterauslasten, wenn jeder Job kleine Wartezeiten für Netzwerk oder Festplatte hat. Ein Vorabruf von 500 mag in einem Benchmark schnell aussehen, aber ein langsamer Verbraucher kann Arbeit horten und bei einem Absturz die Schmerzen durch erneute Zustellung erhöhen.

Ein praktischer Ausgangspunkt ist zu messen, wie viel Zeit ein Verbraucher pro Nachricht verbringt. Wenn die Arbeit CPU-intensiv ist und jeder Prozess jeweils eine Nachricht verarbeitet, halten Sie den Vorabruf niedrig. Wenn die Arbeit auf einen entfernten Dienst wartet und der Verbraucher die Parallelität intern handhabt, kann ein moderater Vorabruf ihn auslasten. Erhöhen Sie schrittweise und beobachten Sie:

Bestätigungsrate;
messages_unacknowledged;
Verbraucherspeicher;
End-to-End-Latenz;
Anzahl der erneuten Zustellungen nach einem Verbraucherneustart.

Der Test sollte einen Fehlerfall beinhalten. Töten Sie einen Verbraucher, während er unbestätigte Nachrichten hält. Wenn die erneute Zustellung zu einem großen Ausbruch doppelter Arbeit oder langen Stillständen führt, ist der Vorabruf für diese Warteschlange wahrscheinlich zu hoch.

Persistente Nachrichten und die Realität der Festplatte

Persistente Nachrichten und dauerhafte Warteschlangen sind die richtige Wahl für wichtige Arbeiten, aber sie verlagern einen Teil des Engpasses auf den Speicher. Wenn Herausgeber auf Bestätigungen warten, zeigen sich langsame Festplattenschreibvorgänge als langsames Veröffentlichen. Wenn Warteschlangen groß werden, hat RabbitMQ mehr Index- und Speicherarbeit zu erledigen. In geclusterten Setups fügt die Replikation Netzwerk- und Festplattenarbeit hinzu.

Überprüfen Sie die Festplattensymptome vom Betriebssystem aus:

iostat -xz 1
vmstat 1

Hohe I/O-Wartezeit, hohe Festplattenauslastung oder lange Wartezeiten sagen Ihnen, dass der Broker auf den Speicher wartet. Das bedeutet nicht "Persistenz ausschalten". Es bedeutet, dass Sie schnelleren Speicher, weniger unnötige persistente Nachrichten, eine niedrigere Veröffentlichungsrate, effizienteres Batching oder eine Topologie benötigen, die die Arbeit auf Knoten verteilt.

Vermeiden Sie es, RabbitMQ-Datenverzeichnisse auf langsamen Netzwerkfestplatten zu platzieren, es sei denn, Sie haben das genaue Setup getestet. RabbitMQ kümmert sich um die Latenz genauso wie um den Durchsatz. Eine Festplatte, die für Massenkopien von Dateien akzeptabel erscheint, kann für Nachrichten-Workloads dennoch schlecht sein.

Warteschlangentyp und Replikationsentscheidungen

Ältere RabbitMQ-Anleitungen erwähnen oft gespiegelte klassische Warteschlangen. In aktuellen RabbitMQ-Bereitstellungen werden Quorum-Warteschlangen häufig für replizierte dauerhafte Workloads bevorzugt, während klassische Warteschlangen immer noch für nicht replizierte oder weniger kritische Fälle geeignet sind. Die beste Wahl hängt von der RabbitMQ-Version, den betrieblichen Anforderungen und der Arbeitslast ab.

Quorum-Warteschlangen verbessern das Fehlermodell für replizierte dauerhafte Warteschlangen, sind aber nicht kostenlos. Sie replizieren über ein Konsensprotokoll, sodass Schreibvorgänge mehrere Knoten umfassen. Wenn Sie jeden hochvolumigen transienten Ereignisstrom in Quorum-Warteschlangen stecken, können Sie ein Leistungsproblem erzeugen, das Sie nicht brauchten.

Verwenden Sie stärkere Haltbarkeit dort, wo sie dem Geschäftswert entspricht:

Zahlungs-, Bestell-, Bestands- und Audit-Workflows verdienen oft dauerhafte replizierte Warteschlangen;
Cache-Aktualisierungen, Metriken und neu erstellbare Benachrichtigungen benötigen möglicherweise nicht denselben Schutz;
Sehr große Rückstände erfordern möglicherweise eine Designüberprüfung und nicht nur einen größeren Broker.

Der Punkt ist nicht, die Sicherheit zu minimieren. Es geht darum, die höchsten Zuverlässigkeitskosten für Daten zu vermeiden, die neu erstellt werden können, während Nachrichten geschützt werden, die dies nicht können.

Große Nachrichten erschweren alles

RabbitMQ kann große Nachrichten transportieren, aber Warteschlangen sind normalerweise gesünder, wenn Nachrichten klein sind. Eine Nachricht, die ein großes Bild, einen Bericht, ein Archiv oder einen vollständigen Datenbankexport enthält, erhöht den Speicherdruck, den Festplattendruck, die Netzwerkübertragungszeit und die Kosten für die erneute Zustellung.

Speichern Sie für große Nutzlasten die Nutzlast in einem Objektspeicher oder einer Datenbank und senden Sie eine Nachricht, die einen Verweis enthält:

{
  "job_id": "report-2026-05-25-001",
  "object_url": "s3://reports-bucket/report-2026-05-25-001.json",
  "sha256": "..."
}

Der Verbraucher ruft die Nutzlast ab, wenn er bereit ist, sie zu verarbeiten. Dieses Design ist nicht perfekt; jetzt benötigen Sie eine Lebenszyklusbereinigung und Zugriffskontrolle für den Nutzlastspeicher. Aber es hält RabbitMQ auf die Koordination fokussiert, anstatt es zu einem Dateitransportsystem zu machen.

Wenn die CPU hoch ist, aber die Warteschlangen leer sind

Leere Warteschlangen bedeuten nicht immer, dass RabbitMQ im Leerlauf ist. Die CPU kann hoch sein, weil Clients ständig Verbindungen herstellen, sich authentifizieren, nicht routingfähige Nachrichten veröffentlichen, Topologie deklarieren oder mit ineffizienten Mustern abfragen.

Überprüfen Sie die Management-UI oder CLI auf Verbindungswechsel und Kanalanzahlen. Überprüfen Sie Anwendungsprotokolle auf Wiederverbindungsschleifen. Achten Sie auf Clients, die vor jeder Veröffentlichung Exchanges und Warteschlangen deklarieren. Die Topologiedeklaration ist normalerweise idempotent, aber bei sehr hoher Frequenz erhöht sie dennoch die Broker-Arbeit.

Überprüfen Sie auch Plugins. Management, Federation, Shovel, MQTT, STOMP, Tracing und benutzerdefinierte Plugins fügen alle Arbeit hinzu, wenn sie aktiviert und genutzt werden. Deaktivieren Sie ein Plugin während eines Vorfalls nicht blind, aber bestätigen Sie, ob die Last mit der Plugin-Aktivität übereinstimmt.

Eine sicherere Optimierungsroutine

Ändern Sie jeweils eine Sache und zeichnen Sie Vorher-/Nachher-Zahlen auf. Die RabbitMQ-Leistungsoptimierung wird verwirrend, wenn Vorabruf, Verbraucheranzahl, Warteschlangentyp, Persistenz und Hardware alle im selben Deployment geändert werden.

Eine nützliche Routine:

Erfassen Sie Warteschlangenraten, Warteschlangentiefe, unbestätigte Nachrichten, Verbindungsanzahl, CPU, Speicher, Festplatten-I/O und Latenz der Veröffentlichungsbestätigung.
Wählen Sie den wahrscheinlichen Engpass.
Nehmen Sie eine Änderung vor.
Führen Sie dieselbe Arbeitslast aus.
Vergleichen Sie die End-to-End-Latenz, nicht nur den Broker-Durchsatz.

Wenn der Vorfall aktiv ist, wählen Sie zuerst reversible Änderungen: Fügen Sie Verbraucher hinzu, stoppen Sie den Verbindungswechsel, reduzieren Sie die Produzentenrate, leeren Sie einen Rückstand oder verschieben Sie optionale Arbeitslasten. Heben Sie sich Warteschlangentyp-Migrationen und Speicherneugestaltungen für geplante Arbeiten auf, es sei denn, das System ist bereits ausgefallen und Sie haben keinen sichereren Weg.

Zusammenfassung der umsetzbaren Schritte

Befolgen Sie bei hoher CPU-Auslastung oder allgemeiner Langsamkeit diese Checkliste:

Alarme prüfen: Stellen Sie sicher, dass keine Festplatten- oder Speicher-Flusskontrollalarme aktiv sind.
Client-Verhalten überprüfen: Achten Sie auf hohen Verbindungs-/Kanalwechsel oder Clients, die auto-ack unangemessen verwenden.
Verbraucher optimieren: Passen Sie prefetch_count an die tatsächliche Verarbeitungsgeschwindigkeit Ihrer Verbraucher an.
Festplattengeschwindigkeit überprüfen: Stellen Sie sicher, dass der Speicher-Backend schnell genug für Ihre Persistenz- und Replikationsanforderungen ist.
Erlang profilieren (Fortgeschritten): Verwenden Sie Erlang-Tools (z. B. observer), um zu bestätigen, ob die CPU für die Protokollverarbeitung oder die interne Warteschlangenverwaltung aufgewendet wird.

Durch die systematische Analyse der Ressourcennutzung auf den Ebenen Betriebssystem, Broker und Anwendung können Sie die Ursachen von RabbitMQ-Leistungsproblemen effektiv isolieren und beseitigen.