NextCloud lädt im Webinterface lange

[ramsey]

Ich habe das bei uns so (die Werte, die gleiche Zahlen haben, sollten auch gleich sein, z.B. max_heap_table_size und tmp_table_size sowie die drei Werte mit der 32000).
Den Kram für MyISAM kannst Du ignorieren.

skip-external-locking   = 1
skip-name-resolve       = 1

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = localhost

#
# * Fine Tuning
#
join_buffer_size        = 2M
key_buffer_size         = 2048M
bulk_insert_buffer_size = 32M
max_allowed_packet      = 256M
thread_stack            = 2048K
thread_cache_size       = 384
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam_recover_options  = BACKUP,FORCE
myisam_sort_buffer_size = 64M
max_connections        = 450
table_cache            = 32000
table_open_cache        = 32000
max_heap_table_size     = 512M
#thread_concurrency     = 10
concurrent_insert       = 2
connect_timeout         = 15
read_buffer_size        = 2M
#select_into_buffer_size        = 2M
read_rnd_buffer_size    = 8M
sort_buffer_size        = 1M
tmp_table_size          = 512M
transaction_isolation   = READ-COMMITTED
table_definition_cache  = -1


# * Query Cache Configuration
#
query_cache_limit       = 2M
query_cache_size        = 64M
query_cache_type        = 1
query_cache_min_res_unit= 2k

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
general_log_file        = /var/log/mysql/mysql.log
general_log             = 0
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
expire_logs_days        = 7
max_binlog_size         = 100M
binlog_format           = ROW
#binlog_do_db           = include_database_name
#binlog_ignore_db       = exclude_database_name

#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
innodb_buffer_pool_size=4G
innodb_io_capacity=1000
innodb_buffer_pool_instances=4
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=64M
innodb_max_dirty_pages_pct=90
innodb_file_per_table=1
innodb_open_files=32000
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G

[isamchk]

key_buffer = 2048M

[Dennis1993]

Vielen vielen Dank!

Ich habe die Werte mal angepasst und beobachte es wieder ein paar Tage

Es ist leider wirklich so, dass man auf jeder Website etwas anderes liest. Die einen sagen, je mehr desto besser (was ich mir nicht vorstellen kann, weil die Ressourcen halt auch Grenzen haben) und andere sagen, es reichen die Einstellungen die von NextCloud vorgegeben werden. Hier ist halt immer die Frage, wie groß betreibt man die Systeme. Für 5 User wird das mit Sicherheit gehen. Mit 500 wäre ich wiederum skeptisch
Hier fände ich eine grobe Richtung seitens NextCloud Dokumentation sinnvoll, wo man sagt für X Benutzer hat sich folgende Konfiguration als gut erwiesen und für große Instanzen mit z.B. bis zu 100 gleichzeitigen Benutzern hat sich folgende Konfiguration gut gemacht. Dann hätte man mal grobe Richtwerte und kann etwas abwägen.

Mir fehlt hier irgendwie eine gute Erklärung, wie man so etwas sauber und sinnvoll einstellt. Ich sehe auch bei meinem System den RAM in htop nie über 6 GB gehen obwohl ich ja 16GB zugewiesen habe. Also wäre ja theoretisch genug Luft nach oben.

Meine letzte Konfig wie oben gepostet ist per MySQL-Tuner gemacht. Danach lief es auch schon etwas geschmeidiger. Allerdings hat das Script durchgehend etwas zu “meckern” Wenn ich es jetzt nach der Anpassung wieder starte, meldet er immer die 2 Variablen. Mal sind sie zu klein, mal zu groß…

Variables to adjust:
    join_buffer_size (> 2.0M, or always use indexes with JOINs)
    key_buffer_size (~ 3M)

Vielen Dank nochmals für die Mühe und Unterstützung!

[ramsey]

Hey Dennis,

wenn Du table_definition_cache = -1 setzt (Automatik), dann bist Du das Gemecker vom SQL Tuner wegen der join_buffer_size los und es ist tatsächlich so, dass bei manchen Variablen viel viel hilft und bei anderen ist viel schädlich.
Es gibt doch keine einfache Regel für alles, ohne dass man wissen müsste, was was tut.
Da, wo ich die 32000 eingetragen habe, hilft viel.
Bei innodb_buffer_size hilft auch viel, allerdings muss die innodb_log_file_size 25 Prozent davon betragen.
Setz die key_buffer_size einfach auf den Wert, den ich genannt habe, der SQL Tuner meckert vielleicht auch manchmal, wenn bestimmte variablen nur ein Vielfaches der Blocksize annehmen können und keine glatten Dezimalwerte.
Es ist in der Dokumentation bei MySQL ja alles gut beschrieben, da steht, wo viel hilft, wo viel schädlich ist und wann was hilft.
Bei 10 bis 300 Nutzern müsstest Du mit meiner Conf eigentlich ganz gut fahren.
Die Query Cache Size zum Beispiel sollte niemals größer als ein paar Zehner MB sein, nahezu egal wie viele Nutzer Du hast, nachzulesen bei MySQL.
Der innodb Buffer Pool muss natürlich bei einer Datenbank von 150 MB keine 8 GB betragen, aber das ist zumindest nicht schädlich.
Es ist wie beim Software Download: nur beim Hersteller bzw. Projekt, und bei MySQL bzw MariaDB ist das gut dokumentiert und die Default Werte sind meistens schon besser als die der Ego Tripper mit Optimierungswahn.
Dass Dein RAM nicht ausgelastet ist, hängt ja auch von der Größe der Datenbank und den tatsächlichen gleichzeitigen Verbindungen ab.
Bei der schädlichen Join Buffer Size von 64 MB bist Du bei 400 Verbindungen im Extremfall bei einem Speicherverbrauch von 50 bis 60 GB.
Wie gesagt, table_definition_cache bitte automatisch verwalten lassen und die Werte, bei denen ich eine 32000 habe, auch möglichst hoch, wie der RAM es zulässt, dann meckert der MySQL Tuner auch nicht mehr.
Gerade diese Werte zum Beispiel führen zu abhängigem Gemecker.
Hast Du da eine 16000 stehen, will der Tuner mehr table_definition_cache und da bei den Werten viel viel hilft und die Automatik das andererseits besser macht als ein statischer Wert, spricht nichts dagegen.
Versuch mal meine Konfiguration, die braucht maximal 14 GB RAM für den SQL Server und wenn das bei Deiner Maschine zu viel ist, setz die gigabytegroßen Werte runter, aber lass die kleinen MB-großen Werte so wie sie sind.
Im Internet findest Du halt viel von Leuten, die ihr Ego spazieren führen wollen und deshalb keine Zeit für Zusammenhänge haben.

Sei mir herzlich gegrüßt.
Du schaffst das schon.

Christian

[ramsey]

Noch ein Nachtrag:
Manche Werte sind ja pro Verbindung andere pro Abfrage, andere globalgalaktisch.
Es ist also restlos verblödet, im Internet pauschal zu behaupten, dass es bei vielen Nutzern sinnvoll wäre, die hochzusetzen, weil es bei einem Wert, der eine einzelne Abfrage betrifft, egal ist, ob Du 5 Nutzer hast oder 20000.
Außerdem hängt es ja stark von der Anwendung ab, wie viele Daten tatsächlich in der Datenbank gespeichert werden.
Nextcloud gibt ja eine Empfehlung, und die ist nicht dumm, denn sie betrifft vor allem die Werte, bei denen zu viel schädlich ist.
Ansonsten kann man das ja nicht pauschal pro Nutzer sagen, denn es hängt ja auch davon ab, wie Nextcloud genutzt wird.
Reine Dateien brauchen ja nur ein paar Verweise in der Datenbank.
Ob Du jetzt eine innodb Buffer Size von 512 MB oder mehreren GB brauchst, lässt sich ja herausfinden, ansonsten läuft es aber eigentlich immer besser mit Default Werten als mit Daumenregeln à la “viel hilft viel”.

[ramsey]

Die key_buffer_size ist übrigens eigentlich nur für MyISAM und 25 Prozent des RAMs sind laut MySQL ein akzeptabler Wert.
Also brauchst Du es erstens nicht, wenn Du nur Nextcloud mit InnoDB machst und zweitens wären 16 MB der Wert der 90er Jahre.

Ich bin 45 Jahre alt und früher gab es inkompetente bescheuerte Beraternutten, die ihre Kunden im Rahmen des QM für echtes Geld dazu gezwungen haben, auf Windows Server die Gruppe “Benutzer” überall durch “authentifizieren Benutzer” zu ersetzen, weil sich das nach Gefühlslage besser anhörte.
Konsequenz: plötzlich hatte jeder weitreichende Rechte, der sich auf irgendeinem Taschenrechner angemeldet hatte (authentifizierte Benutzer mit NTLM) und nicht mehr nur direkt auf der Maschine angemeldete Benutzer (die Gruppe Benutzer).
Weitere Konsequenz: Microsoft hat jegliche Gewährleistung gestrichen, da es sich nach dieser Modifizierung nicht mehr um ein Microsoft Betriebssystem handele.

Guckst Du also ausschließlich hier und überprüfst nur dort jeden Tipp vor der Umsetzung:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html

Hier:
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html

Und hier:
https://dev.mysql.com/doc/refman/8.0/en/optimization.html

[Dennis1993]

Ganz lieben Dank für deine ausführlichen Infos, habe nun beide Dateien mal verglichen und die Werte soweit angepasst wie du empfohlen hast.
Ab morgen arbeiten damit wieder einige Leute, ich bin gespannt und werde stetig selbst probieren wie es sich anfühlt von der Performance

Ich habe gerade auch mal bei phpmyadmin etwas geschaut und den Punkt “STATUS” gefunden. Hier gibt es auch einige Verbesserungsvorschläge im Punkt Ratgeber. Da stand auch deine Tipps teilweise schon bei:

Weiß nicht, ob du das kennst aber bestimmt.
Ich finde das echt interessant, was man da alles einstellen kann. Ich bin gerade wenige Jahre aus meiner Ausbildung raus und habe die Cloud quasi geerbt von einem Kollegen der jetzt in Rente ist inkl. einiger anderer Systeme.
Zu der Zeit hatten die Cloud nur sehr sehr wenige genutzt, da waren die Einstellungen wohl aber nicht so wichtig
Jetzt, wo ich einige dahin treibe, damit nicht alle OneDrive und Co. nutzen, merkt man natürlich die Performance-Probleme.

In meiner slow.log Datei, die die langsamen Queries aufzeichnet, finde ich auch oft folgenden Befehl. Ist das normal und bei dir auch?

SET timestamp=1699282965;
INSERT INTO `oc_mounts` (`storage_id`,`root_id`,`user_id`,`mount_point`,`mount_id`,`mount_provider_class`) SELECT '143','23561','5BC70623-7754-151B-BB41-FCE331D7FAF9','/5BC70623-7754-151B-BB41-FCE331D7FAF9/',NULL,'OC\\Files\\Mount\\LocalHomeMountProvider' FROM `oc_mounts` WHERE `root_id` = '23561' AND `user_id` = '5BC70623-7754-151B-BB41-FCE331D7FAF9' AND `mount_point` = '/5BC70623-7754-151B-BB41-FCE331D7FAF9/' HAVING COUNT(*) = 0;
# Time: 231107  1:01:04
# User@Host: nextcloud[nextcloud] @ localhost []
# Thread_id: 428016  Schema: nextcloud  QC_hit: No
# Query_time: 7.880230  Lock_time: 0.000047  Rows_sent: 0  Rows_examined: 1
# Rows_affected: 1  Bytes_sent: 52

Ich hoffe, dass das etwas bringt. Ich habe mir auch schon vorgenommen, wenn Ubuntu 24.04 released wird, den Server auf einen frisch installierten umzuziehen. Aktuell läuft er noch mit 20.04 von meinem Vorgänger. Ich weiß auch nicht 100%, was er da alles so eingestellt hat. Bisher eher weniger so wie es scheint

Vielen Dank nochmals für deine Mühe und nicen Infos! Das bringt mich wirklich weiter! :*

[ramsey]

Hey Dennis,

ich verstehe Dich gut.
Bei uns versuche ich dasselbe, damit die nicht immer von “irgendwas mit Cloud” bei Microsoft schwadronieren.

Wie es aussieht, solltest Du noch folgendes runtersetzen:

join_buffer_size            = 1M
read_buffer_size           = 1M
read_rnd_buffer_size   = 2M
sort_buffer_size            = 1M

Dann müsste das bei Dir super laufen.
Das mit der Speicheralloziierung ist echt ein Problem, wenn man viele Nutzer hat und irgendwas mal nicht in viel zu großen Caches gefunden werden kann.
Das wird schon!

Liebe Grüße

christian

[ramsey]

Hey Dennis, guten Morgen.

//Edit: ich habe anlässlich Deines Problems bei uns auch nochmal Tests gemacht und ein wichtiger Punkt ist, dass der Query Cache massive Skalierungsprobleme hat und sei MySQL 5.7 veraltet und in 8.0 komplett entfernt ist.
Es ist also vermutlich vernünftig, den abzuschalten, jedenfalls habe ich das jetzt bei uns getan:

query_cache_size        = 0
query_cache_type        = 0

Ich komme jetzt insgesamt für InnoDB auf dies hier (MyISAM benutzt Du ja wahrscheinlich nicht):

join_buffer_size        = 16M
#Nicht für InnoDB: key_buffer_size         = 256M
bulk_insert_buffer_size = 32M
max_allowed_packet      = 256M
thread_stack            = 2048K
thread_cache_size       = 384
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
# Nicht für InnoDB: myisam_recover_options  = BACKUP,FORCE
# Nicht für InnoDB: myisam_sort_buffer_size = 256M
max_connections        = 450
table_cache            = 16000
table_open_cache        = 16000
max_heap_table_size     = 512M
#thread_concurrency     = 10
concurrent_insert       = 2
connect_timeout         = 15
read_buffer_size        = 1M
#select_into_buffer_size = 1M
read_rnd_buffer_size    = 2M
sort_buffer_size        = 1M
tmp_table_size          = 512M
transaction_isolation   = READ-COMMITTED
table_definition_cache  = -1


# * Query Cache Configuration
#
query_cache_limit       = 2M
query_cache_size        = 0
query_cache_type        = 0
query_cache_min_res_unit= 2k

innodb_buffer_pool_size=4G
innodb_io_capacity=800
innodb_buffer_pool_instances=4
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=64M
innodb_max_dirty_pages_pct=90
innodb_file_per_table=1
innodb_open_files=16000
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G

[isamchk]

#Nicht für InnoDB: key_buffer = 256M

Du solltest zusätzlich noch checken, ob folgendes in Deiner Apache-Seiten-Konfig steht (mod_xsendfile aktivieren):

XSendFilePath /var/www/nextcloud
XSendFilePath /Dein/Datenverzeichnis/ausserhalb/des/Webroots
LimitRequestBody 0
php_admin_flag output_buffering off

In Deiner php.ini solltest Du darauf achten, dass der MySQL-Socket und der Redis-Socket auch erreichbar sind, falls Du eine open_basedir Direktive hast.
(Beispielsweise /var/run/mysqld und /var/run/redis, wo die Sockets drin sind.)

Diese Sachen sollten auf jeden Fall in Deiner php.ini drin sein (Performance, Sicherheit ist außen vor. Ich nehme an, dass Du ACPu und Redis nutzt):

apc.enabled=1
apc.shm_size=1024M
apc.num_files_hint=64000
apc.user_entries_hint=65536
apc.ttl=7200
apc.enable_cli = 1
apc.gc_ttl=3600
apc.entries_hint=65536
apc.slam_defense=1
apc.write_lock=1
apc.serializer=igbinary

[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1

; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli=1

; The OPcache shared memory storage size.
opcache.memory_consumption=1024

; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=64

; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 1000000 are allowed.
opcache.max_accelerated_files=60000

; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=1

; Enables or disables file search in include_path optimization
;opcache.revalidate_path=0

; If disabled, all PHPDoc comments are dropped from the code to reduce the
; size of the optimized code.
opcache.save_comments=1

SQL-mäßig sollte das in die php.ini:

[mysql]
mysql.allow_local_infile=On
mysql.allow_persistent=On
mysql.cache_size=8000
mysql.max_persistent=-1
mysql.max_links=-1
mysql.default_port=3306
mysql.default_socket=/var/run/mysqld/mysqld.sock
mysql.default_host=
mysql.default_user=
mysql.default_password=
mysql.connect_timeout=60
mysql.trace_mode=Off

Das war jetzt erstmal alles, was mir zum Thema Performance einfiel.

Dies hier würde ich verwerfen: “Eventuell musst Du, wenn viele Cache Prunes auftreten (MySQL Tuner sagt’s Dir) die Query Cache Size von MySQL doch noch erhöhen.”, und stattdessen den Query Cache deaktivieren, weil es ihn bald sowieso nicht mehr gibt.
Bei uns wurde dadurch die Performance des Dash Boards viel besser.

Komm gut in Deinen Tag!

[Dennis1993]

Hey,

vielen Dank nochmal für deine Hilfe!

Es läuft tatsächlich etwas runder, hatte heute mal eine Feedback-Runde gemacht und diverse Leute (die sich auch gerne oft gemeldet hatten bzgl. der Themen) zu diversen Systemen befragt, was wie gut/schlecht läuft aus deren Sicht.
Beim Thema NextCloud sei es wohl besser (vor allem bei Talk wäre es wohl spürbar und das Webinterface sei flotter), die Hänger ab und an nehme ich aber dennoch hin und wieder wahr, dass die Seite auf einmal über 5 Sekunden braucht zum laden, obwohl keinerlei Last erkennbar ist. Ich habe die letzten Tage auch immer htop auf meinem 2. Monitor offen gehabt um das beobachten zu können. Die Last ist wirklich immer nur minimal, auch das Monitoring (CheckMK) zeigt das gleiche Bild.

Wir alle arbeiten hierbei im Unternehmen und sind per 1GBit/s am Core-Switch angebunden, die Server sind mit 10GBit/s untereinander verfügbar. Hier sehe ich keine Probleme. Hier weiß ich noch nicht ganz wo das noch her kommt aber es ist auf jeden Fall schon deutlich besser