[SOLVED] Nextcloud performance/ Hardware ausreichend?


Ale:x

Recommended Posts

Hallo zusammen, 

ich hab mehrere Probleme mit der Nextcoud Installation konnte einige zwar schon lösen oder Notlösungen für andere finden.

Bis zur Erreichbarkeit von außen bin ich noch gar nicht gekommen weil mich so manches stört.

 

1. Problem 

Ich bekomme es nicht hin Nextcloud im BridgeMode per Docker zu laufen mit einer anderen IP.

bsp: Unraid 192.168.178.90

Nextcloud 192.168.178.100:443

MySQL / PostgresSQL / MariaDB: 192.168.178.101 Erreichbarkeit über Heidi SQL funktioniert vom lokalen Rechner, Nextcloud hat aber einen SQL Fehler wenn dieser Container nicht auf der Unraid IP läuft.

 

Also erstmal Nextcloud überhaupt testen und alles auf der 192.168.178.90 per Docker installiert. 

Beide Container (mariaDB / nextcloud) die Offizielen von LinuxServer

 

2.Problem: 

Ich habe bisher nicht viel mit Nextcloud gemacht, finde es aber trotzdem schade das ein Klick auf Kalender fast eine Minute dauert. 

Das ganze wird sicherlich im realen benutzen nicht viel ausmachen wenn man nur noch Dateien per App / Sync verschiebt aber stören tut mich das trotzdem deswegen die Frage, reicht meine Hardware für mehrere Docker Container? 

 

Ich habe Nextcloud / appdata SSD Cache ONLY eingestellt. 

Das Mainboard ist ein J4205 (4x1.50Ghz) mit 8Gb Arbeitsspeicher. 

Crucial 240Gb SSD und als Storage werden 4TB Seage Ironwolf verwendet. 

 

Andere Docker wie Plex / Emby / Jellyfin / JDownloader / HomeAssitant laufen nicht mit so einer schlechten Performance 

Vielleicht sind die "empfohlenen" vorinstallierten Apps bei Nextcloud ein Problem? 

 

Viele Grüße

Alex 

 

 

 

 

 

 

Link to comment

Was sagt denn die CPU Auslastung auf dem Dashboard, während du den Kalender öffnest?

 

2 hours ago, Ale:x said:

J4205

Die Single Thread Leistung der CPU liegt deutlich unter meiner Empfehlung in #1:

https://forums.unraid.net/topic/97165-smb-performance-tuning/

 

Dennoch gibt es noch viele Stellen an denen man schrauben könnte.

 

3 hours ago, Ale:x said:

appdata SSD Cache ONLY

Wenn du auf Shares > Appdata > Views wechselst wird bei Location auch wirklich nur "Cache" angezeigt?

 

3 hours ago, Ale:x said:

ein Klick auf Kalender fast eine Minute dauert. 

Laut meiner Recherche soll der Kalender sehr viele HTTP Abfragen produzieren. Kannst du das mit Google Chrome und den Developer Tools > Netzwerkmonitor bestätigen bzw davon mal einen Screenshot machen?

Link to comment

Performance Tuning werde ich mir mal durchlesen! 
Beim klicken in Nextcloud steigt die CPU aber auch rasant an und fällt dann sofort wieder.

CPU Isolation für den Container? Bei 4 Kernen etwas schwierig :D
image.png.dea0b7747aa1b5233468fdb895ddc11f.png
 

Wenn ich mich nicht irre, ja:
image.thumb.png.d08b4b637a49ab16b0efaf4856ade766.png

 

Eine Minute war doch übertrieben. 
Es sind ca 10-20 Sekunden, man ist einfach anderes gewöhnt, dann sind 10-20 Sekunden normal? 
image.thumb.png.d6e84e66402845abb0f1237562f77268.png

Die großen Verursacher sind hier die Stylesheets, da frage ich mich wieso der Browser nicht cached.
Vivaldi und Chrome ausprobiert. 

Ich werde bald auf meinen alten Ryzen 1700 als unRAID CPU umsteigen.. damit sollten die meisten Performance Probleme ja behoben sein.. 

Link to comment
2 hours ago, Ale:x said:

Beim klicken in Nextcloud steigt die CPU aber auch rasant an und fällt dann sofort wieder.

 

Ok, dann ist da also keine dauerhafte Last wie zB durch übertrieben lange SQL Abfragen. Das interessiere mich jetzt. Die Last, die du im Dashboard siehst, ist übrigens nicht nur die CPU Last, sondern auch i/o Wait. Wenn du wirklich nur die CPU Last sehen willst, müsstest du über das Webterminal gehen und das eingeben:

htop

 

2 hours ago, Ale:x said:

Wenn ich mich nicht irre, ja:

Ja alles korrekt. Wenn Dateien auch auf dem Array liegen, steht da auch die Nummer der Disk.

 

2 hours ago, Ale:x said:

dann sind 10-20 Sekunden normal? 

Auf keinen Fall.

 

2 hours ago, Ale:x said:

Die großen Verursacher sind hier die Stylesheets, da frage ich mich wieso der Browser nicht cached.

In der Entwickler-Ansicht ist der Cache normalerweise deaktiviert. Check das mal:

230889326_2021-01-0315_13_44.png.5f32042d03f6791d8051ea76a9dce983.png

 

Sollte das Häkchen nicht gesetzt sein und er cached trotzdem nicht, dann müssten wir uns das mal anschauen, weil die sollten natürlich auf keinen Fall mehrfach vom Server geladen werden.

 

Aktiviere auch bitte mal die "Use Large Request Rows":

1961886054_2021-01-0315_17_08.png.f69aca8bea03482418e22a2e4399cada.png

 

Damit siehst du ob die Komprimierung funktioniert. Öffnest du zB eine Unraid Seite, dann siehst du, dass das Stylesheet 7.8 kB groß ist, aber nur 2 kB über das Netzwerk übertragen wurden und für die Komprimierung "gzip" verwendet wurde:

2025122554_2021-01-0315_18_27.thumb.png.838f7656ff33327b0e03a70bc044de6f.png

 

Beides ist absolut wichtig. Also Komprimierung und Caching.

 

Welchen Nextcloud-Container verwendest du (linuxserver oder knex666)?

Link to comment
14 minutes ago, mgutt said:

Beides ist absolut wichtig. Also Komprimierung und Caching.

Beides ist aktiviert. 

 

14 minutes ago, mgutt said:

Welchen Nextcloud-Container verwendest du (linuxserver oder knex666)?

linuxserver

 

15 minutes ago, mgutt said:

htop

Verhält sich ähnlich zu der Ansicht im Dashboard, beim klick auf einen Menüreiter in Nextcloud geht alles eben auf 60%. 

Ich würde also mal tippen das die Performance mit einer anderen CPU besser wird. 

 

 

Link to comment
1 minute ago, Ale:x said:

Ich würde also mal tippen das die Performance mit einer anderen CPU besser wird. 

60 sind nicht 100%. Also überlastet ist sie nicht.

 

2 minutes ago, Ale:x said:

Beides ist aktiviert. 

 

Und wie sehen die Ladezeiten nun im Netzwerk-Monitor aus, da Komprimierung und Caching funktioniert?  

Link to comment

Eventuell ist das missverständlich rübergekommen. Wenn du den Cache in den Dev Tools aktivierst, heißt das noch nicht, dass der Nextcloud Server auch Caching erlaubt. Hier ein Beispiel:

421793532_2021-01-0317_14_47.thumb.png.3d3779c1c8cb6d2a7ced0e4c9beea7bc.png

 

- DeviceList.php wurde vom Server ohne Komprimierung und ohne Caching geladen

- sweetalert2.css wurde nicht vom Server geladen, da die Datei bereits auf der Festplatte meines PCs lags (disc cache) und sie ist komprimiert (gzip)

- sweetalert2.js wurde vom Server mit Komprimierung geladen (gzip)

- clear-sans.woff wurde nicht vom Server geladen, da die Datei bereits im RAM meines PCs lag (memory cache) und diese ist nicht komprimiert

 

Ziel für dich ist, dass möglichst alles komprimiert und aus dem Cache geladen wird.

 

Wenn das nicht der Fall ist, wäre der erste Schritt, dass du mir sagst welchen Container du verwendest. Dann kann ich ihn mir selbst mal installieren und recherchieren ob es dazu vielleicht schon eine Lösung gibt.

 

Link to comment
9 minutes ago, mgutt said:

Ziel für dich ist, dass möglichst alles komprimiert und aus dem Cache geladen wird.

Ist es, ich finde es aber trotzdem etwas langsam größer 10 Sekunden. 

Caching ist aktivert und wird auch im gzip Format aus dem Memory geladen. 

Ich nutze den Offiziellen linuxserver Docker Container, nicht den Knex... 
 

Link to comment
4 minutes ago, Ale:x said:

ich finde es aber trotzdem etwas langsam größer 10 Sekunden. 

Das verstehe ich dann aber nicht. Du hattest zu Anfang einen Screenshot gepostet wo es nicht gecached wurde. Da war das Ergebnis 11.14s (im Fuß zu sehen). Wenn jetzt die ganzen CSS Dateien aus dem Cache kommen, dann müsste das doch auf 5-6 Sekunden gefallen sein?!

Link to comment

Dann sag doch nicht, dass das Caching geht. Die CSS Dateien werden nicht gecached und machen ja mal locker 12 Sekunden aus.

 

2 hours ago, Ale:x said:

Offiziellen linuxserver Docker Container,

Das ist nicht der offizielle Container. Der offizielle Container ist dieser:

https://hub.docker.com/_/nextcloud/

 

Dieser wird aber (noch) nicht über die Unraid Apps angeboten und muss von Hand eingestellt werden.

 

Ich habe mal den LSIO Nextcloud Container installiert. Dabei ist mir aufgefallen, obwohl die HTTP Header alle korrekt sind und ich nicht F5 drücke, sondern durch die Seiten klicke, dass er die Stylesheet Dateien manchmal cached und manchmal nicht. Daraufhin habe ich mal recherchiert und bin auf diesen interessanten Kommentar gestoßen:

Quote

I think it is also depends on whether the hosted environment supports SSL or not. On a customer, their domain was not https (no cert) and disc cache did not worked if you perform refresh, everytime the content was read from tomcat. but after installing a proper cert, the content was read from browser disc cache (chrome) provided that resources not modified

Da der LSIO Container ausschließlich den Zugriff über Port 443, also https erlaubt, können wir es nicht verizieren, ob es bei Port 80, also http, funktionieren würde, aber wenn die Aussage stimmt, dann klappt das Browser-Caching nur dann zuverlässig, wenn man ein korrektes SSL Zertifikat verwendet. Das können wir schon mal im Hinterkopf behalten.

 

Trotzdem ist dein Webserver sehr langsam. 2 Sekunden für eine statische Textdatei, was ja eine Stylesheet Datei ist, ist viel zu lang. Soweit ich das richtig sehe, verwendet der LSIO Container nginx und nginx braucht eigentlich kaum Ressourcen und sollte von deiner CPU spielend gestemmt werden. Allerdings habe ich eine Vermutung, die trotzdem mit deiner CPU zusammenhängt:

 

Beim Installieren von Containern, landen die Container-Dateien im /mnt/user/system/docker/docker.img. Dieses Image ist ein BTRFS Dateisytem und wird unter /var/lib/docker/ gemountet. Allerdings läuft der Pfad /mnt/user durch Unraids SHFS Prozess, der sicherstellt, dass das docker.img sowohl auf dem Cache als auch auf einer Disk des Arrays liegen kann. Dieses Konstrukt ist relativ "kompliziert" und kann eine eine hohe Last auf der CPU verursachen. Mein Vorschlag wäre, sofern deine Shares appdata und system immer auf dem Cache liegen, dass du folgendes probierst:

 

1.) Docker stoppen

2.) Im Terminal das ausführen:

sync; echo 1 > /proc/sys/vm/drop_caches

3.) In den Docker-Einstellungen /mnt/user/system/docker/docker.img in /mnt/cache/system/docker/docker.img ändern

4.) Den Nextcloud-Container bearbeiten und den "AppData Config Path" von /mnt/user/appdata/nextcloud in /mnt/cache/appdata/nextcloud ändern (nicht den "Host Path 2", wo die hochgeladenen Dateien landen)

5.) Den MariaDB-Container bearbeiten und den "AppData Config Path" von /mnt/user/appdata/mariadb in /mnt/cache/appdata/mariadb ändern

6.) Docker starten

 

Jetzt wird das docker.img nicht mehr durch den SHFS Prozess gejagt, sondern es wird beim Mounten direkt auf die Cache-Disk zugegriffen. Auch laufen die ganzen Nextcloud-Dateien und die Datenbank-Abfragen nicht mehr durch SHFS. Das sollte einiges an Last von der CPU nehmen.

 

Das selbe kannst du natürlich mit jedem Docker-Container machen, aber beachte, dass wenn du die SSD irgendwann ersetzt, dass du den Docker-Dienst erst wieder startest, wenn alle Dateien wieder auf der neuen SSD liegen. Ansonsten installieren sich die Container alle neu, weil sie nichts von evtl Dateien auf dem Disk-Array wissen, da der Pfad /mnt/cache wirklich nur auf die SSD abzielt. Auch darfst du niemals den Cache von system und appdata deaktivieren und den Mover starten während der Docker-Dienst noch läuft. Ansonsten verschiebt der Mover die Dateien auf das Disk-Array und die Container finden sie nicht mehr, weil sie nur den Pfad der SSD kennen.

 

Und natürlich gilt: Erst mal Backup machen und Nutzung auf eigene Gefahr ^^

2021-01-03 19_07_13.png

Link to comment
1 hour ago, mgutt said:

2.) Im Terminal das ausführen:

sync; echo 1 > /proc/sys/vm/drop_caches

Das kam doch später hinzu :D

Hab es nach der Anleitung gemacht, gestern habe ich noch die Unraid 6.9 RC Version installiert, die kann sogar ohne Docker.IMG in einem Directory arbeiten. 
Also erstmal alle Container weg da, neu aus dem Store geladen und da das Relevante ja im appdata liegt noch alles da. 
nextcloud habe ich aber mal clean installiert. 

Läuft wie es sein soll. Jeder Aufruf dauert unter 3 Sekunden. 
CPU geht nicht höher als 40% 

Bei der Neuinstallation der Container habe ich auch mal den BridgeMode ausprobiert und siehe an alle Container können jetzt auch in unterschiedlichen IP´s laufen.. 

Riesen Dank! 
Jetzt kann ich beruhigt mit SWAG und der Erreichbarkeit von außen weiter machen. 

Link to comment
2 hours ago, Ale:x said:

Das kam doch später hinzu :D

Ja ist mir noch eingefallen. Hilft, falls noch Dateien im RAM liegen.

 

2 hours ago, Ale:x said:

die kann sogar ohne Docker.IMG in einem Directory arbeiten. 

Ja das ist super und da freue ich mich auch schon drauf. Auch hier bietet sich dann natürlich ein direkter Link auf die Cache Disk an mit /mnt/cache

 

 

 

 

Link to comment
13 hours ago, Ale:x said:

Riesen Dank! 
Jetzt kann ich beruhigt mit SWAG und der Erreichbarkeit von außen weiter machen. 

Wofür braucht man SWAG?

 

Ich empfehle für Erreichbarkeit von Außen eine IPv4 Adresse zu haben.

Hast Du das nicht (DS-Lite Anschluß) kann Dir ein Anruf beim Support Deines Internetanbieters mit der Nennung der Stichwörter: Port Forwarding, IPv4 Adresse sowie NAS möglicherweise Stunden des Konfigurierens und Testens ersparen.

 

Gruß

Martin

Link to comment
10 hours ago, mgutt said:

Dann explodiert aber auch der Stromverbrauch. Sparsam sind die Ryzen erst ab 4000/5000.

Der 1700 hat auch "nur" eine TDP von 65W vermutlich wird der aber trotzdem dauerhaft mit 30W laufen + Platten anstelle jetzigen 10W mit Platten

 

5 minutes ago, MartinG said:

Ich empfehle für Erreichbarkeit von Außen eine IPv4 Adresse zu haben.

Hab DualStack ein Anruf habe ich schon gemacht.
Da kann sich die IP Adresse doch auch ändern? Ich denke ich komme an einem DynDNS nicht vorbei. 

 

Bin aber auch froh wenn ich weitere Container nicht brauche.. 

Link to comment
43 minutes ago, MartinG said:

Wofür braucht man SWAG?

 

Ich empfehle für Erreichbarkeit von Außen eine IPv4 Adresse zu haben.

Hast Du das nicht (DS-Lite Anschluß) kann Dir ein Anruf beim Support Deines Internetanbieters mit der Nennung der Stichwörter: Port Forwarding, IPv4 Adresse sowie NAS möglicherweise Stunden des Konfigurierens und Testens ersparen.

...no einfacher ist es, das gar nicht als Service "zu exportieren", sondern zB mittels zerotier Docker aufzubauen.

Da braucht jeder nur einen Client zu zerotier-One und lokale DynDNS, Portfreigaben usw sind Geschichte.

Vor allem wenn man nur auf Unraid-Services (unraid-UI + Docker/VMs) zugreifen will braucht man kein weiteres Routing (etwas was für einen Anwender in DE, in der regel ja mit einer Fritz, die keine VLANs kann, ja nicht so einfach wäre).

 

Edited by Ford Prefect
Link to comment
1 hour ago, Ale:x said:

Der 1700 hat auch "nur" eine TDP von 65W vermutlich wird der aber trotzdem dauerhaft mit 30W laufen

Das ist der Knackpunkt. Der 4000/5000 Ryzen geht im Leerlauf runter auf unter 10W:

https://www.computerbase.de/forum/threads/renoir-und-b550-die-idle-kuenstler.1967755/

 

1 hour ago, MartinG said:

Wofür braucht man SWAG?

Das ist ein Proxy. Dieser erlaubt sowas:

www.deinedomain.de > webserver

nextcloud.deinedomain.de > nextcloud

usw

 

Man kann also den selben Port (80/443) und die selbe öffentliche IP für verschiedene Docker Container verwenden.

 

Neben SWAG sollte man sich auch NPM anschauen:

https://forums.unraid.net/topic/76460-support-djoss-nginx-proxy-manager/

 

 

Der ist mit WebGUI.

Link to comment
  • ich777 changed the title to [SOLVED] Nextcloud performance/ Hardware ausreichend?
  • 3 months later...
On 1/3/2021 at 9:16 AM, Ale:x said:

2.Problem: 

Ich habe bisher nicht viel mit Nextcloud gemacht, finde es aber trotzdem schade das ein Klick auf Kalender fast eine Minute dauert. 

Das ganze wird sicherlich im realen benutzen nicht viel ausmachen wenn man nur noch Dateien per App / Sync verschiebt aber stören tut mich das trotzdem deswegen die Frage, reicht meine Hardware für mehrere Docker Container? 

Welche Datenbank läuft bei dir drunter?

Ich hab das Setup mit MariaDB und es wirkt auch zähe.

 

Ich habe gelesen, dass viele das mit postgres gelöst haben. (Hier auf reddit und hier im Forum )

 

Ich versuche das auch mal die Tage.

Link to comment
4 minutes ago, Knutowskie said:

Ich hab das Setup mit MariaDB und es wirkt auch zähe.

 

Ich kenne niemanden, der mit MariaDB ein lahmes Setup hat. Meiner Ansicht nach liegt es nur an den Pfaden. Man muss mit "/mnt/cache/appdata..." arbeiten statt "/mnt/user/appdata...". Denk dran, dass die Umstellung nur sicher ist, wenn bereits alle Daten auf dem Cache liegen und der appdata Share auf "Prefer" oder "Only" eingestellt ist.

 

 

Link to comment

Einen schönen gutem Tag.

Ich habe etwa den gleichen PC wie Newbie. Und mit Nextcloud im Docker das selbe Problem. Ob MariaBD im einen selbständigen Docker oder nicht. Ich habe NextcloudPi jetzt in einer VM intalliert und es läuft um Welten besser. Der Kalender öffnet in 5 sek.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.