Opened 3 years ago
Closed 3 years ago
#5141 closed Defekt (erledigt)
Hohe Load auf nextcloud
| Reported by: | Rüdiger Kupper | Owned by: | Rüdiger Kupper |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Nextcloud: Optimierungen |
| Component: | Webdienst: Kepler-Cloud | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | netzwerk |
Description
Auf dem nextcloud-Rechner ist die Load auf 10. Das ist sehr ungewöhnlich, seitdem das auf einem dedizierten Virtualisierer läuft, war die Load immer zwischen 2 und 3.
Heute morgen hing die Cloud völlig und ich habe sie neu gestartet. Was ist denn da auf einmal los?
Attachments (1)
Change History (20)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
Problem scheint vorerst weg zu sein.
comment:3 by , 3 years ago
| Resolution: | erledigt |
|---|---|
| Status: | closed → reopened |
Load war gestern Abend auf 5, heute während des Unterrichts ist sie auf 15 oder mehr – ein bisschen hoch für eine 12-Prozessor-Maschine. Allerdings sind die Prozessoren gar nicht belastet, vermutlich ist eher I/O das Problem? Keine Ahnung, ob sich da nach dem Update vom Wochenende etwas geändert hat. Ich lasse es jetzt mal laufen, um zu sehen, ob die Load nach der Unterrichtszeit wieder runter geht. Und dann schaue ich, ob ich an den PHP-Parametern etwas verändern kann.
comment:4 by , 3 years ago
Die Systemplatte des Proxmox hat 714 fehlerhafte Sektoren. Keine Ahnung, ob die hohe Load damit zusammenhängen kann. Wie kann man denn die Plattenaktivität im System prüfen?
comment:5 by , 3 years ago
iostat zeigt eine mittlere Prozessorauslastung von 14% an, aber iowait schwankt um 60%. Das heißt, die Prozessoren warten 60% der Zeit nur auf I/O-Operationen. Auf dem RAID werden ca. 2MB/s gelesen und ca. 150kB/s geschrieben. Kommt mir jetzt nicht übermäßig viel vor. Das data-Verzeichnis von Nextcloud liegt allerdings im GlusterFS, es könnte also auch die Netzwerkverbindung Schuld sein.
comment:7 by , 3 years ago
Dort ist zu sehen, dass der Load-Anstrieg schon am Freitag, 10.11 aufgetreten ist, also einen Tag, bevor ich das Update gemacht habe. Das Update ist also nicht schuld.
Was hat sich am Freitag mit dem Cloud-Rechner verändert?!
comment:8 by , 3 years ago
Auf dem proxmox ist zu sehen, dass die Ursache fpr die hohe Load wirklich die IO-Wait-States sind. Und gerade habe ich mal den Datenbank-Service angehalten – sofort sinkt die Load auf 1. Also sind Datenbankzugriffe der Übeltäter. Warum die ab Freitagabend plötzlich so zugenommen haben bzw. auf einmal langsamer laufen, weiß ich nicht.
Die Datenbank liegt in der Systempartition der Cloud-VM, also auf dem ersten RAID.
Kann mit dem RAID irgendwas schief laufen?
comment:9 by , 3 years ago
Was zum …?! Die Load war den ganze restlichen Tag bei 3-5. Jetzt grade (17:15) sehe ich nach und sie ist bei 0,5 (!!). Der mariadb-Prozess hat unter 1% CPU-Nutzung. Wie hat sich das denn jetzt plötzlich so krass geändert?
comment:10 by , 3 years ago
20:40 Load ist zurück auf 3–5. Mal sehen, ob sich morgen das traurige Schauspiel wiederholt.
comment:11 by , 3 years ago
Hat die NextCloud irgendwas reorganisiert?
Aus irgendeinem Grund muss die auf das Datenbanksystem zugreifen.
comment:12 by , 3 years ago
Irgend so etwas müsste es gewesen sein, ich weiß aber nicht, was es ausgelöst hat. Wenn das nach dem Update passiert wäre könnte ich es verstehen. Vielleicht habe ich am Freitag irgend eine App aktualisiert? Das sollte aber nicht solche Auswirkungen haben.
Oder macht vielleicht mariadb von Zeit zu Zeit irgendeine Reorganisation der Datenbank? Irgendwas optimieren oder garbage collection?
comment:13 by , 3 years ago
Im Moment steigt die Load wieder, jezt auf 13. Heute morgen vor der Schule war sie auf 1.
comment:14 by , 3 years ago
Möglicherweise interessant:
- https://serverfault.com/questions/574881/high-i-o-because-of-mariadb
- https://bobcares.com/blog/fix-mysql-high-iowait/
- https://stackoverflow.com/questions/63519758/mariadb-high-disk-io-and-io-wait
- https://github.com/home-assistant/core/issues/101369
- https://severalnines.com/blog/what-check-if-mysql-io-utilisation-high/
comment:15 by , 3 years ago
Wichtig wäre wohl, den InnoDB Buffer Pool zu tunen. (Dachte eigentlich, das habe ich beim Aufsetzen der Nextcloud gemacht?)
comment:16 by , 3 years ago
Habe die Puffergröße jetzt deutlich erhöht und bisher sieht das Ergebnis gut aus (abwarten!). Optimal wäre, wenn der Puffer so groß ist, dass die komplette Datenbank im Speicher gehalten werden kann.
Auf der obigen Seite gibt es noch eine Vielzahl weiterer Einstellungen, die man tunen kann.
comment:17 by , 3 years ago
Ich habe nun den Speicher der nextcloud-Maschine massiv erhöht (von 16GB auf 44GB – der Virtualisierer hat insgesamt 48GB zu bieten) und das Datenbank-Caching entsprechend erhöht auf 32GB. Nextcloud selbst braucht ja auch noch Speicher, der ist sehr abhängig von der Zahl der momentan verbundenen Nutzer.
Ich sehe, dass die Speichernutzung bei 12GB stagniert. Entweder, es gibt nur 12GB aktive Bestandteile in der Datenbank, oder irgendwo in den verschachtelten Konfigs steht noch eine Speicherbegrenzung von 12GB. Danach werde ich schauen.
Einstweilen ist die Load auf 1-2 und die Waitstates auf unter 1%(!).
comment:18 by , 3 years ago
12GB-Begrenzung hat sich erledigt, die Nutzung ist grade plötzlich auf 19GB hoch gegengen. Uhrzeit 19:56. Wer arbeitet da massiv mit der Cloud?
comment:19 by , 3 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | reopened → closed |
Die Speicher-/Puffererhöhung scheint das Problem beseitigt zu haben. Speichernutzung stagniert bei ca. 20GB, das dürfte die Größe des aktiven Teils unserer Datenbank sein.
Ob die Maßnahme nun die Ursache bekämpft oder nur die Symptome, weiß ich nicht. Nach wie vor muss sich am Freitag Nachmittag irgend etwas am Verhalten der Cloud geändert haben.
Habe jetzt mal den kompletten Proxmox neu gestartet. Momentan ist die Load wieder zwischen 2 und 3. Mal sehen.