Sehr langsames Sidekiq-Problem mit großer Warteschlange aufgrund massiver Anzahl ungelesener Benutzerbenachrichtigungen

Unterstützung Installation
1

Ich habe ein Problem mit Sidekiq.

Es verarbeitet Jobs über die Sidekiq-Web-Oberfläche überwiegend erstaunlich schnell. Gelegentlich scheint es jedoch überlastet zu sein und wird extrem langsam. Es läuft dann mit etwa 1–5 % seiner normalen Geschwindigkeit und erholt sich nicht, es sei denn, ich leere Redis – obwohl die Serverressourcennutzung in Ordnung bzw. gering ist.

Es sieht so aus, als würde es, sobald die Warteschlange eine bestimmte Größe erreicht, zum Stillstand kommen und sich drastisch verlangsamen. Dadurch wächst die Warteschlange noch weiter. Ich rate hier zwar nur, vielleicht ist die Warteschlange auch nur groß, weil sie aus einem anderen Grund verlangsamt wurde.

Dieses GIF beschreibt, wie es für mich aussieht.

simpsons_EDIFIL20161024_0001
simpsons_EDIFIL20161024_0001425×305 965 KB

Es stehen ausreichend Serverressourcen zur Verfügung, die CPU-Auslastung ist aktuell sehr niedrig – unter 10 %. Auch RAM und SSD sind ausreichend vorhanden. Der Server verfügt über 16 CPU-Kerne mit 32 Threads. Ich habe versucht, zwischen 8 und 14 Unicorn-Sidekiq-Prozesse zu starten. Ich habe es auch mit 20 versucht, doch das führte zu vielen 5xx-Fehlern.

Ich konnte langsame Jobs, die auf dem Reiter „Busy“ der Sidekiq-Web-Oberfläche angezeigt wurden, beschleunigen, indem ich

(durch Hinzufügen von vm.overcommit_memory = 1 in die Datei /etc/sysctl.conf und einem Neustart) sowie durch Reduzierung der Unicorn-Sidekiq-Prozesse auf 8 (von ursprünglich 12) verwendet habe.

Es läuft jedoch immer noch langsam. Gestern habe ich dies im Redis-Log gesehen (die einzige andere Warnung betraf das fehlende Setzen von overcommit_memory auf 1, was ich oben bereits geändert habe):

# WARNING: /proc/sys/net/core/somaxconn ist auf den niedrigeren Wert von 128 gesetzt

^ Hat jemand diese Warnung oben bereits behoben?

Wie auch immer, falls jemand Ideen hat, was die Ursache und/oder Lösung sein könnte – bitte geben Sie mir Bescheid. Ich wäre Ihnen dankbar.

Es wäre wirklich großartig, dieses Problem dauerhaft zu lösen, statt es nur durch Leeren von Redis zu umgehen.

Hier ist ein Screenshot dessen, was ich auf dem Sidekiq-Dashboard sehe:

Screen Shot 2020-02-05 at 6.52.24 PM
Screen Shot 2020-02-05 at 6.52.24 PM2386×1688 1.02 MB

Und einige Screenshots der Jobs im Reiter „Busy“:

Screen Shot 2020-02-05 at 6.42.03 PM
Screen Shot 2020-02-05 at 6.42.03 PM1214×2178 450 KB

Außerdem: Weiß jemand, ob es sicher ist, diese Option zu verwenden? Das Löschen der Warteschlange mit niedriger Priorität über die Sidekiq-Web-Oberfläche?

Screen Shot 2020-02-05 at 6.47.18 PM
Screen Shot 2020-02-05 at 6.47.18 PM2396×492 89.9 KB

2

Update: Ich habe die Warteschlange mit niedriger Priorität problemlos gelöscht, die Verarbeitungsgeschwindigkeit der Jobs ist jedoch unverändert geblieben.

3

Hast du Metriken darüber, wie lange deine Jobs dauern? Es sieht so aus, als hättest du eine enorme Anzahl an Konflikten bei deinen PostAlert-Jobs, während andere schnell abgeschlossen werden.

4

Nach meinen Beobachtungen in der Sidekiq-Web-Oberfläche: Ja, Sie haben recht, andere Jobs scheinen schnell abgeschlossen zu werden, mit Ausnahme von:

Jobs::PostAlert – 0 bis 3 Minuten, wobei die meisten im Bereich von 0 bis 1 Minute liegen.
Jobs::ProcessPost – 0 bis 21 Sekunden.

5

Ist Ihr SMTP-Server langsam?

6

Ich verwende Amazon SES zum Versenden und habe auch den Mail-Empfänger für den Empfang von VERP konfiguriert.

Das auf SES angezeigte Sendelimit beträgt 25 E-Mails pro Sekunde. Ist das zu langsam? Ich kann wahrscheinlich eine Erhöhung beantragen.

Jetzt, wo Sie es erwähnen, habe ich eine Korrelation festgestellt: Das Problem trat an einem Tag auf, an dem eine ungewöhnlich große Anzahl von Digest-E-Mails versendet wurde (viele Digest-E-Mails wurden aufgrund eines früheren Konfigurationsfehlers an einem einzigen Tag gebündelt).

7

An wie viele Nutzer versenden Sie E-Mails? Wie sehen die Mailmengen aus?

8

Unklar, wie viele Benutzer per E-Mail erreicht werden. Die Statistik für aktive Benutzer der letzten 30 Tage im Admin-Dashboard beträgt 60,8 Tausend – vielleicht ist das ein Hinweis? Hier sind die Versandstatistiken von SES (Grenze von über 100.000 pro 24 Stunden):

Screen Shot 2020-02-06 at 1.47.59 PM
Screen Shot 2020-02-06 at 1.47.59 PM1382×818 83.4 KB

9

Update: Das SES-Sendelimit pro Sekunde wurde von 25 auf 50 erhöht. Jetzt können bis zu 180.000 E-Mails pro Stunde versendet werden (obwohl das tägliche Gesamtlimit bei etwas mehr als 100.000 liegt). Die Verarbeitungsgeschwindigkeit der Sidekiq-Jobs scheint sich jedoch nicht verbessert zu haben.

10

Wir hatten vor ein paar Jahren ein Problem, bei dem Benutzer 10.000 ungelesene Benachrichtigungen hatten, was die Abfragen für Benachrichtigungen und dadurch auch den PostAlert-Job verlangsamt hat.

Wir haben einen Schutzmechanismus eingeführt, damit dies nicht mehr so häufig vorkommt, aber es könnte in Ihrer Umgebung andere Leistungseigenschaften aufweisen.

Gibt es Benutzer, die Kategorien abonnieren, denen die Anzahl der Benachrichtigungen egal ist?

Können Sie die maximale Anzahl ungelesener Benachrichtigungen pro Benutzer in Ihrer Datenbank überprüfen?

11

Also habe ich die Warteschlange für niedrig priorisierte Aufgaben erneut geleert und sie ein paar Tage sich selbst überlassen (seit meinem letzten Update gab es keine Änderungen) – sie hat sich nicht sofort beschleunigt, und es haben sich schnell gestaute Aufgaben angesammelt, aber es scheint sich mit der Zeit von selbst behoben zu haben. Die Verarbeitung der Aufgaben läuft jetzt blitzschnell. :slight_smile: Bei einem Abfrageintervall von 20 Sekunden sehe ich in den letzten paar Minuten eine Rate von 55 bis 140 Aufgaben pro Sekunde. Auch der Tageswert sieht gesund aus, keine Stauung der Warteschlange.

Vielen Dank für die Hilfe @Falco @supermathie @Stephen, ich habe das sehr zu schätzen gewusst!

Bezüglich Ihrer Fragen bin ich mir nicht sicher, wie ich diese prüfen soll. Ich würde gerne nachschauen (bräuchte dafür etwas Anleitung) und die Informationen bereitstellen, falls es noch hilfreich ist. Etwas möglicherweise Relevantes ist, dass ich die Einstellung „Maximale E-Mails pro Tag pro Benutzer

12

Ich habe mich vielleicht zu früh gefreut. Sidekiq-Jobs laufen derzeit mit etwa 1 bis 3 pro Sekunde bei einer Warteschlange von 8,81 Millionen.

:philosoraptor:

Screen Shot 2020-02-10 at 6.43.33 PM
Screen Shot 2020-02-10 at 6.43.33 PM1208×3142 679 KB

13

Wann hast du zuletzt aktualisiert? Ich habe vor ein paar Tagen einige Leistungsverbesserungen für den PostAlert-Job vorgenommen:

Einige unserer sehr großen Seiten hatten Leistungsprobleme bei Kategorien, in denen viele Personen den „ersten Beitrag beobachten“. Dieser Commit hat das Problem auf unserem Hosting behoben, sodass es möglich ist, dass er auch deiner Seite helfen könnte.

14

Super! Ich aktualisiere gerade. Der letzte Update war vor etwa 10 Tagen (tests-passed). Ich werde das Ergebnis beobachten und sehen, ob es eine Verbesserung gibt, und dann Rückmeldung geben. Danke!

15

Update: Leider keine unmittelbaren Geschwindigkeitsverbesserungen seit dem Update. Wir werden sehen, ob es sich mit der Zeit verbessert.

16

Update: Immer noch langsam und die Warteschlange wächst. Über ‘top’ sind viele Postmaster-Prozesse zu sehen. Die gesamte CPU-Auslastung liegt bei ca. 85 % (32 Kerne), wobei der Großteil davon vom Postmaster stammt. Das ist interessant, da die CPU-Auslastung heute Morgen noch bei 20–35 % lag (Sidekiq war zu diesem Zeitpunkt ebenfalls noch langsam). Verwandt: Primary Postgres database process (postmaster) eating all CPU - #5 by pfaffman

17

Meinen Sie, dass diese Redis-Warnungen damit zusammenhängen könnten? Sie werden während des Neuaufbaus der App angezeigt:

# WARNUNG: Die TCP-Backlog-Einstellung von 511 kann nicht durchgesetzt werden, da /proc/sys/net/core/somaxconn auf den niedrigeren Wert 128 gesetzt ist.

# WARNUNG: Die Unterstützung für Transparent Huge Pages (THP) ist in Ihrem Kernel aktiviert. Dies kann zu Latenz- und Speichernutzungsproblemen mit Redis führen. Um dieses Problem zu beheben, führen Sie als root den Befehl 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' aus und fügen Sie ihn Ihrer Datei /etc/rc.local hinzu, damit die Einstellung nach einem Neustart erhalten bleibt. Redis muss nach der Deaktivierung von THP neu gestartet werden.

Hat jemand diese Fehler für eine Docker-Installation bereits behoben?

Ich habe bereits vm.overcommit_memory = 1 in /etc/sysctl.conf hinzugefügt, um die Warnung zur Speicherüberbelegung zu beheben.

18

Also, ich habe die Warnung zu Transparent Huge Pages (THP) behoben, indem ich einfach als root echo never > /sys/kernel/mm/transparent_hugepage/enabled ausgeführt habe. Ich habe es noch nicht in rc.local für die Persistenz aufgenommen, nur zum Testen. Ich habe einen Discourse-Rebuild durchgeführt, die Performance ist etwa gleich geblieben – vielleicht eine leichte Verbesserung.

Ich bin mir jedoch nicht sicher, wie ich diese Warnung beheben soll:
# WARNING: Die TCP-Backlog-Einstellung von 511 kann nicht erzwungen werden, da /proc/sys/net/core/somaxconn auf den niedrigeren Wert von 128 gesetzt ist.

Einige Leute sagen, dass Docker trotzdem den Wert 128 verwendet, selbst wenn der Systemwert höher gesetzt ist, z. B. über einen Leitfaden wie diesen: Performance tips for Redis Cache Server – Tech and Me

19

Ich denke, es könnte eine gute Idee sein, bestimmte UNICORN_SIDEKIQs speziell für die Warteschlange mit niedriger Priorität zuzuweisen.

Es scheint, als würden Aufgaben mit der Standardpriorität, also beispielsweise PostAlert, ziemlich langsam abgearbeitet. Sobald sich bei diesen langsamen Standardaufgaben ein Rückstau bildet, wächst die Warteschlange mit niedriger Priorität (mit Aufgaben, die deutlich schneller erledigt werden könnten) stark an, da anscheinend kaum eine davon abgeschlossen wird. Ich vermute, dass dieses Anwachsen die gesamte Verarbeitung der Warteschlangen für alle Aufgaben verlangsamt. Ich glaube, dies könnte auch die starken Schwankungen bei der Anzahl der Jobs pro Sekunde erklären.

Weiß jemand, ob es möglich ist, UNICORN_SIDEKIQs in der app.yml-Datei (oder auf andere Weise) bestimmten Prioritätsaufgaben zuzuweisen?

20

[quote=“markersocial, post:16, topic:140716”]
Viele Postmaster-Prozesse über „top