Wir haben den RAM erhöht und die Datenbank neu aufgebaut, aber das Problem besteht weiterhin.
Ich möchte fragen, ob den Entwicklern dieses Problem bekannt ist.. Danke!
Gibt es eine schnelle Lösung, die ich als Admin durchführen kann? Vielleicht eine längere Zeitüberschreitung?
Bin mir nicht sicher. Es scheint wirklich, als würde ein längeres Timeout helfen. Das passiert viel häufiger in stark frequentierten Threads, sodass es sich anfühlt, als gäbe es eine Stichproben- oder Scannprozedur, die zu lange dauert.
Wenn ich herausfinde, wie man das umsetzt, melde ich mich. Ich würde es verdoppeln.
Ja, das Problem besteht auch mit 2.5.0.beta2.
Hast du das Discourse-Setup nach der RAM-Änderung ausgeführt? Es gibt Einstellungen, die aktualisiert werden müssen, um den RAM voll auszunutzen.
Ich bin mir nicht sicher, da die Umsetzung bei einer anderen Person liegt. Aber ich werde ihn darauf hinweisen, dass dies erledigt werden muss, um den Prozess abzuschließen. Vielen Dank!
Hallo,
bei der Verschiebung von Beiträgen erhalte ich häufig 502-Fehler.
Haben Sie einen Plan, um dieses Szenario zu verbessern?
Vielen Dank
Hallo, konntest du es finden? Es wäre großartig, den Timeout für uns mit wenig Arbeitsspeicher in app.yml-Umgebungsvariablen oder Discourse-Site-Einstellungen parametrisieren zu können.
Vielleicht eine blöde Frage?
Wenn du so viele Beiträge verschiebst, wird dieser Prozess dann von Sidekiq verwaltet?
Entschuldigung, ich habe den Code nicht durchsucht…
Update
Ich habe einen kurzen Blick in die Ruby-Codebasis geworfen, und ja: Wenn die Funktion zum Verschieben von Beiträgen aufgerufen wird, werden die Jobs mit enqueue_jobs() in die Warteschlange gestellt.
Da ich kein Discourse-Entwickler bin, scheint es einem oberflächlichen Code-Betrachter, dass Probleme im Zusammenhang mit Verzögerungen, Fehlern oder Zeitüberschreitungen beim Verschieben von Beiträgen direkt mit der Leistung und Konfiguration von Sidekiq zusammenhängen.
Ich habe vor einigen Tagen versucht zu untersuchen, wie Discourse Sidekiq auf Systemebene nutzt, konnte aber keine „Kurzversion für Anfänger
Update:
Auf einen Hinweis von einem Leiter in einem anderen Thread hin haben wir alle Plug-ins außer „Wer ist online
Welche Plugins genau hast du deaktiviert?
Sehr wahrscheinlich ein Blödsinn. Ich vermute, es hat Hooks, die beim Verschieben eines Beitrags ausgelöst werden.
Gut zu wissen. Danke. Und Respekt an @featheredtoast für die Reparatur.
Meine Community hat kürzlich begonnen, das 502-Fehlerproblem beim Verschieben von Beiträgen zu erleben, insbesondere zwischen großen Threads. Ich hatte keine benutzerdefinierten Plugins installiert. Nach dem Rat aus einem anderen Discourse-Thread habe ich unicorn_workers auf 10 und db_shared_buffers auf 4096 MB erhöht, aber das hat die Situation nicht verbessert. Unten finden Sie das ./discourse-doctor-Protokoll unseres Forums. Ich hoffe auf einige Hinweise. Vielen Dank!
==================== DOCKER-INFO ====================
DOCKER-VERSION: Docker version 17.10.0-ce, build f4ffd25
DOCKER-PROZESSE (docker ps -a)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ddfb2222fd64 local_discourse/app "/sbin/boot" 10 days ago Up 10 days 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp app
ddfb2222fd64 local_discourse/app "/sbin/boot" 10 days ago Up 10 days 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp app
Der Discourse-Container app läuft.
==================== PLUGINS ====================
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/discourse/discourse-solved.git
Keine nicht-offiziellen Plugins erkannt.
Siehe https://github.com/discourse/discourse/blob/master/lib/plugin/metadata.rb für die offizielle Liste.
========================================
Discourse 2.6.0.beta2
Discourse-Version auf localhost: Discourse 2.6.0.beta2
==================== SPEICHERINFORMATION ====================
RAM (MB): 16434
total used free shared buff/cache available
Mem: 16048 5605 919 4255 9523 5850
Swap: 2047 437 1610
==================== PLATTENPLATZ-PRÜFUNG ====================
---------- OS-Plattenplatz ----------
Filesystem Size Used Avail Use% Mounted on
/dev/disk/by-label/DOROOT 315G 132G 168G 45% /
/dev/disk/by-label/DOROOT 315G 132G 168G 45% /var/lib/docker/aufs
/dev/disk/by-label/DOROOT 315G 132G 168G 45% /
/dev/disk/by-label/DOROOT 315G 132G 168G 45% /var/lib/docker/plugins
/dev/disk/by-label/DOROOT 315G 132G 168G 45% /
---------- Container-Plattenplatz ----------
unbekannter Kurzflaggen-Parameter: 'w' in -w
Siehe 'docker exec --help'.
==================== PLATTENINFORMATION ====================
Disk /dev/vda: 320 GiB, 343597383680 bytes, 671088640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 29B528BA-16C4-402E-BEE9-53555C8B6F10
Device Start End Sectors Size Type
/dev/vda1 2048 671086591 671084544 320G Linux filesystem
==================== ENDE DER PLATTENINFORMATION ====================
Hallo, ich habe dasselbe Problem. Ich kann Megatopics aufgrund dessen nicht aufteilen.
Ich habe es auch im abgesicherten Modus versucht, aber das hat nichts geändert.
In meiner Discourse-Entwicklungsumgebung (gleiche Version 2.6.0.beta2) gibt es jedoch kein Problem.
Und in den Logs ist ebenfalls nichts zu finden.
Ich bekomme seit einem Jahr diese 502-Fehler 
Ich glaube, wir haben dich noch nicht gefragt: Welche Plugins betreibst du?
Ich habe alle Plugins deaktiviert, um zu prüfen, ob es sich um einen pluginbedingten Fehler handelt. Es scheint, dass das Problem bei langen Threads stabil wiederkehrt.