Entschuldigung, falls dies nicht die richtige Kategorie dafür ist.
Ich bewerte Discourse und der VersionCheck Job schlägt in meiner Umgebung fehl.
Mir ist aufgefallen, dass fehlgeschlagene Jobs sich in Sidekiq ansammeln und wahrscheinlich nach den standardmäßigen 25 Wiederholungsversuchen in den Bereich “dead” verschoben werden (gemäß https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry).
Ich weiß, dass ich untersuchen muss, was zum Scheitern führt, aber der Punkt ist hier: Macht es Sinn, diese Jobs dort zu belassen? Ist es nicht besser, fehlgeschlagene Versionsprüfungen einfach zu verwerfen und auf die nächste Jobausführung zu warten?
Im Moment habe ich mehr als 80 VersionCheck-Jobs, die auf eine Wiederholung warten, und das erscheint mir wie eine Verschwendung von Ressourcen (wahrscheinlich wenig, aber immer noch eine Verschwendung)…
Nach meinen Recherchen würde das Hinzufügen von sidekiq_options retry: false zu app/jobs/scheduled/version_check.rb dies beheben.
Wie hast du es installiert? Gibt es Grund zu der Annahme, dass du Netzwerkprobleme hast? RAM?
Du könntest Recht haben, aber da du der Einzige bist, der dies meldet (zumindest bisher), hat es keine Priorität auf der Liste der Optimierungen. Es ist sinnvoll, es nach einem Versuch fehlschlagen zu lassen, würde ich denken.
Vor ein paar Wochen (Ende Oktober) gab es ein Problem mit dem Versionsprüfungsjob, das jetzt behoben ist. Wenn Sie ein Upgrade im Terminal durchführen (./launcher rebuild app), sollte es in Ordnung sein.
Ich benutze die Standard-Docker-Installation auf einer EC2-Instanz.
Ich befinde mich in einer Unternehmensumgebung, daher gibt es viele Firewalls, Proxys und Sicherheits-Scanner zwischen der Instanz und dem Internet. In den Protokollen sehe ich einen Fehler “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”, also verweigert wahrscheinlich eine Firewall die Anfrage an einem bestimmten Punkt… Ich versuche noch zu verstehen, wie Discourse diese Versionsprüfungen durchführt, damit ich sie manuell reproduzieren und mehr Details erhalten kann.
Das verstehe ich vollkommen. In der Vergangenheit habe ich mit GitLab gearbeitet und viele Probleme gesehen, bei denen volle Sidekiq-Warteschlangen zu Leistungseinbußen und anderem seltsamen Verhalten führten, daher schrillen bei mir jedes Mal die Alarmglocken, wenn ich so etwas sehe.
Ja… Das Upgrade im Terminal oder über die GUI funktioniert einwandfrei (wöchentlich durchgeführt). Das einzige Problem in diesem Fall ist, dass der Hauptadministratorbildschirm nicht die neueste Version anzeigt und immer sagt, dass ich eine veraltete Version ausführe.
Discourse wird für Aufgaben wie die Überprüfung von Versions-Upgrades, das Abrufen von Benutzer-Avataren, das Herunterladen von Remote-Bildern in den lokalen Speicher und allgemeines Oneboxing das Internet kontaktieren. Wenn die Instanz vom Internet getrennt ist, wird es tatsächlich zu einigen Problemen kommen.
Ja! Ich mache das jede Woche, bis ich eine Lösung gefunden habe.
Aus diesem Grund musste ich das Oneboxing aufgeben. Vorerst kann ich diesem Server keinen vollständigen Internetzugang gewähren. github.com/* ist bereits erlaubt, aber wahrscheinlich verwendet dieser Versioncheck-Job eine andere URL, um dies zu tun.
Was ich tun würde, ist einfach SiteSetting.version_checks auszuschalten, das discourse_docker-Plugin zu entfernen und Upgrades über die Befehlszeile durchzuführen.
Aber hier, wenn Sie https://api.discourse.org/api öffnen können, dann sind Sie wahrscheinlich in Ordnung.
