Update von Deb 11 auf 12, Mariadb Performance schlecht

[HansGraefe]

Hallo,

ich habe letzte Woche ein Debian 11 auf 12 aktualisiert und dabei gleich wieder versucht, die Einstellungen in conf.d-Verzeichnisse auszulagern, damit die nächsten Upgrades die original Konfig-Dateien gleich überschreiben können. Leider ist seitdem die Performance des Systems unterirdisch, Mariadb rödelt wie blöd lesend auf der SSD rum (load average über 10) - allerdings nicht immer. Vor dem Upgrade lief es bestimmt ein Jahr sehr flott ohne Probleme. Ich habe die Einstellungen in die Datei /etc/mysql/mariadb.conf.d/70-einstellungen.cnf übertragen:

Code: Alles auswählen

[mariadb]
innodb_log_file_size   = 256M
max_allowed_packet     = 64M
bind-address           = 0.0.0.0

Ansonsten sollte alles auf Standard sein. Ich habe das System auch schon mehrmals neu gestartet, daran sollte es nicht liegen.
Auf dem System läuft ein Znuny 6.5.5 mit Mariadb und Apache2 in einer VM auf Proxmox. Keine eigenen Spiegel, nur Pakete aus dem offiziellen Repo.

Hat jemand eine Idee wo ich hier ansetzen könnte? Leider finde ich zB. in journalctl -f -u mariadb bzw journalctl -f nichts brauchbares:

Code: Alles auswählen

Aug 12 17:11:03 example.org systemd[1]: Stopping mariadb.service - MariaDB 10.11.6 database server...
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: FTS optimize thread exiting.
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Starting shutdown...
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Buffer pool(s) dump completed at 240812 17:11:03
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] InnoDB: Shutdown completed; log sequence number 341262223112; transaction id 816259193
Aug 12 17:11:03 example.org mariadbd[631]: 2024-08-12 17:11:03 0 [Note] /usr/sbin/mariadbd: Shutdown complete
Aug 12 17:11:03 example.org systemd[1]: mariadb.service: Deactivated successfully.
Aug 12 17:11:03 example.org systemd[1]: Stopped mariadb.service - MariaDB 10.11.6 database server.
Aug 12 17:11:03 example.org systemd[1]: mariadb.service: Consumed 3h 42min 43.094s CPU time.
Aug 12 17:11:17 example.org systemd[1]: Starting mariadb.service - MariaDB 10.11.6 database server...
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] Starting MariaDB 10.11.6-MariaDB-0+deb12u1 source revision  as process 2627725
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Number of transaction pools: 1
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Using generic crc32 instructions
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Using liburing
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Completed initialization of buffer pool
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: End of log at LSN=341262223112
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: 128 rollback segments are active.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: log sequence number 341262223112; transaction id 816259158
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] Plugin 'FEEDBACK' is disabled.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] Server socket created on IP: '0.0.0.0'.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] /usr/sbin/mariadbd: ready for connections.
Aug 12 17:11:17 example.org mariadbd[2627725]: Version: '10.11.6-MariaDB-0+deb12u1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Debian 12
Aug 12 17:11:17 example.org systemd[1]: Started mariadb.service - MariaDB 10.11.6 database server.
Aug 12 17:11:17 example.org /etc/mysql/debian-start[2627744]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Aug 12 17:11:17 example.org /etc/mysql/debian-start[2627752]: Checking for insecure root accounts.
Aug 12 17:11:17 example.org mariadbd[2627725]: 2024-08-12 17:11:17 0 [Note] InnoDB: Buffer pool(s) load completed at 240812 17:11:17

Edit: einige Inhalte entfernt weil sie mit dem Problem nichts zu tun haben. Sorry dafür.

[MSfree]

Ich hätte noch zwei Screenshots von htop zur hohen Last, kann sie aber nicht anhängen.

Ich könnte dir zwar verraten, wie man Bilder hier ins Forum bekommt, aber wer lesen kann, ist klar im Vorteil. (Wichtiger Hinweis: Bevor Du einen Beitrag postest: oberhalb des Editorfensters, alle 6 Zeilen lesen!)

Andererseits, htop liefert Textausgaben in ein Terminal. Die kann man per Copy'n'Paste direkt ins Forum schreiben, ohne sie um den Faktor 100 als Bild aufzublasen.

Davon abgesehen, was soll und die htop-Ausgabe sagen? Daß du hohe CPU-Last und ggfls. auch hohe IO-Last hast, hast du ja schon gesagt. Mehr sagt die Textausgabe von htop auch nicht und ein Bild erst recht nicht.

Wenn du no space left on device bekommst, solltest du dich darum kümmern. Hast du /tmp als eigene Partition oder als tmpfs eingerichtet?

[HansGraefe]

Ich könnte dir zwar verraten, wie man Bilder hier ins Forum bekommt, aber wer lesen kann, ist klar im Vorteil. (Wichtiger Hinweis: Bevor Du einen Beitrag postest: oberhalb des Editorfensters, alle 6 Zeilen lesen!)

Ich bitte vielmals um Entschuldigung, das habe ich übersehen.

Wenn du no space left on device bekommst, solltest du dich darum kümmern. Hast du /tmp als eigene Partition oder als tmpfs eingerichtet?

Die Ursache dafür ist mir bekannt, das ist, denke ich, nicht die Ursache des Problems weil das schon paar Monate vor dem Upgrade so lief und keine Probleme machte. Eventuell hätte ich es gar nicht erwähnen sollen, auch dafür Entschuldigung. df -h zeigt:

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev             13G       0   13G    0% /dev
tmpfs           2,5G    660K  2,5G    1% /run
/dev/sda1       485G    378G   83G   83% /
tmpfs            13G       0   13G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           2,5G       0  2,5G    0% /run/user/1000

[MSfree]

Die Ursache dafür ist mir bekannt, das ist, denke ich, nicht die Ursache des Problems weil das schon paar Monate vor dem Upgrade so lief und keine Probleme machte. Eventuell hätte ich es gar nicht erwähnen sollen

Nunja, die Meldung in deinem Log besagt ja nicht nur, daß kein Platz auf /tmp ist, sie besagt vor allem auch

Code: Alles auswählen

waiting for someone to free some space... 

Wenn mariadb hier nun durch Polling ständig nach freiem Platz sucht, kann das die CPU und die SSD stark belasten.

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev             13G       0   13G    0% /dev
tmpfs           2,5G    660K  2,5G    1% /run
/dev/sda1       485G    378G   83G   83% /
tmpfs            13G       0   13G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           2,5G       0  2,5G    0% /run/user/1000

Das sieht nicht so aus, als on /tmp auf einer eigenen Partition bzw. als tmpfs angelegt ist. 83GB freier Platz auf der root-Partition erklärt ebenfalls nicht, warum auf /tmp kein Platz mehr ist.

[HansGraefe]

Die Ursache dafür ist mir bekannt, das ist, denke ich, nicht die Ursache des Problems weil das schon paar Monate vor dem Upgrade so lief und keine Probleme machte. Eventuell hätte ich es gar nicht erwähnen sollen

Nunja, die Meldung in deinem Log besagt ja nicht nur, daß kein Platz auf /tmp ist, sie besagt vor allem auch

Code: Alles auswählen

waiting for someone to free some space... 

Wenn mariadb hier nun durch Polling ständig nach freiem Platz sucht, kann das die CPU und die SSD stark belasten.

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev             13G       0   13G    0% /dev
tmpfs           2,5G    660K  2,5G    1% /run
/dev/sda1       485G    378G   83G   83% /
tmpfs            13G       0   13G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           2,5G       0  2,5G    0% /run/user/1000

Das sieht nicht so aus, als on /tmp auf einer eigenen Partition bzw. als tmpfs angelegt ist. 83GB freier Platz auf der root-Partition erklärt ebenfalls nicht, warum auf /tmp kein Platz mehr ist.

Jeden Samstag um 0:00 schreibe ich eine Datei voll mit Nullen (dd if=/dev/zero of=/root/testdatei ; rm /root/testdatei) bis / voll ist, danach lösche ich die Datei wieder. Genau in der Zeit sind auch die "No space left on device"-Meldungen, natürlich ist da mal kurz / voll, aber die Datei wird ja wieder gelöscht. Ich denke diese Meldungen bekomme ich weg, wenn ich vor dem Schreiben der Datei mysql runterfahre und danach wieder hochfahre.

[MSfree]

Jeden Samstag um 0:00 schreibe ich eine Datei voll mit Nullen (dd if=/dev/zero of=/root/testdatei ; rm /root/testdatei) bis / voll ist

Wozu soll das gut sein?

[HansGraefe]

Jeden Samstag um 0:00 schreibe ich eine Datei voll mit Nullen (dd if=/dev/zero of=/root/testdatei ; rm /root/testdatei) bis / voll ist

Wozu soll das gut sein?

Das hatte ich eingerichtet, weil die Backups der VM von Proxmox größer wurden als die Daten in der VM selbst und weder die Option discard noch fstrim etwas gebracht haben.

[slu]

Jeden Samstag um 0:00 schreibe ich eine Datei voll mit Nullen (dd if=/dev/zero of=/root/testdatei ; rm /root/testdatei) bis / voll ist

Wozu soll das gut sein?

Das hatte ich eingerichtet, weil die Backups der VM von Proxmox größer wurden als die Daten in der VM selbst und weder die Option discard noch fstrim etwas gebracht haben.

Vielleicht sinnvoller diesem Problem auf den Grund zu gehen anstatt den Server bewusst gegen die Wand zu fahren, das ist ein Glücksspiel.

[KP97]

Und noch ein Hinweis an den TE:
Bitte keine Vollzitate, das erschwert das Lesen ungemein, da man den ganzen Kram ja bereits vorher gelesen hat.
Also ausschließlich den Satz zitieren, auf den man sich beziehen will, und das Ganze wird übersichtlich.

[slu]

Die Kritik gilt auch für mich