Nextcloud Webinterface langsam

[Piktogramm]

Wie viele Prozesse für Nginx und PHP sinnvoll sind hängt davon ab woran es krankt. Mehr Threads bringen nichts, wenn das System am CPU Limit ist und/oder es sowieso einen kritischen Pfad gibt, auf den alle anderen Prozesse warten müssen. Wo es was bringt sind Fälle, wo Prozesse hauptsächlich mit dem Warten auf I/O zubringen.
Wobei Nextcloud eine komplexe Anwendung ist und eine bunte Mischung aus allem liefert. CPU Last, da DAV in PHP implementiert wurde, kritische Pfade da oft auf die Datenbank gewartet werden muss und I/O bound ist das ganze dank Netzwerklatenzen und Dateioperationen oft auch.

An der Stelle wären wir dann auch bei der I/O-Last. Da bringt es nichts, wenn du der Meinung bist, dass da irgendwas "nicht groß" ist, sondern was das System dazu sagt. Unter top wäre das der Wert "wa" (für iowait).

Hast recht, ich sollte entspannter werden, ich habe dennoch eine Abneigung gegen unvollständige Bug reports
Zu Transmit habe ich nichts gefunden was das Verhalten angeht. Also ob das Programm HTTP/2 nutzt wenn möglich und/oder ob es vielleicht einfach Verbindungen spamt. Da müsste man sich den Traffic anschauen..

Nicht zählen sondern messen. Kannst du ja auch wunderbar ohne deinen Kollegen, einfach einen Nutzer anlegen und selbst Uploads durchführen und derweil versuchen die Instanz zu nutzen. Da kannst du dann auch reproduzierbar messen wie lang das Laden der Seite dauert und wie die Last auf dem Server ausschaut.

 

[G-Red]

An der Stelle wären wir dann auch bei der I/O-Last. Da bringt es nichts, wenn du der Meinung bist, dass da irgendwas "nicht groß" ist, sondern was das System dazu sagt. Unter top wäre das der Wert "wa" (für iowait).

Also müsste ich beim Überwachen auf diesen Wert Ausschau halten, welcher Prozess das bewirkt?

Zu Transmit habe ich nichts gefunden was das Verhalten angeht. Also ob das Programm HTTP/2 nutzt wenn möglich und/oder ob es vielleicht einfach Verbindungen spamt. Da müsste man sich den Traffic anschauen..

Es scheint als hätte ich http2 nicht aktiviert gehabt. Zumindest fehlten die unten genannten Einträge in meiner nextcloud Konfiguration für nginx. Diese habe ich jetzt einegetragen und den nginx Service neu gestartet.

    listen 443 ssl http2;
    listen [::]:443 ssl http2;

Nicht zählen sondern messen. Kannst du ja auch wunderbar ohne deinen Kollegen, einfach einen Nutzer anlegen und selbst Uploads durchführen und derweil versuchen die Instanz zu nutzen. Da kannst du dann auch reproduzierbar messen wie lang das Laden der Seite dauert und wie die Last auf dem Server ausschaut.

Aber wenn ich von meiner Kiste aus anfange etwas als ein anderer Benutzer zu laden, da merk ich doch nicht ob etwas langsamer oder schneller ist, weil ich ja meine Leitung bereits belege so zu sagen. Zumindest hatte ich das langsame Reagieren der Cloud während des eigenen Uploads damit begründet. Oder ist das ein falscher Gedankengang?

Das mit dem Messen musst du mir vielleicht noch näher erläutern. Wie und womit mach ich das am besten, sodass ich dann eindeutige und lesbare Infos erhalte? Noch einz vorweg. Ich komm zwar mit einigen Sachen zu recht, bin aber kein Admin und habe mit Monitoring von Webservern oder dergleichen nicht viel am Hut. Daher bitte nicht aufregen .

Ergänzung (20. Mai 2020)

Weiß nicht obs hilft, habe jetzt den Kollegen gebeten was hoch zu laden und dabei die Ausgaben von htop und iotop aufgezeichnet.

 

[G-Red]

Kleiner Erfolgsupdate, so hoffe ich.
nach der Anpassung der Werte in der Datei

/etc/php/7.2/fpm/pool.d/www.conf

und einem restart des nginx und php-fpm, wurde die vorherige Situation behoben. Zumindest scheint es jetzt keine Downtimes der Webseite zu geben, während ein Upload stattfindet.

Die Werte die Angepasst wurden, sind folgende

pm = static ;dynamic
pm.max_children =70
pm.start_servers = 16 ;20
pm.min_spare_servers = 16 ;20
pm.max_spare_servers = 32 ;35
;pm.max_requests = 1000

Das was mit Semikolon auskommentiert ist, hatte ich zuvor.

Darüber hinaus, hatte ich in der nginx Nextcloud configuration folgendes im server Bereich ergänzt. Das hat aber jetzt keine Wirkung gezeigt, bevor ich die o.g. Änderungen vorgenommen habe. Da die Optionen in der Doku von Nextcloud stehen, habe ich diese mal vorsichtshalber mit aufgenommen.

listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;

Danke schon mal an alle die sich beteiligt haben. Wenn sich was ändert, werd ich mich noch mal melden

 

[snaxilian]

bin aber kein Admin und habe mit Monitoring von Webservern oder dergleichen nicht viel am Hut

Dann wende dich an den Admin denn das ist sein Job.

Ach ihr habt keinen Admin und du betreust dies? Tja dann heißt das wohl, dass DU der Admin bist. Wenn du also verantwortlich dafür bist, solltest du dir auch das Fachwissen und die Kenntnisse dazu aneignen oder ihr lagert dies aus an jemanden, der dies für euch erledigt.

Für das erfassen von Metriken gibt es viele Ansätze. Icinga2, zabbix, check-mk oder meinetwegen auch Nagios sind so die klassischen Monitoring-Lösungen, die idR aber primär Event basiert etwas erfassen. Bei icinga2 und check-mk weiß ich, dass diese aber auch zeitbasierte Metriken aufbewahren und erfassen.
Rein zeitbasiertes Monitoring wäre z.B. mit Prometheus + Grafana möglich aber Monitoring ist so ein schönes weites Feld wo man ggf. schnell etwas sieht aber WAS man da sieht und wie man die Werte interpretieren und kombinieren kann ist dann noch etwas anderes.

Ansonsten siehst du bei der CPU nur das, was dein VPS eben "sieht" und hat. Da siehst du ggf. welche CPU unten drunter in der Hardware verbaut ist aber diese CPU teilst du dir ja mit zig anderen Kunden. Das ist auch völlig legitim so, der Anbieter kommuniziert dies ja auch so klar. Wenn also die CPU der Hardware gerade andere Aufgaben abarbeitet, muss dein VPS warten, davon siehst du aber nix in deiner Auslastungsanzeige.
Müsstest den Support von Netcup fragen ob eine Migration von VPS zu deren Rootserver angeboten möglich ist falls das irgendwann mal nötig sein sollte.

Ansonsten noch das hier gefunden: https://www.reddit.com/r/NextCloud/comments/cut50y/nextcloud_web_interface_slows_down_when_someone/
Neben den erwähnten worker Prozessen kam dort noch ein weiterer guter Hinweis: Ein Upload von Dateien ballert den Upload der Internetanbindung des Anwenders zu. Parallel sollen dann durch den Uploadstream noch die ACK Pakete des regulären Surftraffics.
Bisher wird ja pauschal angenommen, dass es ein Serverproblem sein muss und beim Client alles iO ist. Ansonsten vom Anwender mal den Nextcloud Client und Webdav direkt unter OS X testen. Wenn damit das Verhalten besser ist, wurde per Aussschlussverfahren ja gezeigt, dass es an der Transmit Software liegt. Soll sich jemand anderes mit dem Support der Software herum ärgern^^

 

[G-Red]

@snaxilian
Ich habe die Befürchtung, du hast sehr viel hineiniterpretiert aus dem was ich geschrieben habe . Das ist meine Private Cloud die ich mit meiner Verwandschaft teile . Also ja, ich bin Admin/Tech-Support und Reparier-Onkel in der Familie der sich auch für solche Sachen wie Cloud interessiert, aber nicht das allumfassende Wisen beistzt. Hier ist eben die Devise "Learning by Doing" .

Die Monitoringgeschichten sind mir bekannt, nur die Zeit fehlt Momentan sich dises genau anzugucken und zu testen. Wobei ein paar von den für einen Normalsterblichen in Frage kommen. Icinga ist meines wissens kostenpflichtig.

Danke dir für den Link, werde disen mir noch anschauen, aber momentan ist das Problem erstmal gelöst. Wie gut, wird sich mit der Zeit zeigen .

 

[snaxilian]

Falsches Wissen denn icinga2 wie auch schon das alte icinga ist open source. Ja, du kannst bei der Firma, die den Großteil bzw. sehr viele der Entwickler beschäftigt Support und/oder managed services dazu kaufen. Ist ne kleine feine deutsche Firma aus Nürnberg.
Wenn es nur im privaten Umfeld ist würde ich ggf. eher zu check-mk raten, dafür reicht locker deren kostenfreie Community Edition und ist schneller aufgesetzt und eingerichtet als manch andere Lösungen.

 

[G-Red]

Hi Leute, ich bins wieder.

Leider war die Freude nur von kurzer Dauer. Das Problem besteht weiterhin und ich werde wohl als nächstes einen anderen VPS Anbieter probieren, der Minutenweise abrechnet, sodass ich mich nicht vertraglich binden muss. Soweit ich gelesen habe könnte so ein Verhalten wohl auf eine I/O Überlastung des Hostservers deuten. Da ich diese nicht sehe, werd ich mal was anderes probieren.

Werde es beim scaleway Probiern. Die bieten für recht kleines Geld ein paar AMD Epyc Kerne

 

[snaxilian]

CPUs haben IO, RAM hat IO und ein Storage hat IO. Ich vermute du beziehst dich auf den Storage und wie genau kommen da jetzt VMs bei Scaleway ins Spiel? Auch die teilen sich Ressourcen mit anderen VMs auf dem Blech beim Anbieter denn ich sehe nirgends Garantien zu irgendwelchen IOs.

 

[G-Red]

CPUs haben IO, RAM hat IO und ein Storage hat IO. Ich vermute du beziehst dich auf den Storage und wie genau kommen da jetzt VMs bei Scaleway ins Spiel? Auch die teilen sich Ressourcen mit anderen VMs auf dem Blech beim Anbieter denn ich sehe nirgends Garantien zu irgendwelchen IOs.

Scaleway ist lediglich mir untergekommen, weil aus der Bekanntschaft jemand das nutzt und diese recht günstig sind und die Starke CPU haben. Darüber hinaus ist laut deren Inserat bei dem Server eine NVMe verbaut ist, wo ich auf mehr Leistung hoffe.

Ob letzten Endes es etwas bringt weiß ich nicht, darum will das ja erstmal austesten. Kostet nicht viel da dort Stundenweise abgerechnet wird ca 0,006Cent für eine Maschiene mit einem Epyc Kern, 25GB NVMe und 2GB RAM.

 

[snaxilian]

naja... NVMe SSDs gibt es auch "von-bis" und es macht einen Unterschied ob ich auf einem Storage 5, 10, 50, 100 oder mehr VMs parallel laufen lasse.
Gleiches gilt für die CPU. Natürlich klingt im Hochglanz-Werbeprospekt die neueste AMD superduper CPU ganz toll denn die hat ja drölfzighundert Threads und die Benchmarkergebnisse erst huiuiui
Wenn die CPU aber 64 Threads hat und ich da beispielsweise 320 VMs mit je 2 vCPUs laufen lasse dann steht rein rechnerisch jeder vCPU 10% der physikalischen CPU zur Verfügung.
Du siehst: mit einem Wechsel des Anbieters und weiterhin der Verwendung von VMs ohne garantierte Ressourcen hast du genau nichts gewonnen.

Wenn du das wirklich ausschließen willst bleibt dir nur die Nutzung von eigenem Blech. Das gibt es auch bei Scaleway, kostet dann halt 24ct pro Stunde. Wenn du denkst, dass es nicht am Storage sondern an der CPU liegt: Bleib bei Netcup und nimm einen root statt vps Server, da hast garantierte CPU und RAM Ressourcen und "nur" der Storage ist geteilt.

 

[G-Red]

naja... NVMe SSDs gibt es auch "von-bis" und es macht einen Unterschied ob ich auf einem Storage 5, 10, 50, 100 oder mehr VMs parallel laufen lasse.
Gleiches gilt für die CPU. Natürlich klingt im Hochglanz-Werbeprospekt die neueste AMD superduper CPU ganz toll denn die hat ja drölfzighundert Threads und die Benchmarkergebnisse erst huiuiui
Wenn die CPU aber 64 Threads hat und ich da beispielsweise 320 VMs mit je 2 vCPUs laufen lasse dann steht rein rechnerisch jeder vCPU 10% der physikalischen CPU zur Verfügung.
Du siehst: mit einem Wechsel des Anbieters und weiterhin der Verwendung von VMs ohne garantierte Ressourcen hast du genau nichts gewonnen.

Klar es Besteht die Möglichkeit, dass das Ding bei scaleway hoffnungslos überlastet ist, aber ohne es probiert zu haben werde ich nicht schlauer . Wenns klappt gut, wenn nicht dann überleg ich weiter.

Danke aber für dein Feedback und die Vorschläge. Betreibst du selbst irgendwas in der Richtung?

 

[snaxilian]

Ja, ich mache den "Quatsch" seit Jahren beruflich. Ganz früher Hardware in geo-redundante RZs bauen, verkabeln, Grundconfigs einspielen etc, dann eher weniger RZ Management und mehr VMware/HyperV, SAN, Storage allgemein, Backups, Monitoring und Nebenkriegsschauplätze im Bereich Netzwerktechnik, Loadbalancing und IT-Security, inzwischen aber primär Automatisierung und Betreuung (per Automatisierung) von Linux-Servern und IT-Security.

Bitte überlege dir doch mal 5 Minuten was dir so ein Test bringen soll und welche Aussagekraft der am Ende hat. Denn defacto ist dies nur eine Momentaufnahme. Schon 5 Minuten später kann auf dem Host wo dein System läuft/lief ein anderer Kunde 10 Systeme deployen auf denen lauter Datenbanken laufen. Hier ist also die Frage: Die gut ist das capacity management des Anbieters und wie viel Ressourcen plant er durchschnittlich pro VM von Kunden. Diese Zahlen geben aber viele Provider nicht heraus und/oder bieten garantierte Ressourcen eben nur in bestimmten Tarifen.
Performance bei virtuellen Systemen sind nun einmal nicht starr und statisch außer man konfiguriert eben explizite garantierte Ressourcen pro Gast/Kunde/VM. Im privaten Umfeld braucht dies aber kaum jemand und wenn überschätzen die Leute oft maßlos ihre realen Anforderungen und buchen dann X Ressourcen. Kann ich diese dann als Hoster nicht geteilt für andere Kunden nutzen sinkt somit die Effizienz meiner vorhandenen Hardware und ich muss eben eher erweitern und vergrößern. Daher lässt man sich diese garantierte und oft brach liegenden Ressourcen natürlich besser bezahlen als reine geteilte Plattformen.

Ja, ich betreibe auch privat eine kleine Handvoll Systeme aber dort kann ich mit der vorhandenen und gebuchten bzw. erwarteten Disk IO leben weil ich explizit weiß worauf ich mich eingelassen habe und wenn Dritte dies mit nutzen, wie z.B. eine Nextcloud dann sage ich Dritten auch: Nutze den Dienst, den ich dir bereit stelle in den Zustand wie er ist. Ist dir dieser zu lahm beteilige dich an meinen Kosten für etwas größeres/schnelleres oder besorge oder betreibe etwas eigenes aber das kostet halt Zeit oder Geld.
Wobei ich auch schon mehr als einmal fest gestellt habe, dass eben das Problem nicht am Server sondern am Endgerät oder der Internetanbindung des Anwenders etc lag und ich versuche auch diese ganzen Serverspielereien in einem kleinen Maßstab zu halten und nutze bei manchen Anwendungsfällen eher bereits vorhandene darauf spezialisierte Anbieter denen ich vertraue weil ich inzwischen privat andere Prioritäten habe als mich regelmäßig und kontinuierlich um irgendwelche privaten Server zu kümmern

 

[Piktogramm]

Zum Messen:
Browser auf, Entwicklerkonsole suchen und dort dann den Reiter zum Messen des Netzwerkverhaltens.

Schaut dann bei mir so aus, beim Anzeigen von https://example.com/apps/files/

Interessant sind da: Protocol um zu sehen ob wirklich http2 zum Einsatz kommt. Gefolgt vom Wasserfall (ganz rechts) um zu erkennen ob evtl einzelne Elemente besonders lang brauchen.

Die Gesamtgeschwindigkeit steht dann unten. Finish gibt an nach wie vielen Sekunden die Seite angezeigt wird, DOMContentLoaded wann das grundlegend HTML File da ist und loaded sollte die Gesamtzeit der Übertragung dauert. Mehr dazu: https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

Da reicht eigentlich top.

op - 17:42:07 up 2 days,  8:58,  1 user,  load average: 0.61, 0.36, 0.22  
Tasks: 202 total,   1 running, 201 sleeping,   0 stopped,   0 zombie                                                                        
%Cpu(s):  4.8 us,  2.9 sy,  0.0 ni, 91.2 id,  0.1 wa,  0.0 hi,  0.7 si,  0.3 st
MiB Mem :   7961.7 total,   3670.9 free,    483.3 used,   3807.5 buff/cache                                                                 
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   7002.4 avail Mem                                                                  
                                                                                                                                            
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                              
 325163 www-data  20   0 2571160  17832   7580 S   9.0   0.2   0:59.58 apache2                                                              
 450128 www-data  20   0  290480  58572  42996 S   5.0   0.7   0:08.57 php-fpm7.4                                                           
 444736 www-data  20   0  290488  61292  45628 S   3.3   0.8   0:43.44 php-fpm7.4                                                           
 444738 www-data  20   0  290500  60492  44836 S   3.3   0.7   0:40.53 php-fpm7.4                                                           
 450155 www-data  20   0  290308  59056  43540 S   2.0   0.7   0:06.28 php-fpm7.4                                                           
 443831 root      20   0       0      0      0 I   1.0   0.0   0:00.54 kworker/u8:0-btrfs-worker                                            
    686 postgres  20   0  218316  25944  23888 S   0.7   0.3   2:27.20 postgres

Fängt an bei load Average (manpage von top und/oder google!). Wo auf meinem Server (VPS mit 4CPUs, auch bei Netcup) abzulesen ist, dass (trotz aktivem Uploads meinerseits) kaum Last ist.
Weiterhin interessant ist das Feld "wa" (hier mit 0.1) wo abzulesen ist, wie viel Zeit das System damit zubringt auf I/O zu warten.

Problematisch ist ein load average, der nahe oder über der Anzahl der verfügbaren CPUs liegt und generell sind hohe Werte für iowait schlecht.


Der Testfall wenn du selbst hochlädst, da wird das Ergebnis etwas verfälscht aber nicht enorm. Das Hochladen schlägt sich vor allem auf dein Uplink nieder, während der Abruf einer Seite eher durch den Downlink bestimmt wird. Klar wird der Abruf dennoch etwas langsamer, aber Aussagen sollten dennoch möglich sein, was es langsamer macht.

 

[G-Red]

@Piktogramm
Hay danke dir für die Analyse-Anleitung. Ich nehme es in ein paar Tagen in Angriff, denn momentan nicht so viel Zeit da. Werde mich aber definitiv noch mal melden, also vergesst mich bitte nicht :-)!