freebsd vs. ubuntu unter Performance-Gesichtspunkten bei bspw. Nextcloud

[pbtraveller]

Hi,
ich nutze seit vielen Jahren Freebsd, weil es für mich einfach viel nachvollziehbarer ist und auch immer für mich funktioniert hat. Ich liebe außerdem die Stabilität. Was mich aber bei Freebsd wirklich nervt, ist die schlechte Unterstützung für wifi. Ich habe bspw. immer meinen eigenen Router auf freebsd aufgesetzt (meistens APU2 boards), bis auf wifi. Da muss ich immer noch auf so einen ... wie Fritz oder eben auf Openwrt zurückgreifen. Außerdem habe ich gelesen (selbst nicht getestet), dass Nextcloud (php, Postgres etc.) auf ubuntu deutlich schneller sei, als auf freebsd, da daraufhin optimiert. Ich muss auch gestehen, dass bei mir Nextcloud nicht so richtig schnell ist.

Wer von Euch hat tatsächlich Erfahrung mit beiden Welten und kann was zu den Geschwindigkeitsunterschieden sagen - if any... wie ist die Performance im Vergleich bei Anwendungen wie Nextcloud.

Vielen Dank und viele Grüße
pbtraveller

 

[CommanderZed]

Ich bin von OpenBSD mit relayd, apache, php mysql gerade auf Archlinux mit apache, php mysql mit meiner nextcloud gewechselt.

Obwohl da nun nen wireguard-tunnel zu einer vm zuhause hinzugekommen ist, ist es gegühlt etwas schneller. Nicht nur aber vor allem durch den tunnel und andere Hardware sind die Setups nicht 1:1 vergleichbar

 

[turrican]

man kann mit etwas feintuning von zfs, Datenbank und php/fpm sowie den Caches noch ein wenig rausholen, aber nach meinem dafürhalten hat nextcloud so seine internen Problemchen welche sich negativ auf die Performance niederschlagen (bei FreeBSD wie Linux);

so war bei meinem letzten Test mit nextcloud (v26, durchaus schon ne Weile her) ein Problem, dass die Table oc_filecache sehr schnell auf >100GB anwuchs - bei einer Gesamt-Datenlage von unter 10 GB, innerhalb Testzeitraum von ein paar Tagen;

hab das jetzt nicht mehr weiter verfolgt (und seitdem kein nextcloud genutzt), aber ich kann mir gut vorstellen, dass dieses Problem immer noch besteht - manuelle Abhilfe war, den fraglichen Index/die Indices zu löschen und neue anzulegen

mein Setup war Intel J5040 mit 16GB RAM, FreeBSD 13 und jails, mit mariadb 10 als db, die schwuppdizität der nextcloud-GUI war so einigermaßen ok, vielleicht hätte ein Ryzen5 mit 32 oder 64 GB RAM wesentlich besser ausgesehen - das gleiche/ähnliche (php8.2 statt 8.1 usw) Setup auf Linux auf einem i5-2400 mit ebenfalls 16GB RAM brachte keine nennenswerte Verbesserung;

mit postgres anstatt mariadb erstmal auch keine nennenswerte Veränderung, vielleicht fühlte sich das GUI etwas spritziger an (subjektiv), aber so wie es sich für mich darstellte braucht nextcloud primär ein performantes db setup (db auf nvme, von mir bislang ungetestet) und genug RAM um php, fpm und redis gut zu versorgen.

 

[pbtraveller]

man kann mit etwas feintuning von zfs, Datenbank und php/fpm sowie den Caches noch ein wenig rausholen, aber nach meinem dafürhalten hat nextcloud so seine internen Problemchen welche sich negativ auf die Performance niederschlagen (bei FreeBSD wie Linux);

so war bei meinem letzten Test mit nextcloud (v26, durchaus schon ne Weile her) ein Problem, dass die Table oc_filecache sehr schnell auf >100GB anwuchs - bei einer Gesamt-Datenlage von unter 10 GB, innerhalb Testzeitraum von ein paar Tagen;

hab das jetzt nicht mehr weiter verfolgt (und seitdem kein nextcloud genutzt), aber ich kann mir gut vorstellen, dass dieses Problem immer noch besteht - manuelle Abhilfe war, den fraglichen Index/die Indices zu löschen und neue anzulegen

mein Setup war Intel J5040 mit 16GB RAM, FreeBSD 13 und jails, mit mariadb 10 als db, die schwuppdizität der nextcloud-GUI war so einigermaßen ok, vielleicht hätte ein Ryzen5 mit 32 oder 64 GB RAM wesentlich besser ausgesehen - das gleiche/ähnliche (php8.2 statt 8.1 usw) Setup auf Linux auf einem i5-2400 mit ebenfalls 16GB RAM brachte keine nennenswerte Verbesserung;

mit postgres anstatt mariadb erstmal auch keine nennenswerte Veränderung, vielleicht fühlte sich das GUI etwas spritziger an (subjektiv), aber so wie es sich für mich darstellte braucht nextcloud primär ein performantes db setup (db auf nvme, von mir bislang ungetestet) und genug RAM um php, fpm und redis gut zu versorgen.

Sehr interessante Hinweise, vielen Dank. db auf nvme Bin ich gerade dabei aufzusetzen, verspreche mir davon auch etwas mehr Performance. Neue CPU für eine private Cloud ist mir gerade etwas OTT. Tuningparameter werde ich mal probieren.

 

[CommanderZed]

so war bei meinem letzten Test mit nextcloud (v26, durchaus schon ne Weile her) ein Problem, dass die Table oc_filecache sehr schnell auf >100GB anwuchs - bei einer Gesamt-Datenlage von unter 10 GB, innerhalb Testzeitraum von ein paar Tagen;

Das hatte / hab ich nicht, der war bei mir sehr unauffällig, hab etwas über 100GB an Dateien drinne (Vor allem Fotos)

Das Nextcloud eine relativ fette sache ist die auch gerne etwas Dampf mag, ist ja hinlänglich bekannt. AFAIK gibt es je nach dem was man machen möchte durchaus schlankere, vermutlich auch bessere Lösungen.

Für mich war die Entscheidung für NC das es ne ziemlich eierlegende Wollmilchsau ist, die eine gute App-Unterstützung hat auf allen Plattformen (Insb. Android & iOS) gut supported wird, da ein sehr wichtiger punkt für mich das automatische wegsichern der Smartphonephotos ist. Dazu auch durch ein offenbar funktionierendes Business-Modell eine realistische Zukunftsaussicht hat.

Die Diskusion / Frage vom @pbtraveller war aber ja nicht ob Nextcloud fett ist, sondern ob es sein kann das sie unter Linux schneller läuft.

Was sich immer lohnt bei NC ist das ganze Setup anzuschauen. Man kann z.B. mit der my.cnf spielen um etwas mehr Datenbankperformance rauszukitzeln - hier könnten schon unterschiedliche defaultwerte zwischen FreeBSD und Linux relenvant sein. Dito auch bei php und redis etc gibts sehr viele unterschiedliche Werte. Will sagen: Um FreeBSD und Linux da performancetechnisch zu betrachten sollte man das auch vergleichen, dito auch den gleichen Webserver nehmen, gleiche PHP-Version etc.

Die Config-Page von Nextcloud weißt auch idr. auf probleme im Bereich Cache, indizies etc hin - diese sollte mann dann auch beachten (Unabhängig vom Betriebsystem)

Ich hab die DB, die Nextcloud und das OS jetzt auf ner nvme, das NC-Datenverzeichniss liegt auf klassischen Rostplatten und das läuft echt flüssig. Auch der wechsel von httpd auf apache - noch unter OpenBSD hat etwas gebracht. Der VM unter qemu hat zurzeit 8GB Ram und darf 6 Prozessorkerne nutzen (Ryzen 7 7600)

Nextcloud ist eine Software die selbst wenn man sie nur für sich privat betreiben möchte etwas mehr Pflege & Reinlesen möchte, was imho auch daran liegt das sie klar auf zumindest mittlere Business-Installationen hin entwickelt wird. Das ist für mich auch okay, denn sie wird ja auch recht eindeutig nicht für den klaren privaten Use-Case Beworben - zumindest wenn man zwischen den Zeilen lesen kann. Er ist aber auch, so lese ich das, ganz klar erwünscht und nicht "geduldet" oder so - finde ich nen guten kompromiss bislang.

Grundsätzlich ist glaub ich die klare Tendenz, @Yamagi kann das immer sehr gut ausführen, das FreeBSD je-nach-dem im ganzen oft etwas langsamer ist als Linux, in Details aber auch mal schneller sein kann, aber nicht um riesige faktoren. Das sieht bei OpenBSD anders aus, das ist nen eckchen langsamer, bei manchen dingen auch nen ordentliches eckchen. Das wird von den Entwicklern auch nicht verheimlicht

 

[mr44er]

Ich kenne den Vergleich nicht, da nextcloud bisher nur auf FreeBSD betrieben. Da empfand ich das zwar als merklich anspruchsvoll (im Rahmen eben von Krempel, der noch zusätzlich an einer DB nuckelt), aber insgesamt nicht langsam im Sinne der Hardware, die druntergepackt wurde.

Den hauptsächlichen "Boost" ziehst du aus einem recordsize-angepassten Dataset nur für die Datenbank. Der Beitrag ist älter, aber hat immer noch seine Gültigkeit: https://www.usenix.org/system/files/login/articles/login_winter16_09_jude.pdf
"recordsize + $db + nextcloud" in der Suchmaschine deiner Wahl wird dir weitere Tuningtips bringen. Die meisten Datenbanken komprimieren die Daten auch selbst default, aktive ZFS-Kompression konterkariert das. Wenn Kompression, dann nur eins davon. Da hilft nur selbst benchen.
Es macht natürlich auch den Unterschied von wo aus man misst...entweder direkt im heimischen LAN mit GBit oder unterwegs am Smartphone mit einem Balken Signalstärke. Zwei Maschinen (1x DB, 1x Webserver) wären natürlich das Optimum.

Außerdem habe ich gelesen (selbst nicht getestet), dass Nextcloud (php, Postgres etc.) auf ubuntu deutlich schneller sei, als auf freebsd, da daraufhin optimiert.

Nicht alles im Netz ist auch wahr oder es kann anders gemeint sein. Hast du den Link noch?

 

[medV2]

Ich habe eine NC auf Linux (RHEL9) und ich hatte vor langer Zeit eine NC auf FreeBSD. Performancemonster ist weder das eine, noch war es das andere..

Ich denke Optimierungsmöglichkeiten gibt es bei NC genug, das OS sollte da eher als eine der letzten gesehen werden. Ordentliche Datenbank (Postgresql) und auch ordentlich konfiguriert (hier gibt es leider kein Patentrezept, hängt stark von Nutzung und HW ab), ObjectCache (REDIS) - ordentlich konfiguriert, und ab einer gewissen Größe auch Webserver und php-fpm, bzw. das man php-fpm verwendet.

Unter FreeBSD war für solche Anwendungsfälle (Auslieferung über php-fpm / statischer Content ) mal lighttpd um die 10% schneller als apache oder nginx. Das hatte auch einen Grund (er machte irgendwelche Syscalls anders). Ob das noch so ist weiß ich tatsächlich nicht, müsste man testen, ist schon 5-8 Jahre altes Wissen.

 

[turrican]

db auf nvme Bin ich gerade dabei aufzusetzen, verspreche mir davon auch etwas mehr Performance.

die db lag bei mir in beiden Fällen (FreeBSD wie Linux) auf ner ssd - und eine nvme hat ja doch wesentlich mehr Schreib-/Lese-Performance im Vergleich dazu, das solte also schon was bringen:
beobachte doch auch mal die oc_filecache table - die explodierte bei mir innerhalb von Tagen größenmäßig nach oben (unter mariadb, unter postgres hatte ich das nicht mehr so weit getestet);

Tuningparameter werde ich mal probieren.

ansonsten wie @mr44er schon schrieb, falls zfs, das zfs auf die db und die db aufs zfs abstimmen (recordsize, cache, metadata etc), die Datenbank (mariadb) braucht ein paar Grundeinstellungen, z.B. read-committed, utf8mb4_general_ci etc

Die nextcloud selber hat eigentlich relativ wenig Stellschrauben, die Komplexität ergibt sich eher aus dem Zusammenspiel der verschiedenen Komponenten: Filesystem, Datenbank, webserver samt php/fpm, Caching (redis, memcached, evtl vielleicht sogar schon dragonfly) etc; viel RAM und hohe random-I/O-capability scheint nicht zu schaden; zu den Setups gibts haufenweise (teils widersprüchliche) Doku im Netz, ich kann dir bei offenen Fragen gern auch in meinen Notizen von damals nachschlagen;

 

[Columbo0815]

die db lag bei mir in beiden Fällen (FreeBSD wie Linux) auf ner ssd - und eine nvme hat ja doch wesentlich mehr Schreib-/Lese-Performance im Vergleich dazu, das solte also schon was bringen:
beobachte doch auch mal die oc_filecache table - die explodierte bei mir innerhalb von Tagen größenmäßig nach oben (unter mariadb, unter postgres hatte ich das nicht mehr so weit getestet);

Ich würde hier mal von einem Bug ausgehen, in den du gelaufen bist. Ich habe meine Nextcloud-Installation mindestens seit 2017 laufen. Aktuell liegen da 325 GB. Die von dir genannte Datenbank hat hier (mysql) gerade mal 21 MB.

 

[midnight]

Ich kann jetzt nicht von Nextcloud reden, denn ich nutze Syncthing ueber Wireguard auf meinem Server um meine ganzen Clients (Desktops, Smartphones) zu synchronisieren und das sind teilweise einige 100 GB, darunter auch die Fotos der Smartpones. Ich habe hier volle Bandbreite meiner Netzwerkinterfaces, die CPUs sind am dauer-IDLEn und der RAM-Verbrauch ist auch minimal. Zu Performanceeinbruechen kann es kommen, wenn die Limits wie kern.maxfiles in der sysctl.conf und openfiles-{cur,max} in der login.conf zu klein eingestellt sind. Steht aber meinstens auch in den pkg-readmes, brauch ich ja nicht zu sagen. ;-)

 

[pbtraveller]

Ich habe aktuell noch eine sqlite im Einsatz, was vermutlich einer der größten Flaschenhälse ist und die Version ist aktuell auch noch auf 27.XX hatte die letzten Monate null Zeit, mich mal darum zu kümmern. Das Update auf die aktuell v30 verursacht immer ein Fehler. Laut Fehlermeldung geht das Update zwischen all diesen Versionen auf einmal nicht. Hab schon versucht, das "manuell" von Version zu Version upzugraden, indem ich immer die letzte fetche, entpackt und dann per cp -R nextcloud/* /usr/local/www/nextcloud/ drüberbügel. Leider hat das auch nicht funktioniert, da ein App-update immer zu eine Fehler und der zu irgend einem DB-lock geführt hat. Hat jemand eine Empfehlung, wie ich am schnellsten und einfachsten auf die aktuelle Version komme, so dass ich dann noch mal die DB-Migration versuchen kann (oder würdet ihr die DB-Migration erst versuchen und dann die updates?).

 

[medV2]

Ich habe aktuell noch eine sqlite im Einsatz, was vermutlich einer der größten Flaschenhälse ist und die Version ist aktuell auch noch auf 27.XX hatte die letzten Monate null Zeit, mich mal darum zu kümmern. Das Update auf die aktuell v30 verursacht immer ein Fehler. Laut Fehlermeldung geht das Update zwischen all diesen Versionen auf einmal nicht. Hab schon versucht, das "manuell" von Version zu Version upzugraden, indem ich immer die letzte fetche, entpackt und dann per cp -R nextcloud/* /usr/local/www/nextcloud/ drüberbügel. Leider hat das auch nicht funktioniert, da ein App-update immer zu eine Fehler und der zu irgend einem DB-lock geführt hat. Hat jemand eine Empfehlung, wie ich am schnellsten und einfachsten auf die aktuelle Version komme, so dass ich dann noch mal die DB-Migration versuchen kann (oder würdet ihr die DB-Migration erst versuchen und dann die updates?).

Von SQLite solltest du auf jedenfall weg, es wird bei der Installation soweit ich mich erinnere auch deutlich davon abgeraten, SQLite für Produktivumgebungen zu nutzen. Ich würde direkt zu Postgressql wecheln, aber auch mariadb sollte schon deutlich spürbar sein!

Version 27 wird ja schon nicht mehr unterstützt, auch aus dem Sicherheitsaspekt solltest du da schnell wechseln. Sind Upgrades mit Überspringen von Versionen bei NC zulässig? Ansonsten würde ich mal 27->28->29->30 probieren. Upgradeempfehlung hab ich keine, da ich unter Linux die Community-Docker-Images verwende.

 

[CommanderZed]

Von SQLite solltest du auf jedenfall weg, es wird bei der Installation soweit ich mich erinnere auch deutlich davon abgeraten, SQLite für Produktivumgebungen zu nutzen. Ich würde direkt zu Postgressql wecheln, aber auch mariadb sollte schon deutlich spürbar sein!

Version 27 wird ja schon nicht mehr unterstützt, auch aus dem Sicherheitsaspekt solltest du da schnell wechseln. Sind Upgrades mit Überspringen von Versionen bei NC zulässig? Ansonsten würde ich mal 27->28->29->30 probieren. Upgradeempfehlung hab ich keine, da ich unter Linux die Community-Docker-Images verwende.

Ich würde keine Version überspringen wenn kein notfall vorliegt.

Mit dem aktuellen Kommandozeilenupdater oder auch dem Webupdater sind die updates ja inzwischen sehr sehr schnell. Ich hab nicht gemessen aber ich würde sagen selbst bei Major sprüngen unter einer Minute, auch schon unter OpenBSD bei mir. (Dabei hab ich, als tipp, den cli-updater als ne ecke schneller empfunden)

Und ja, auf ein unterstütztes *SQL wechseln wäre der erste absolut wichtigste Schritt (Ich verwende Maria).

 

[SolarCatcher]

Tipps zum Anlegen der ZFS-Datasets für MySQL/MariaDB finden sich in der server.cnf.sample der MariaDB-Server Ports von FreeBSD. Ich habe keine Ahnung, wie gut die wirklich sind, ich gehe aber davon aus, dass da jemand mehr Ahnung hatte als ich. Daher nutze ich diese Einstellungen seit Jahren.

# [mysqld] configuration for ZFS
# From https://www.percona.com/resources/technical-presentations/zfs-mysql-percona-technical-webinar
# Create separate datasets for data and logs, eg
# zroot/mysql      compression=on recordsize=128k atime=off
# zroot/mysql/data recordsize=16k

 

[turrican]

Ich würde hier mal von einem Bug ausgehen, in den du gelaufen bist. Ich habe meine Nextcloud-Installation mindestens seit 2017 laufen. Aktuell liegen da 325 GB.

möglich, und der wurde auch z.B. hier beschrieben, schon im Jahre 2017, ich hatte witzigerweise aber nichts mit "external Storage" gemacht in meinen Installs;

Die von dir genannte Datenbank hat hier (mysql) gerade mal 21 MB.

viel Daten war bei mir auch nicht drin (ein paar MB, datalength war klein), aber die table war sehr groß, vermutlich wegen der ganzen Indices

ich hab das dann nicht mehr weiter verfolgt, weil ich mit nextcloud nichts mehr gemacht habe - ich hatte über die Jahre die v17, die 25 und die 26 ausprobiert, und war jedes mal eher nicht so recht begeistert davon;

Ich habe aktuell noch eine sqlite im Einsatz

sqlite ist von nextcloud selber nur für testing und minimale Installationen gedacht
ich denke da an ne Installation auf dem Laptop zum mitnehmen und ausprobieren von Features unterwegs

 

[mr44er]

Die kurze Version: Wenn aus der Datenbank nur 16 oder 32kb gelesen werden müssen, dafür ZFS aber einen 128kb oder noch größeren Block zunächst einlesen und entpacken muss, gibt das Latenz und die will man tunlichst vermeiden.

Die lange Version: https://shatteredsilicon.net/mysql-mariadb-innodb-on-zfs/

Im Umkehrschluss für eine reine Dateiablage und wenn man weiß, dass die meisten Dateien sowieso über 1Mb groß sind, kann man getrost eine recordsize von 1M benutzen. Der nette Nebeneffekt dabei ist noch, dass man weniger Verschnitt hat und die Kompression besser abschöpft.

 

[Yamagi]

Datenbanken sind meist durch die Single Thread Leistung der CPU limitiert, profitieren also gerade bei komplexeren Queries durch den Turbo bzw. Boost der CPU. FreeBSD kann den in Standardeinstelltung aber nicht erreichen, Linux bei den meisten Distros schon. Je nach verbauter CPU kann das schon einiges ausmachen. Man sollte daher unter FreeBSD immer:

• performance_cx_lowest="LOW" in der rc.conf setzen, damit die niedrigst möglichen C-States genutzt werden. Das ist bei praktisch allen CPUs der letzten 10 Jahren C3, die tieferen Mode bis runter zu C8 regelt die CPU intern.
• Wenn es eine AMD-CPU oder eine Intel-CPU vor Skylake ist, muss powerd oder besser sysutils/powerdxx aus den Ports laufen. Neuere Intel-CPUs ab Skylake unterstützen hwpstate, d.h. der Kernel regelt die Frequenzen ohne Userland Daemon.

Damit erreicht man dann auch Turbo-Frequenzen.