Nextcloud 23 die Performance eine Katastrophe!

Nach dem Update auf Nextcloud 23 ist die Performace nun mehr als schlecht. Unter 22 hatten wir auch ab und zu peeks aber jetzt warten wir nur noch.
php-fpm und mysql/mariadb Prozesse liegen oft bei 100 % oder höher. Mariadb tillt vor allem bei external_storage mounts und bei der mail app.

grafik

Die Daten meines Servers:
Centos 7x64
Prozessor: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (12 cores)
Speicher: 125.73 GB

Swappen trotz genĂŒgend zugewiesnem Speicher!
grafik

Apache im http2 modus:
Server version: Apache/2.4.43 (codeit)
Server built: Apr 25 2020 01:28:33
Server’s Module Magic Number: 20120211:92
Server loaded: APR 1.7.0, APR-UTIL 1.6.1
Compiled using: APR 1.7.0, APR-UTIL 1.6.1
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)

PHP /php-fpm 7.3.12
Arbeitsspeucher-Grenzwert 16 GB
Max Upload 10 GB

redis.x86_64 3.2.12-2.el7
mariadb 4.10.12
Datenbank GrĂ¶ĂŸe 2,5GB

Unsere php.config Sektion caching:
‘memcache.local’ => ‘\OC\Memcache\APCu’,
‘filelocking.enabled’ => ‘true’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘memcache.distributed’ => ‘\OC\Memcache\Redis’,
‘redis’ =>
array (
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0.0,
),
Wir können hier keinen redis-socket einsetzen weil auf dem gleichen Host onlyoffice documentserver lÀuft.

redis.conf:
bind 127.0.0.1
port 6379
tcp-keepalive 300

php-fpm.conf:
include=/etc/php-fpm.d/*.conf
pid = /run/php-fpm/php-fpm.pid
error_log = /var/log/php-fpm/error.log
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10

php-fpm → www.conf:
[www]
user = apache
group = apache
listen = 127.0.0.1:9000
pm = dynamic
pm.max_children = 296
pm.start_servers = 147
pm.min_spare_servers = 98
pm.max_spare_servers = 197
pm.max_requests = 1000
request_terminate_timeout = 3600

10-opcache.ini:
zend_extension=opcache
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=1
opcache.max_file_size=0
opcache.file_cache_only=0
opcache.huge_code_pages=0

30-pdo_mysql.ini:
; Enable pdo_mysql extension module
extension=pdo_mysql

mariadb–> server.cnf:
[server]

skip-name-resolve = 1
innodb_buffer_pool_size = 6000M
#innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 32M
innodb_max_dirty_pages_pct = 90
query_cache_type = 1
query_cache_limit = 2M
query_cache_min_res_unit = 2k
query_cache_size = 64M
tmp_table_size= 64M
max_heap_table_size= 64M
slow-query-log = 1
bind-address = 127.0.0.1
slow_query_log_file = /var/log/mysql/mysql.log
key_buffer_size = 128M

lc_messages_dir = /usr/share/mysql
lc_messages = en_US
log_slow_verbosity = query_plan
log_warnings = 2
long_query_time = 1
max_allowed_packet = 16M
max_binlog_size = 100M
max_connections = 200
myisam_recover_options = BACKUP
myisam_sort_buffer_size = 512M
read_buffer_size = 2M
read_rnd_buffer_size = 1M
skip-external-locking
sort_buffer_size = 4M
table_open_cache = 400
thread_cache_size = 128
tmp_table_size = 64M
wait_timeout = 600

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
transaction_isolation = READ-COMMITTED
binlog_format = ROW
innodb_large_prefix=on
innodb_file_format=barracuda
innodb_file_per_table=1
innodb_open_files = 400
innodb_io_capacity = 4000
innodb_flush_method = O_DIRECT
concurrent_insert = 2
connect_timeout = 5
expire_logs_days = 2

[client]
default-character-set = utf8mb4

[galera]

[embedded]

[mariadb]

[mariadb-10.4]
[mysqldump]
max_allowed_packet = 16M
quick
quote-names
[isamchk]
key_buffer = 16M

In den LOG-dateien von php-fpm nur das ĂŒbliche:
[17-Mar-2022 09:30:37] NOTICE: [pool www] child 13848 started
[17-Mar-2022 09:30:55] NOTICE: [pool www] child 8375 exited with code 0 after 163727.286687 seconds from start

Nextloud/mariadb log finde ich auch keinen Anhaltspunkt?
redis auch nur das ĂŒbliche:
1877:M 17 Mar 09:29:51.929 * Background saving terminated with success
1877:M 17 Mar 09:34:52.029 * 10 changes in 300 seconds. Saving

1877:M 17 Mar 09:34:52.031 * Background saving started by pid 16768
16768:C 17 Mar 09:34:52.807 * DB saved on disk
16768:C 17 Mar 09:34:52.809 * RDB: 3 MB of memory used by copy-on-write
1877:M 17 Mar 09:34:52.832 * Background saving terminated with success
1877:M 17 Mar 09:39:53.063 * 10 changes in 300 seconds. Saving

1877:M 17 Mar 09:39:53.065 * Background saving started by pid 20041
20041:C 17 Mar 09:39:53.887 * DB saved on disk
20041:C 17 Mar 09:39:53.889 * RDB: 4 MB of memory used by copy-on-write
1877:M 17 Mar 09:39:53.967 * Background saving terminated with success

Kann mir jemand weiterhelfen?

Dass swap verwendet wird hat nichts mit nextcloud zu tun, sondern wie linux seinen speicher verwaltet. Wenn man nicht möchte dass swap verwendet wird aktiviert man ihn einfach nicht.

Dass einzelne Kerne voll ausgelastet sind muss ja nichts schlechtes sein dafĂŒr hat man die Kerne ja (Und die meisten aktionen in php & mysql sind nunmal single-threaded, daher springt nunmal ein kern auf 100%, dass ist normal ).

Du hast auch noch nicht erwĂ€hnt wie sich die schlechte Performance zeigt, also ob die Seite langsam/nicht lĂ€dt o.Ă€. Wenn man dass wĂŒsste könnte man dort beim optimieren helfen.

Ich wĂŒrde mal sagen, dass MariaDB das Problem ist.
Laut Top sind es 12,9g VIRT und 7,2g RES.
Eine Idee habe ich leider nicht.
Vielleicht hat jemand ein paar Tipps in die Richtung.

Zur Optimierung gibt es ein paar Seiten. Evtl. helfen mehr Pool Instances:
https://www.saotn.org/mysql-innodb-performance-improvement/

Und es gibt auch so Analyse-Scripts, die die aktuelle Nutzung mit der Konfiguration vergleichen und VorschlÀge machen: mysqltuner.pl, tuning-primer.sh

Wenn das mit dem Update zusammenhĂ€ngt, evtl. braucht die neue Version mehr Indizes in der Datenbank (gibt eine Warnung im Admin-Interface). Oder ĂŒber die Slow-Queries etc. schauen, wo das verursacht wird, kann auch ein Bug sein.

Na wie sich das zeigt: Man wartet 30 Sekunden oder mehr bis sich die Seite aufbaut. Schon allein wenn man auf den Datei Aktenreiter zugreift,
grafik
Top wÀhrend der Ladezeit. Immer wieder hohe Ladezeiten auch REDIS

Dann schmeiß doch Redis erst mal raus. Wie viele Tausend Benutzer und verschiedene Systeme hast du, dass sich Redis wirklich lohnt? Starte auch mal deine MariaDB neu und poste evtl. Fehler und den Speicherverbrauch. Vielleicht kann man die MariaDB auch neu strukturieren lassen. Leider kenne ich mich damit gar nicht aus.

Dass redis bei dir dabei auffĂ€llt ist echt interressant, da es bei dir nur fĂŒr das file-locking und dem distributed cache verwendet wird. Und das sollte eigendlich recht schnell gehen.

Als beispiel:

auf meiner instanz (25 user, 997610 Dateien ) benutzt redis 10MB, was selbst bei deiner recht alten CPU sehr schnell verarbeitet sein sollte.

127.0.0.1:6379> info memory
# Memory
used_memory:2313928
used_memory_human:2.21M
used_memory_rss:11288576
used_memory_rss_human:10.77M
used_memory_peak:2960176
used_memory_peak_human:2.82M
used_memory_peak_perc:78.17%
used_memory_overhead:1131944
used_memory_startup:809880
used_memory_dataset:1181984
used_memory_dataset_perc:78.59%

Redis deaktivieren wĂŒrde ich nicht empfehlen, dann wĂŒrde das file-locking ĂŒber die db geregelt werden, und dass ist langsamer. (außerdem hast du ja genĂŒgend arbeitsspeicher dafĂŒr).

Kannst du mal im Hintergrund iostat -x 1 mitlaufen lassen, die seite neuladen und den output davon posten?

grafik

ich hatte so nen gefĂŒhl dass einiges deiner cpu last durch den io zustande kommt, dass sieht aber nicht so aus.

Selbst mit der recht alten CPU und Software auf dem Server solltes es (nach meinem bauchgefĂŒhl) nicht 30 Sekunden zum laden brauchen.

Aber ohne handfeste Daten kann man da jetzt schlecht irgendwas empfehlen.
Und bevor man anfÀngt jetzt performance probleme mit mariadb 4.10.12 auf einem centos 7 zu debuggen wÀre die frage ob man dass ganze nicht auf einen modernen stack umzieht und sich dass ganze dann nochmal anschaut da dort nicht nur die performance meist besser ist sondern auch die debugging/profiling möglichkeiten

@mueller
Hast du mal die MariaDB neu gestartet? Gibt es dort irgendwelche AuffĂ€lligkeiten? Vielleicht kennt jemand Analysetools fĂŒr MariaDB, um ineffektive Datenstrukturen zu erkennen.

Ich könnte mir vorstellen, dass die Nextcloud z. B. aufgrund eines Konfigurationsfehlers Tausende oder Millionen von EintrÀge unnötig in der Datenbank speichert. Kennt vielleicht jemand einen Befehl, wo man die MariaDB nach EintrÀgen sortiert nach Menge ausgeben kann? Das könnte vielleicht interessant sein.

Ja, Mariadb neugestartet usw

Ich habe mittlerweile festgestellt, dass in der Datenbank die Benutzer gedoppelt eingetragen sind. Einmal erscheinen sie verschlĂŒsselt mit einem langen Hashcode und dann noch im Klartext. Also gehe ich davon aus das die Datenbank das problem ist. Nur wie bekomme ich die wieder sauber?
Beispiel:
drwxr-xr-x 3 apache apache 27 17. Okt 2019 F9E17592-C4EE-403B-AF00-0CE33E4F9435

drwxr-xr-x 7 apache apache 118 20. Jul 2021 mueller

Hat jemand eine Idee?

du erwÀhnst die datenbank, zeigst aber ein dir listing des data verzeichniss.

user verzeichnisse mit einer UUID werden z.b. erstellt wenn man LDAP als authentifizierungsbackend verwendet.

Die tabelle oc_mounts sollte hier helfen können.

Generell wĂŒrde ich dir raten beim debuggen von performance problemen nicht zu vermuten sondern feste daten zu benutzen. Also z.b. mal den aufruf zu profilen (xdebug mit valgrind ist da recht praktisch auf der php seite, das slowquerylog von mysql fĂŒr die datenbank seite) und darauf basierend schlĂŒsse zu ziehen.

1 Like

@mueller
Ich bin auch kein Datenbankexperte. Aber eine Datenbank ist nicht das, was du darstellt. Du zeigst irgendwelche Verzeichnisse. Du kannst erst mal das lesen, um zu verstehen, was eine MariaDB-Datenbank ungefĂ€hr ist. Und dann können wir zurĂŒck zu der Frage kommen, warum sie so viel Speicher braucht. DafĂŒr musst du Lösungen finden, wie du an mehr Details der Datenbank kommst.

1 Like

Also, definitiv ist das nicht die Datenbank
 aber so stellt sich das im Dateiverzeichnis dar. ZunĂ€chst mein User-Verzeichnis in “Klartext” und dasselbe in einem Hashcode
 Ich werde wohl neu installieren


Deine Datenbank braucht 12,9 GB RAM (erster Eintrag top). Da kann doch irgendwas nicht in Ordnung sein. Daher könntest du versuchen dich in Richtung MariaDB weiterzubilden. Du kannst natĂŒrlich auch den Windows-Weg gehen: plattmachen, neu installieren und nichts lernen.

Das sag ich doch die Datenbank ist durch irgendetwas beschÀdigt oder arbeitet nicht richtig


Ok. Dann beschĂ€ftige dich einfach mit dem Dump (Backup) von Datenbanken, lösch die Datenbank und fĂŒhre ein Restore durch. Es kann aber sein, dass selbst der Dump dann fehlerhaft ist. Das wĂ€re schlecht. Es gibt auch Befehle zur Neustrukturierung von Datenbanken, Ermittlung der grĂ¶ĂŸten Strukuren usw. Leider kenne ich mich damit wenig aus. Ich mĂŒsste mich damit auch erst beschĂ€ftigen. Aber ich denke es gibt genug Anleitungen im Internet zur Optimierung von MariaDB. Vielleicht mĂŒllt dir auch irgendwas die Datenbank voll wie z. B. Nextcloud-AktivitĂ€ten usw.

Habe ich bereits gemacht. Einen Dump erstellt. Auf einem anderen Server importiert. Das gleiche Problem. Die Performance ist einfach unterirdisch und auch hier frisst die Datenbank zu viel Speicher


Hast du mal versucht die Datenbank nach EintrÀge zu sortieren. Ich habe z. B. das gefunden. Die wirkliche Ursache ist wahrscheinlich eher ein Fehler in deiner Nextcloud als in der Datenbank.

Im Moment lasse ich einen check und ein optimize laufen.
Ich schaue mir den Link an. Vielen Dank

note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_attachments
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_classifiers
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_coll_addresses
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_mailboxes
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_message_tags
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_messages
note : Table does not support optimize, doing recreate + analyze instead
status : OK
nextcloud.oc_mail_provisionings
note : Table does not support optimize, doing recreate + analyze instead