Beim Besuch meiner Site erhalte ich manchmal eine Reihe von 500-Fehlern bei allen JavaScript-Dateien, meist beim ersten Seitenaufruf (auch wenn die Dateien bereits zwischengespeichert sein sollten oder sollten). Manchmal steht dort NS_ERROR_CORRUPPTED_CONTENT.
Mein Theme wird ordnungsgemäß geladen (der Hintergrund wurde zur besseren Sichtbarkeit entfernt), aber außer dem sollte es nichts geben, das dies verursacht. Das Problem löst sich, wenn man 30 Sekunden wartet und die Seite neu lädt.
Meine Site ist auf dem fast neuesten Commit (2 zurück) und in den Logs gibt es nichts Ungewöhnliches. Mein Disk-Cluster ist gesund. Was verursacht dies und wie kann ich es beheben?
Meine erste Vermutung war ein Problem mit der Cloudflare-Optimierung – stelle sicher, dass Rocket Launcher deaktiviert ist (was wahrscheinlich der Fall ist, aber einen Check wert ist).
Außerdem denke ich, dass du die S3-Bucket-Objektspeicherung über Cloudflare R2 konfigurieren solltest, wenn du die von dir verwendete Hardware weiter nutzen möchtest.
Du hast in unserem Chat erwähnt, dass du einige gespendete ältere SSDs verwendest, die du kurz vor dem Beginn dieses Problems installiert hast, was ein Indiz ist – die Dell-Firmware meldet sie als defekt, aber smartctl zeigt sie als ok an. Ich denke, die Dell-Firmware blinkt orange, weil sie hohe Latenz und unregelmäßige E/A-Antworten oder eine nicht unterstützte Firmware erkennt. Discourse fordert von den Laufwerken, Dutzende von kompilierten JavaScript-Dateien alle gleichzeitig zu lesen, und ältere, nicht unterstützte SSDs können unter diesem plötzlichen E/A-Burst versagen. Der Storage-Controller hängt beim Abrufen der Daten und timeoutt nach genau 30 Sekunden – ein häufiger Standard-SCSI-/Block-Geräte-Timeout.
Da die Laufwerke für 30 Sekunden hängen, stürzt Discourse Rails/Nginx ab oder timeoutt beim Abrufen der Dateien und wirft einen 500-Fehler. Cloudfang fängt wahrscheinlich die 500-Fehler ab und wendet die falschen Header an und leitet sie an den Browser weiter, was den NS_ERROR_CORRUPTED_CONTENT verursacht, den du siehst.
Ersetze diese SSDs, oder wenn du sie unbedingt verwenden musst, verwende dann einen Objektspeicher-Bucket, um Discourse-Assets und Uploads auszulagern – du kannst den Cloudflare R2 kostenlosen S3-kompatiblen Dienst verwenden (ich habe das und es funktioniert gut). Dann muss dein Server nicht Tausende kleiner Dateien von diesen fehlerhaften SSDs lesen, da er den Hardware-Engpass für Web-Assets umgeht.
Das wusste ich bisher nicht, und es würde das Problem definitiv erklären. In jedem Handbuch für den Server heißt es, dass eine blinkende orangefarbene LED bedeutet, dass das Laufwerk zu 100 % defekt ist. Wenn diese Laufwerke jedoch I/O-Timeouts verursachen oder sich auf andere Weise seltsam verhalten, ergibt es für mich Sinn, warum Discourse den Fehlercode 500 ausgibt.
Ich bin sehr gegen Abonnementmodelle, und langfristig macht es wahrscheinlich Sinn, den Bissen zu schlucken und neue SSDs zu kaufen, sobald sie wieder erschwinglich sind. Wenn ich 150 für neue SSDs für diesen Server ausgeben würde, den ich für immer besitze, würde ich das viel lieber tun, als Cloudflare für den Rest der Ewigkeit 5 pro Monat zu zahlen. Wenn es kostenlos ist (wie du sagst), werde ich es vielleicht als vorübergehende Alternative in Betracht ziehen, während ich darauf warte, dass diese KI-Blase platzt
