Wir führen Maria DB 10.6.9 auf CentOS aus und beobachten, dass der Speicherverbrauch weiter zunimmt. Serverspezifikationen: RAM – 128 GB vCPUs – 48 Swap – 100 GB
Wir haben innodb_buffer_pool auf 65 GB konfiguriert
Dennoch ist die Speichernutzung derzeit wie folgt:
Und wir beobachten weiterhin, dass der Swap-Satz weiter zunimmt.
Der Server ist für Mariadb bestimmt und es werden keine anderen Apps außer Mariadb darauf ausgeführt.
Unsere Belastung lässt nachts nach, aber MariaDB erholt sich scheinbar nicht und gibt keinen Speicher frei.
Wir haben einen ähnlichen DB-Server, auf dem MySQL 5.7.38 läuft, und sehen kein ähnliches Problem.
Wir sind für alle Erkenntnisse dankbar, die uns helfen können, Folgendes zu verstehen:
- Was verwendet den Speicher in MariaDB?
- Welche Tabellen werden in den Speicher geladen, was möglicherweise zu einer höheren Speichernutzung führt?
- Wie können wir Tools weiter analysieren, die uns Einblick in die Speichernutzung von MariaDB geben können?
Benötigen Sie möglicherweise weitere Informationen, um unsere Situation besser zu verstehen?
Nachfolgend finden Sie den aktuellen Innodb-Status: Innodb-Status
[Zusätzliche Informationen angefordert]
A:https://justpaste.it/cs5vw
B:https://justpaste.it/9868l
C:https://justpaste.it/8q99c
D:https://justpaste.it/byhv5
E:https://justpaste.it/cgnum
G:https://justpaste.it/ba5if
HTOP:https://justpaste.it/dd57f
Zusatzinformationen Teil 2
1)https://jpst.it/30ItC- oben -b -n 1
2)https://jpst.it/30OBo- oben -b -n 1 -H
3)https://jpst.it/30OGm- ulimit -a
4)https://jpst.it/30OKb- iostat -xm 5 3
5)https://jpst.it/30OME- df -h
6)https://jpst.it/30OPx- frei -h
7)https://jpst.it/30OQF- Katze /proc/meminfo
8)https://jpst.it/30OTB- df -ich
Antwort1
Mögliche Ursachen für die Speicherauslastung,
Normalerweise sehen wir ausgeglichene Zahlen für com_perpare_sql, com_execute_sql und com_dealloc_sql. In Ihrer Show wurde der globale Status com_dealloc_sql (schließen) 151.033 Mal verpasst, was bedeutet, dass Ressourcen innerhalb von 36 Tagen nicht freigegeben wurden.
Normalerweise sehen wir ausgeglichene Zählungen bei com_stmt_prepare, com_stmt_execute und com_stmt_close. In Ihrem globalen Status wurde com_stmt_close 373.474 Mal verpasst, was bedeutet, dass Ressourcen innerhalb von 36 Tagen nicht freigegeben wurden.
Es wurden 68.677 aborted_clients-Ereignisse gezählt, 78 davon pro Stunde, die zur Beobachtung beitragen könnten.
Der com_rollback-Zähler von 117.323, der im Durchschnitt alle 27 Sekunden einen Rollback ausführt, kann manchmal verhindert werden. Die Rollback-Verarbeitung ist ressourcenintensiv. Suchen Sie nach „So vermeiden Sie einen MySQL-Rollback“.
Bitte sehen Sie sich das Profil an, um Kontaktinformationen zu erhalten. Viele globale Variablen könnten angepasst werden, um die Leistung zu verbessern.