Wir haben im Admin-Bereich einige Ratschläge bezüglich unserer Sidekiq-Warteschlangen-Jobs erhalten – wir haben fast 200.000 Jobs in der Warteschlange und sind uns nicht sicher, wie wir das Problem lösen können. Wir verwenden Version 3.2.0.
Die Jobs befinden sich alle in der Warteschlange ultra_low und scheinen der Job Jobs::ProcessPost zu sein. Sie scheinen alle ähnlich zu sein wie dieser:
Vor zwei Tagen lag der Wert bei etwa 195.000; jetzt ist er auf 211.000 gestiegen. Ich könnte wirklich Ratschläge gebrauchen, was ich mir ansehen und wie ich dieses Problem lösen kann.
Wir haben 5 tote Jobs bemerkt, die so aussehen (IP-Adressen unkenntlich gemacht):
Jobs::HandledExceptionWrapper: Wrapped Errno::ENETUNREACH: Failed to open TCP connection to x.x.x.x:443 (Network is unreachable - connect(2) for "x.x.x.x" port 443)
Die Adresse ist für einen Server, der sich in der Infrastruktur befindet, aber nicht von den Foren genutzt wird (es ist ein Quellcode-Repository-Server). Ich sehe nirgendwo in der Konfiguration, wo dieser Host überhaupt referenziert wird, daher bin ich mir nicht sicher, warum er glaubt, eine Verbindung zu diesem Host herstellen zu müssen. Aber ich frage mich, ob dies mit der wachsenden Zahl von enqueued Jobs in der ultra_low-Warteschlange zusammenhängt.
Weitere 7.000 Aufträge wurden in den letzten ~23 Stunden in die Warteschlange gestellt.
Dies verzögert auch einige Implementierungsänderungen – automatisches Schließen und Hinzufügen des Solutions-Plugins (möchte einfach keine Änderungen vornehmen, die davon betroffen sein könnten oder wenn dies durch eine so bedeutende Änderung der Systemkonfiguration noch verschlimmert wird).
Die 7.000 hinzugefügten Aufträge stimmen nicht mit der Anzahl der neuen Beiträge überein, die wir am letzten Tag hatten, daher bin ich mir nicht sicher, was dies überhaupt antreibt.
Welche weiteren Informationen wären hilfreich, um dieses Problem zu lösen?
Ich kann nicht helfen, außer mit dem Vorschlag, dass mehr Antworten und mehr Likes für Beiträge in diesem Thread ihm die Aufmerksamkeit verschaffen könnten, die er zu verdienen scheint!
Bearbeiten: Ich habe dieses Problem auch im Thread über die Standardreihenfolge nach Beliebtheit erwähnt, die meiner Meinung nach diesen Thread sehr effektiv und sehr unhilfreich verbirgt.
Ich gehe davon aus, dass wir dies von der Konsole aus tun müssen – ich muss jemanden mit Zugriff bitten, dies zu tun; können Sie mir sagen, woher ich es abrufen kann, damit ich es an die Person mit Zugriff weitergeben kann?
Ah, danke für den Hinweis. Hier ist, was es zeigt (IP-Adresse unkenntlich gemacht):
Nachricht (10 Kopien gemeldet)
Job-Ausnahme: TCP-Verbindung zu x.x.x.x:443 konnte nicht geöffnet werden (Netzwerk nicht erreichbar - connect(2) für "x.x.x.x" Port 443)
Backtrace
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `initialize'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `open'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `block in connect'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:186:in `block in timeout'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:193:in `timeout'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1601:in `connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect'
Mir ist aufgefallen, dass dies anders ist als die Ausgabe im Tab “Backtrace”, aber diese Ausgabe sieht nicht wie ein Backtrace aus, sondern das, was hier als Kopie (über die Kopierschaltfläche) vorhanden ist, schon. Lassen Sie mich wissen, ob weitere Informationen für diese hier benötigt werden.
Ich werde auch sehen, ob ich auf diese Weise weitere Informationen über die über 220.000+ in der Warteschlange befindlichen Aufgaben erhalten kann - ich war mir des /logs-Endpunkts nicht bewusst.
Das war alles, was die Schaltfläche „Kopieren“ erfasst hat – hier ist die vollständige Ausgabe aus dem Tab „Backtrace“:
net-http-0.4.1/lib/net/http.rb:1603:in `initialize'
net-http-0.4.1/lib/net/http.rb:1603:in `open'
net-http-0.4.1/lib/net/http.rb:1603:in `block in connect'
timeout-0.4.1/lib/timeout.rb:186:in `block in timeout'
timeout-0.4.1/lib/timeout.rb:193:in `timeout'
net-http-0.4.1/lib/net/http.rb:1601:in `connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect'
net-http-0.4.1/lib/net/http.rb:1580:in `do_start'
net-http-0.4.1/lib/net/http.rb:1569:in `start'
net-http-0.4.1/lib/net/http.rb:1029:in `start'
/srv/www/vhosts/discourse/lib/final_destination.rb:551:in `safe_session'
/srv/www/vhosts/discourse/lib/final_destination.rb:486:in `safe_get'
/srv/www/vhosts/discourse/lib/final_destination.rb:170:in `get'
/srv/www/vhosts/discourse/lib/retrieve_title.rb:90:in `fetch_title'
/srv/www/vhosts/discourse/lib/retrieve_title.rb:12:in `crawl'
/srv/www/vhosts/discourse/lib/inline_oneboxer.rb:76:in `lookup'
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:310:in `process_inline_onebox'
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:39:in `block in post_process_oneboxes'
/srv/www/vhosts/discourse/lib/oneboxer.rb:214:in `block in apply'
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `block in each_onebox_link'
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:235:in `block in each'
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `upto'
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `each'
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `each_onebox_link'
/srv/www/vhosts/discourse/lib/oneboxer.rb:213:in `apply'
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:9:in `post_process_oneboxes'
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:42:in `block in post_process'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:38:in `post_process'
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:28:in `block in execute'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:8:in `execute'
/srv/www/vhosts/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/srv/www/vhosts/discourse/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/srv/www/vhosts/discourse/app/jobs/base.rb:284:in `block in perform'
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `each'
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `perform'
sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/srv/www/vhosts/discourse/lib/sidekiq/pausable.rb:132:in `call'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/rails.rb:14:in `block in call'
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap'
activesupport-7.0.8/lib/active_support/reloader.rb:72:in `block in wrap'
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap'
activesupport-7.0.8/lib/active_support/reloader.rb:71:in `wrap'
sidekiq-6.5.12/lib/sidekiq/rails.rb:13:in `call'
sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
Entschuldigung, dass ich nicht die gesamte Ausgabe erfasst habe. Ich dachte, es sei seltsam, dass die Schaltfläche „Kopieren“ nicht mehr erfasst hat, aber ich habe fälschlicherweise angenommen, dass sie das Notwendige erfasst hat.
Das bedeutet, dass es einen oder mehrere Inline-Links mit einer URL gibt, die zur IP-Adresse Ihres Servers aufgelöst wird. Wenn dieser Server nicht erreicht werden kann, protokollieren wir den Fehler, aber der Markdown-Kochprozess sollte fortgesetzt werden, ohne das „Link-Verschönern“ durchzuführen, das der Inline-Onebox auslösen würde.
Eine weitere Frage ist, wie haben Sie Discourse installiert? Dies sieht nicht nach einer Installation aus, die unserer offiziellen Installationsanleitung gefolgt ist.
Ich habe die Installation nicht selbst durchgeführt – ich glaube, unser Infrastrukturteam hat sie über eine CI/CD-Pipeline bereitgestellt, aber ich kenne die Details nicht.
Es scheint, dass die fehlgeschlagenen Nachrichten kein Problem darstellen – die große Anzahl von Aufgaben in der Warteschlange „ultra_low“ scheint hier das größere Problem zu sein. Ich finde nichts in den Protokollen (was für mich eigentlich Sinn ergibt, da der Job noch nicht tatsächlich ausgeführt wurde).
Ich sehe keine Option, sie in der Web-Benutzeroberfläche zum Ausführen zu zwingen – ich habe die Option, alle Argumente anzuzeigen oder die Aufgaben einzeln zu löschen.
Hm. Wir haben keine in der Warteschlange auf dem Forum, bei dem ich helfe, daher entschuldige ich mich dafür, dass ich versucht habe, eine Schaltfläche vorzuschlagen, die nicht da ist.
Verweis auf die Wiederholungsseite, wofür ich dachte, es wäre auf der Warteschlangenseite
Keine Sorge – ja, diese hier erscheinen auf der Enqueued-Seite (unter /sidekiq/queues/ultra_low).
Wenn ich mir die Queues-Seite selbst ansehe, stelle ich fest, dass die Latenz der ultra_low-Queue etwa ein Jahr beträgt. Das geht also offenbar schon eine Weile so, und wir haben erst kürzlich eine Benachrichtigung darüber im Dashboard erhalten.
Wenn ich die Jobs::ProcessPost-Jobs genauer untersuche, scheint es, dass die post_id-Werte herunterzählen – ich habe die Post-IDs aus dem ersten und letzten Job in der Warteschlange abgerufen, und die Daten entsprechen einem Post von 2012 (vor der Migration zu Discourse – aber mit einem ‘updated_at’-Zeitstempel von 2022, was unser Migrationsdatum gewesen sein könnte – das muss ich noch überprüfen) und der letzte war vom Januar 2023.
Ich sehe gelegentlich Jobs zur Generierung von Topic-Thumbnails, aber diese sind ziemlich selten. Bei über 8.800 Seiten Warteschlange kann ich nicht alles überprüfen, aber es sieht so aus, als ob hauptsächlich Jobs::ProcessPost-Sachen hinzugefügt werden, und es geht rückwärts durch jeden einzelnen Reply und jeden ursprünglichen Post zu einem Topic (der früheste war mitten im Thread, der neueste war ein Root-Post in einem Topic).
Ich habe ein Backup vom Produktionssystem gezogen und es in eine lokal eingerichtete Testumgebung geladen. Die Warteschlange scheint sich überhaupt nicht aufzustauen – tatsächlich sehe ich Job::ProcessPost überhaupt nicht in dieser Warteschlange, während ich sie beobachte (ich werde sie einrichten und das System einfach von selbst laufen lassen, während ich den Warteschirm aufzeichne, um zu sehen, ob ich sie nur verpasse).
Dies führt zu zwei Fragen:
Was löst den ProcessPost-Job aus?
Was würde dazu führen, dass die ultra_low-Warteschlange nicht verarbeitet wird?
Ich bin kein Experte für die in Discourse verwendeten Technologien (Redis, Sidekiq oder Rails), aber ich bin sehr gut darin, in meiner Sandbox-Umgebung zu lernen und Dinge auszuprobieren, um zu verstehen, was ich jemanden in der Produktion anschauen lassen muss.
Die gute Nachricht ist, dass dieses Problem (noch) keine Probleme für unsere Benutzer zu verursachen scheint. Eine dritte Frage wäre, ob das einfache Leeren dieser Warteschlange helfen würde oder ob das Nichtzulassen, dass diese Jobs ausgeführt werden, dem System in irgendeiner Weise schaden würde.
ETA: Ich habe gerade eine Charge von Jobs in meiner Testumgebung gesehen, und sie werden dort verarbeitet. Es scheint also nur, dass die Warteschlange aus irgendeinem Grund auf dem Produktionsserver nicht verarbeitet wird.
Es scheint, dass wir eine Lösung gefunden haben. Die von uns verwendete Installation stammt aus dem für openSUSE erstellten Paket (die Instanz, über die wir gesprochen haben, ist die Instanz für die openSUSE-Foren) – sie verwendet im Wesentlichen den Installationsprozess „Build from Source“.
Wir haben eine Entwicklungs- und Produktionsumgebung, und die ultra_low-Warteschlange wurde versehentlich aus der Sidekiq-Konfiguration der Produktionsumgebung ausgeschlossen. Dies wurde korrigiert, und es scheint, dass die Warteschlange sich leert und die Latenz von 1 Jahr auf 4 Wochen gesunken ist.
Ich denke, wir können dies jetzt als gelöst betrachten. Ich schätze die Beiträge der Leute, die einige gegeben haben – das hat mir geholfen, den richtigen Weg zu finden, um herauszufinden, was das Problem war.
