meine Moodle-Installtion hat eine Störung. Nach einem Neutstart des Linuxservers läuft das System einige Tage wunderbar. Dann aber kommt es immer wieder dazu, dass das Ausliefern von Webseiten sehr lange dauert - das dauert manchmal bis zum Timeout.
Die Systemlast ermittelt via htop ist absolut unauffällig.
Ein systemctl restart apache2 oder mysql behebt die Ursache nicht bzw nur kurz. Nur nach einem systemctl reboot arbeitet das System wieder für einige Zeit normal.
Wie gehe ich vor um den Fehler zu finden?
PS: Manchmal habe ich den Eindruck, dass das Ganze mit der Bewertungsfunktion der Aktivität Abgabe zu tun hat oder vielleicht liegt es an unoconv… aber das kann durchaus ein Trugschluß sein.
Hallo. Ich hatte in der Vergangenheit einen ähnlichen Fehler. Bei uns lang es am Airnotifier-Server (Mitteilungen -> Mobile) dementsprechend häufig gabs bei uns Probleme (einige Tage habe wir nicht geschafft )
Bei dir wird es eher etwas anderes sein - könnte aber gut wie bei mir ein externer Dienst sein…
Ich würde mir mal die Task-Logdaten & Geplante Vorgänge anschauen und überlegen welche externen Tools evtl. als „Übeltäter“ in Frage kommen. Wenn du mal einen genauen Zeitpunkt bestimmen kannst helfen natürlich ganz grundsätzlich die Server- & Moodle-Logs…
ich nehme an, dass das immer dann passiert, wenn ca. 300 Leute auf der
Möhre sind.
Das liegt daran, dass die MAxWorker Einstellung des defaultapache zu
niedrig ist.
Ich hab mir eine Woche lang den Bär gesucht, bis ich das gefunden hab.
Ich hab Apache gepimpt (caches über caches aktiviert), die Datenbank
gepimpt und den Server stundenlang beobachtet: nix hat was gebracht…
Am Besten rufst du vom server aus mal diese Seite aus (curl installieren
und python bereithalten unter /usr/bin/python, es darf auch python 3 sein):
Da siehst du wieviele worker Prozesse es so gab und wieviele dein Server
„kann“.
Default ist 150 und das reicht für ca. 300 Zugriffe. Alle die danach
kommen sind im Schneckenland… auch mal bis zum TimeOut.
Das mache ich beim nächsten mal. Interessantes Tool.
Gestern war das System auch langsam… daraufhin habe ich den Cache und die maximalen Threads bei Apache und mariadb vervierfacht… das hat mich heute auch nicht gerettet.
Hi @All,
wichtig wäre festzustellen, ob es an Moodle, am System oder an der Hardware liegt.
Wenn die Kiste mal hängt, würde ich auch php neu starten und den Server als auch vom Server aus pingen. Bei Packetverlusten würde ich dann Moodle ausschliessen.
Je nach Aufwand (kenne nicht deine Moodle-Umgebung) unter einer anderen Sub-Domain ein frisches/nacktes Test-Moodle aufsetzen und wenn auch dort zur gleichen Zeit der Fehler auftritt, liese sich Moodle als Verursacher ausschliessen.
Moodle-Cache löschen hat mir auch schon einige Male weiter geholfen.
Ist das ein Hetzner-Börsen-Server?
Wieviel RAM hat bei Dir Moodle zugeordnet bekommen bzw. php(Administration/Server/Performance)?
der server bleibt nicht hängen: die Webseitenauslieferung wird nur sau lahm. Deswegen glaube ich ja, dass sich da der apache nur auf den Füßen steht (war bei mir so).
Er meinte ja: moodle lahm, aber systemlast niedrig.
Ich krieg immer koerperliche Schmerzen wenn in einem Forum ein Befehl angegeben wird, der quasi als root-user ein Skript (hier 2872 Zeilen) runterlaedt und das dann auch als root ausfuehrt.
Ich weiss, das ist jetzt kleinkariert weil die Leute hier schon wissen, was sie machen,
Ich empfehle bei sowas zumindest mal reinzuschauen ob da noch irgendwelche faulen Eier im Code lauern, das Skript koennte mal eben noch einen User mit uid 0 in /etc/passwd und shadow anlegen, die Festplatte mit dd ueberschreiben, Schadcode nachladen und Hintertueren oeffnen usw. usf.
Das geht in ein paar Zeilen Code.
Auch wenn die Quelle im Moment serioes ist, koennte jemand dieses Discourse hacken und da einen anderen Link reinpacken, in stark frequentierten Foren wird sowas auch, wenn man diese mal hackt, quasi als Beifang noch gemacht und ich weiss ausnahmsweise auch mal wovon ich schreibe. Deshalb sind direkte Links auf Skripte mit Anleitung zur direkten Ausfuehrung auch nicht die geilste und nachhaltigste Idee.
Jemand koennte auch den Github-Account uebernommen haben und dort das Skript ersetzen usw. usf.
Ich weiss auch, dass man Node-RED, NodeJS und anderes Zeugs gerne mit Bashskripten installieren laesst, die man auch per curl oder wget runterlaedt und gleich durch die shell presst, eine Befehlszeile.
Das sind aber meistens RaspberryPis, die sowieso alle naselang neu installiert werden weil das root-Passwort vergessen wurde, datenschutzrechtlich ist da meistens auch nicht viel zu holen.
Also nochmal zurück zum Thema:
Bitte zwischen Freeze und einem Timeout unterscheiden. Den Freeze hatte ich letzten Montag bei Hetzner und das war wirklich icht lustig, da musste der Server im Rechenzentrum neu gestartet werden. Bei Windows kennt man den Freeze als BlueScreenOfDeath. Hier sollt eman auf jeden Fall die Kernel.logs sehr genau durchgehen!!!
Zum anderen Thema habe ich auch viel Erfahrung gesammelt, zwar mit NC, aber ist genau das gleiche eigentlich.
Also ich habe als erstes einen nginx Server als Proxy ganz vorne. Der kümmert sich um die verschlüsselte Verbindung, dass die Daten mit http2 übertragen werden, statische Dateien werden direkt durch nginx bedient und es wird zusätzlich wenn möglich die Dateien per gzip komprimiert über die Leitung geschickt. Hier müssen auch genügend Worker zur Verfügung stehen, sonst kommt der Gateway Timeout Fehler.
Hintendran steht dann der Apache Server. Auch hier wie oben genügend Prozesse und Worker zur Vefügung stellen, die auch genügend Childs erzeugen können und dürfen. Auc interessat ist hier der Timeout. Da Nextcloud sehr viel dynamisch mit JS nachlädt, ist der bei mir mit 15s eher hoch. Da muss dann nicht jedes Mal eine neue Anfrage aufgemacht werden und der Overhead ist kleiner. (Hab ja genügend Slots bei den Workern frei). Solltest du eher weniger Slots aufgrund der Leistung haben, dann eher den Timeout runter, dass die Slots wieder frei werden und andere Anfragen bedient werden. Ich weiß jetzt nicht ob Moodle so dynamisch nachlädt, je nachdem auch hier die Kondiguration anpassen.
Nächster Punkt ist PHP-FPM. Hier bisschen beocbachten, was ein Prozess an RAM / Prozessorlast benötigt und ensptechend die mögliche Childs anpassen. Rechenzeit hier eher hoch (3600s), sonst müssen diese Prozesse zuoft neu geladen werden. Auch hier muss man ein bisschen schauen, wieviel Prozesse zur Koordinierung laufen. Da gibt es auch verschiedene Einstellungen, Ich nutze hier die Einstllugen dynamisch und habe bei spareSever minimal Kernanzahl2 und bei maximal Kernanzahl4.
Dann gibt es noch verschieden Cache für verscheiden Funkionen, auch ier weiß ich nicht was Moodle unterstützt, ich nutzte für NC folgende:
PHP OP Cache, caches die kompilierten PHP Scipte zwischen, enormer Leistungssprung
APCU Cache, cached Variablen zwischen
Redis: Filecache, kümmert sich um Locking von Dateien…
Und zum Schluss noch die Datenbank, die braucht genügend RAM und gleichzeitige Verbindungen, dass die Abfragen flüssig laufen. Aber da gab ea oben auch schon TIpps. Man kann sich die kritischen Variablen in seiner DB für phpmyAdmin auch anzeigen lassen, manchmal gibt es gute Tipps wie man hier erwas besser hinbekommt.
Ganz schön viel um das ganze flüssig zu bekommen ^^
Ich weiss, das ist jetzt kleinkariert weil die Leute hier schon wissen,
was sie machen,
ich hatte das gleiche Gefühl wie du: deswegen hab ich das script
runtergeladen und angeschaut.
Und weil ich ein ebenso komisches Gefühl beim „andauern runterladen“
hatte, starte ich jetzt immer das runtergeladene script.
… aber du hast schon recht: das hätte ich vorhin dazu schreiben sollen.
PHP OP Cache, caches die kompilierten PHP Scipte zwischen, enormer
Leistungssprung
APCU Cache, cached Variablen zwischen
Redis: Filecache, kümmert sich um Locking von Dateien…
Und zum Schluss noch die Datenbank, die braucht genügend RAM und
gleichzeitige Verbindungen, dass die Abfragen flüssig laufen. Aber
da gab ea oben auch schon TIpps. Man kann sich die kritischen
Variablen in seiner DB für phpmyAdmin auch anzeigen lassen, manchmal
gibt es gute Tipps wie man hier erwas besser hinbekommt.
die Caches habe ich alle eingerichtet: hat nix gebracht.
Es waren einfach zu wenige worker erlaubt …
Seit ich das geändert habe läuft mein moodle auch mit 500 gleichzeitigen
Zugriffen sehr schnell (Seitenaufbau in einer Sekunde).
Der Server hat für die vielen Worker aber halt auch ausreichend RAM: das
ist nämlich die Kehrseite: der Grund weswegen der Default nur 150 ist
und weswegen man das script braucht: es berechnet einem welche
workerzahl man bei dem RAM ausbau machen kann.
Seit die Worker hoch sind, ist die Handbremse gelößt.
Ich glaub das ganze Cachetheater hätte ich garnicht gebraucht (ich hab
ein APCU Cahe mit 4GB im RAM eingerichtet … es werden nur 100MB
benutzt…) und der REDI Cache ist im Schnitt 30 MB groß…
Täusch dich mal da nicht, mein OP Cache hat in 5 Tagen 3000php Scripte gecached und hat aktuell einen Hit von 6,083,296,838. entspricht einer Rate von 99.99995%; das entlastet die CPU und IO Rate auf der Festplatte schon ordentlich!
nach ein paar Tagen geht auch bei wenig Zugriffen nichts
bei vielen gleichzeitigen Zugriffen geht nichts
Da muss man an ganz unterschiedlichen Stellen suchen!
Im zweiten Fall sollte man unter anderem auf jeden Fall das bei Apache standardmäßig verwendete mpm_prefork deaktivieren und stattdessen mpm_event mit php-fpm und fcgi nehmen.
)
