MySQL-Tuning – Hoher Speicherverbrauch

MySQL-Tuning – Hoher Speicherverbrauch

Ich versuche, eine MySQL-Datenbank mit mysqltuner zu optimieren. Mysqltuner empfiehlt mir, die Größe des Join-Buffers und des Query-Cache zu erhöhen. Gleichzeitig warnt es mich jedoch, dass meine maximale Speichernutzung hoch ist, nämlich bei über 200 % des installierten RAM (also 2 GB). Das Problem, in dem ich mich befinde, ist natürlich, dass die Speichernutzung noch weiter ansteigen wird, wenn ich das tue, was mysqltuner sagt. Was mache ich also hier? Liegt das Problem nicht bei mysql, sondern bei den Apps, die auf diesem Server laufen und offensichtlich eine riesige Menge an Caches von mysql erfordern? Wie würden Sie als MySQL-Administrator-Experten hier weiter vorgehen? Sehen Sie sich den mysqltuner-Bericht unten zusammen mit meinen aktuellen [mysqld]-Einstellungen an:

MySqlTuner-Bericht:

MySQLTuner 1.2.0 - Wichtige Hayden-Fehlerberichte, Funktionsanfragen und Downloads unterhttp://mysqltuner.com/ Ausführen mit „--help“ für zusätzliche Optionen und Ausgabefilterung

-------- Allgemeine Statistiken --------------------------------------------------
[--] Versionsprüfung für MySQLTuner-Skript übersprungen
[OK] Derzeit wird die unterstützte MySQL-Version 5.5.30-log ausgeführt
[OK] Wird auf einer 64-Bit-Architektur ausgeführt

-------- Speicher-Engine-Statistiken -------------------------------------------
[--] Status: +Archiv -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Daten in MyISAM-Tabellen: 310M (Tabellen: 264)
[--] Daten in InnoDB-Tabellen: 8M (Tabellen: 365)
[--] Daten in PERFORMANCE_SCHEMA-Tabellen: 0B (Tabellen: 17) [!!] Gesamtzahl der fragmentierten Tabellen: 376

-------- Sicherheitsempfehlungen -------------------------------------------------------
[OK] Allen Datenbankbenutzern werden Passwörter zugewiesen

-------- Leistungsmesswerte -------------------------------------------------
[--] Aktiv seit: 20 Std. 20 Min. 10 Sek. (2 Mio. q [35.305 qps], 25K Verbindungen, TX: 88B, RX: 2B)
[--] Lesen / Schreiben: 22 % / 78 %
[--] Puffer gesamt: 480,0 Mio. global + 33,5 Mio. pro Thread (max. 110 Threads)
[!!] Maximal mögliche Speichernutzung: 4,1 G (203 % des installierten RAM)
[OK] Langsame Abfragen: 0 % (0/2 M)
[OK] Höchste Nutzung verfügbarer Verbindungen: 7 % (8/110)
[OK] Schlüsselpuffergröße / MyISAM-Indizes gesamt: 150,0 M/129,5 M
[OK] Schlüsselpuffer-Trefferquote: 100,0 % (15 M im Cache / 7 K Lesevorgänge)
[OK] Abfrage-Cache-Effizienz: 74,3 (762 K zwischengespeichert / 1 Mio. Auswahlen)
[!!] Tägliche Bereinigung des Abfrage-Cache: 4341
[OK] Sortierungen, die temporäre Tabellen erfordern: 0 % (3 temporäre Sortierungen / 11 K Sortierungen)
[!!] Ohne Indizes durchgeführte Verknüpfungen: 3901
[OK] Auf der Festplatte erstellte temporäre Tabellen: 0 % (2 K auf der Festplatte / 547 K insgesamt)
[OK] Trefferquote des Thread-Cache: 99 % (8 erstellt / 25 K Verbindungen)
[OK] Trefferquote des Tabellen-Cache: 46 % (688 geöffnet / 1 K geöffnet)
[OK] Verwendetes Limit für geöffnete Dateien: 17 % (593/3 K)
[OK] Sofort erworbene Tabellensperren: 99 % (1 M sofort / 1 M Sperren)
[OK] InnoDB-Datengröße / Pufferpool: 8,9 M/256,0 M

-------- Empfehlungen -----------------------------------------------------
Allgemeine Empfehlungen:
Führen Sie OPTIMIZE TABLE aus, um Tabellen für eine bessere Leistung zu defragmentieren.
MySQL wurde innerhalb der letzten 24 Stunden gestartet – Empfehlungen können ungenau sein.
Reduzieren Sie Ihren gesamten MySQL-Speicherbedarf für die Systemstabilität.
Passen Sie Ihre Join-Abfragen so an, dass immer Indizes verwendet werden
. Anzupassende Variablen:
* Der maximale Speicherverbrauch von MySQL ist gefährlich hoch
Fügen Sie RAM hinzu, bevor Sie die MySQL-Puffervariablen erhöhen *
query_cache_size (> 32 M)
join_buffer_size (> 32,0 M, oder immer Indizes mit Joins verwenden)

Aktuelle mysqld-Einstellungen in my.cnf:

[mysqld]
local-infile=0
datadir=/var/lib/mysql
user=mysql
symbolic-links=0
port = 3306
socket = /var/lib/mysql/mysql.sock
externe Sperre überspringen
key_buffer_size = 150M
max_allowed_packet = 160M
max_connections = 110
wait_timeout = 60
query_cache-type = 1 query_cache
-size = 32M
query_cache_limit = 2M
thread_cache_size = 16
tmp_table_size = 32M
max_heap_table_size = 32M
join_buffer_size = 32M
table_open_cache = 128
table_cache = 1600
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512 KB
myisam_sort_buffer_size = 8 MB
innodb_buffer_pool_size = 256 MB
innodb_additional_mem_pool_size = 2 MB
innodb_log_buffer_size = 8 MB

Antwort1

Sie haben hier eine ziemlich seltsame Datenbank – es werden viel mehr Schreib- als Lesevorgänge ausgeführt.

Es ist wirklich wichtig, dass Sie Ihr DBMS so optimieren, dass es gut mit Innodb läuft.oderSie optimieren es so, dass es gut mit MyISAM läuft – aber Sie scheinen eine Mischung aus beiden Tabellentypen zu haben. Sie können kein DBMS haben, das mit beiden optimal funktioniert. Sie müssen mit der Migration Ihrer Daten auf eine einzige Engine beginnen. Angesichts der schreibintensiven Natur der Datenbank würde ich Innodb empfehlen.

Puffer gesamt: 480,0 M global + 33,5 M pro Thread (max. 110 Threads)

Derzeit wird das Risiko, in den Swap-Speicher zu geraten, hauptsächlich durch die Speichernutzung pro Verbindung bestimmt. Beachten Sie jedoch, dass dies nur einRisikogerade eben. Sie müssen auch feststellen, ob Sie 110 gleichzeitige Verbindungen benötigen – und diese vorzugsweise etwas reduzieren. Normalerweise ist die Sort_Buffer_Size der Hauptschuldige für den Speicherverbrauch pro Verbindung – aber Ihre beträgt ein Viertel des Standardwerts.

Wenn Sie auf InnoDB konsolidieren, müssen Sie wahrscheinlich die Größe des InnoDB-Pufferpools erhöhen.

Sie können mit verschiedenen Werten herumspielenHier.

verwandte Informationen