Vor Weihnachten haben wir bei uns an der Schule das Update auf 3.9 gemacht. Jetzt passiert es vermehrt, dass Moodle immer wieder mal sehr lange braucht, um eine Seite anzuzeigen. Es scheint jeweils, dass ein Prozess im Hintergrund den Moodleserver für kurze Zeit "lahm" legt. Im Extremfall bis zu einer Timeout-Fehlermeldung.
Unsere Moodleumgebung:
Moodle Version 3.9.3+
Windows Server 2012 r2
PHP Version 7.4
MariaDB 10.5
Wenn ich die Auslastungen via Task-Manager auf Windows beobachte, fallen keine speziellen Aktivitäten auf, die hier eine Erklärung liefern könnten.
Hat mir jemand einen Tipp, wo ich eine Übersicht finde, welche Moodleprozesse aktuell laufen und vor allem welche Ressourcen sie dabei benötigen?
Oder welche Massnahmen sonst helfen könnten?
Besten Dank Hermann
Lieber Hermann. Kenne mich nicht mit Windows-Servern aus. Nun, dass diese gesagt ist, würde ich erst prüfen, ob unter Website-Administration > Server > Performance bei allen Werten der Standard gesetzt ist; besonders die eigene PHP-Memory-Begrenzung sollte mindestens die empfohlen 512 MB betragen. Grundsätzlich ist es wichtig, dass dem Server genügend RAM zur Verfügung steht.
Dann kannst du unter Website-Administration > Plugins > Caching > Performance testen beispielsweise 10'000 einzelne Anfragen je Operation ausführen; auf diesem Server steigen die Messwerte dabei nirgends auf über 1 Sekunde. Last but not least, kannst du dir unter Website-Administration > Entwicklung > Debugging die Performance-Information in der Fusszeile des Standardthemes zeigen lassen.
PS: Manchmal lohnt sich ein Blick in die eine oder andere Logdatei des Servers (Apache, PHP etc.) ob da gehäuft Fehler auftauchen.
PPS:
Es gibt auch Leute, welche Bilder mit Copy 'n' Paste in den Editor auf
Moodle einfügen, das generiert viel Last für die Datenbank.
Vielen Dank für deine Tipps. Habe mir jetzt nach den Ferien die Einstellungen angeschaut. Beim Performance Test bin ich nur bis 1000 Zugriffen überall unter 1 Sekunde. 5000 sind es dann knapp 3 Sekunden und bei 10000 schon 6 Sekunden.
PHP-Memory-Begrenzung ist auf dem Maximum. Auf dem Server haben wir den Arbeitsspeicher ebenfalls erhöht. Allerdings zeigt dies keine Wirkung auf den Performance Test. Wo kann ich suchen, um hier den Grund für diese hohen Werte zu finden?
Lieber Hermann. Habe mir die Performance des Cachings noch bei drei weiteren virtuellen Maschinen oder Cloud Servern mit Moodle angesehen. Tatsächlich steigt die Zeit bei 10000 Zugriffen nur bei einem auf 1.7 Sekunden, bei den beiden anderen bleibt sie deutlich unter einer Sekunde. Vielleicht gibt es bei den Geschwindigkeitsempfehlungen (De / En) den einen oder anderen Hinweis.
Mir ist dort jedenfalls der Report Moodle Benchmark aufgefallen. Dieser zeigt dir auf, wo es allfällige Flaschenhälse gibt, also wo du den Hebel ansetzten kannst. Es gibt auch eine dazugehörige (mehrheitlich französische) Diskussion, bei der Leute ihre Benchmarks zeigen. Wie schon gesagt, kenne ich mich nicht mit Windows-Servern aus und würde also nur raten, was du alles ändern könntest ;-)
Hallo Herman
Auch für mich ist Windows ein Problem. Eine Idee kann ich bringen, aber du musst das dann im Server untersuchen können. Nämlich die Frage, _wann_ kommt es zu diesen Ausfällen? Zum Beispiel hat eine ganze Klasse eine Datei abgeben wollen? (Wieviele Studenten? Wie grosse war die Datei? In welchem Zeitfenster?) Oder legt eine Klasse eine Prüfung synchron ab? (Wieder wieviele? Wir gross war der Test? Zeitspanne?) Oder, was ist der Hintergrundprozess, den du meinst? Moodle Cron? Wie ist er eingerichtet? Gibt es unerledigte/blockierte Jobs in der Warteschlange? Oder macht der Server auch andere Sachen? Synchronisieren der User, z.B.?
Nachtrag: Eine höhere PHP-Memory-Begrenzung hilft nicht unbedingt, kann u.U. sogar bremsen, weil sie RAM reserviert und damit andere Prozesse erstickt. Wenn du Performance-Daten auf der Fusszeile einschaltest, siehst du was eine typische Seite braucht. Bei mir sind das zwischen 8 und 15 MB! Die hunderten und tausenden MB sind manchmal notwendig für Hintergrundprozesse, wie z.B. automatische Kurssicherungen. Ich wurde die Begrenzung herabsetzen, bis 64 MB, und schauen ob die Ad-hoc tasks dann hängen bleiben.