Einer der Schlüsselfaktoren für einen leistungsstarken MySQL-Datenbankserver ist eine gute Speicherzuweisung und -nutzung, insbesondere wenn er in einer Produktionsumgebung ausgeführt wird. Aber wie können Sie feststellen, ob die MySQL-Nutzung optimiert ist? Ist eine hohe Speicherauslastung sinnvoll oder bedarf es einer Feinabstimmung? Was ist, wenn ich auf ein Speicherleck stoße?
Lassen Sie uns diese Themen behandeln und zeigen, was Sie in MySQL überprüfen können, um Spuren einer hohen Speicherauslastung zu ermitteln.
Speicherzuordnung in MySQL
Bevor wir uns mit dem spezifischen Thema befassen, gebe ich nur eine kurze Information darüber, wie MySQL Speicher verwendet. Speicher spielt eine bedeutende Ressource für Geschwindigkeit und Effizienz bei der Verarbeitung gleichzeitiger Transaktionen und der Ausführung großer Abfragen. Jeder Thread in MySQL benötigt Speicher, der zum Verwalten von Client-Verbindungen verwendet wird, und diese Threads teilen sich denselben Basisspeicher. Variablen wie thread_stack (Stack für Threads), net_buffer_length (für Verbindungspuffer und Ergebnispuffer) oder mit max_allowed_packet, wo Verbindung und Ergebnis bei Bedarf dynamisch auf diesen Wert vergrößert werden, sind Variablen, die die Speichernutzung beeinflussen. Wenn ein Thread nicht mehr benötigt wird, wird der ihm zugewiesene Speicher freigegeben und an das System zurückgegeben, es sei denn, der Thread geht zurück in den Thread-Cache. In diesem Fall bleibt der Speicher allokiert. Abfrageverknüpfungen, Abfrage-Caches, Sortierung, Tabellen-Cache, Tabellendefinitionen erfordern Speicher in MySQL, aber diesen werden Systemvariablen zugeordnet, die Sie konfigurieren und festlegen können.
In den meisten Fällen sind die für eine Konfiguration gesetzten speicherspezifischen Variablen auf eine speicherbasierte spezifische Konfiguration wie MyISAM oder InnoDB ausgerichtet. Wenn eine mysqld-Instanz im Hostsystem erscheint, weist MySQL Puffer und Caches zu, um die Leistung von Datenbankoperationen basierend auf den festgelegten Werten einer bestimmten Konfiguration zu verbessern. Beispielsweise sind die häufigsten Variablen, die jeder DBA in InnoDB setzt, die Variablen innodb_buffer_pool_size und innodb_buffer_pool_instances, die sich beide auf die Pufferpool-Speicherzuweisung beziehen, die zwischengespeicherte Daten für InnoDB-Tabellen enthält. Es ist wünschenswert, wenn Sie über großen Speicher verfügen und erwarten, große Transaktionen zu verarbeiten, indem Sie innodb_buffer_pool_instances festlegen, um die Parallelität zu verbessern, indem Sie den Pufferpool in mehrere Pufferpoolinstanzen aufteilen.
Während Sie für MyISAM mit key_buffer_size umgehen müssen, um die Menge an Speicher zu handhaben, die der Schlüsselpuffer handhaben wird. MyISAM weist auch Puffer für alle gleichzeitigen Threads zu, die eine Tabellenstruktur, Spaltenstrukturen für jede Spalte und einen Puffer der Größe 3 * N enthalten (wobei N die maximale Zeilenlänge ist, BLOB-Spalten nicht mitgezählt). MyISAM verwaltet auch einen zusätzlichen Zeilenpuffer für den internen Gebrauch.
MySQL weist auch Speicher für temporäre Tabellen zu, es sei denn, er wird zu groß (bestimmt durch tmp_table_size und max_heap_table_size). Wenn Sie MEMORY-Tabellen verwenden und die Variable max_heap_table_size sehr hoch eingestellt ist, kann dies auch viel Speicher beanspruchen, da die Systemvariable max_heap_table_size bestimmt, wie groß eine Tabelle werden kann, und es keine Konvertierung in das Format auf der Festplatte gibt.
MySQL hat auch ein Leistungsschema, das eine Funktion zur Überwachung von MySQL-Aktivitäten auf niedriger Ebene ist. Sobald dies aktiviert ist, weist es Arbeitsspeicher inkrementell dynamisch zu und skaliert die Arbeitsspeichernutzung entsprechend der tatsächlichen Serverlast, anstatt den erforderlichen Arbeitsspeicher während des Serverstarts zuzuweisen. Nachdem Speicher zugewiesen wurde, wird er erst freigegeben, wenn der Server neu gestartet wird.
MySQL kann auch so konfiguriert werden, dass es große Speicherbereiche für seinen Pufferpool zuweist, wenn Linux verwendet wird und der Kernel für die Unterstützung großer Seiten aktiviert ist, d. h. wenn HugePages verwendet wird.
Was zu überprüfen ist, wenn der MySQL-Speicher hoch ist
Laufende Abfragen prüfen
Es ist sehr üblich, dass MySQL-DBAs zuerst wissen, was mit dem laufenden MySQL-Server los ist. Die grundlegendsten Verfahren sind Prozessliste prüfen, Serverstatus prüfen und Speicher-Engine-Status prüfen. Um diese Dinge zu tun, müssen Sie im Grunde nur die Reihe von Abfragen ausführen, indem Sie sich bei MySQL anmelden. Siehe unten:
Um die laufenden Abfragen anzuzeigen,
mysql> SHOW [FULL] PROCESSLIST;Das Anzeigen der aktuellen Prozessliste zeigt Abfragen, die aktiv ausgeführt werden, oder sogar inaktive oder schlafende Prozesse. Es ist sehr wichtig und eine wichtige Routine, eine Aufzeichnung der laufenden Abfragen zu haben. Wie bereits erwähnt, wie MySQL Speicher zuweist, nutzen laufende Abfragen die Speicherzuweisung und können drastische Leistungsprobleme verursachen, wenn sie nicht überwacht werden.
Sehen Sie sich die Statusvariablen des MySQL-Servers an,
mysql> SHOW SERVER STATUS\Goder bestimmte Variablen filtern wie
mysql> SHOW SERVER STATUS WHERE variable_name IN ('<var1>', 'var2'...);Die Statusvariablen von MySQL dienen als Ihre statistischen Informationen, um Metrikdaten zu erfassen, um festzustellen, wie Ihr MySQL arbeitet, indem Sie die von den Statuswerten angegebenen Zähler beobachten. Hier gibt es bestimmte Werte, die Ihnen einen Überblick geben, der sich auf die Speichernutzung auswirkt. Überprüfen Sie beispielsweise die Anzahl der Threads, die Anzahl der Tabellen-Caches oder die Nutzung des Pufferpools,
...
| Created_tmp_disk_tables | 24240 |
| Created_tmp_tables | 334999 |
…
| Innodb_buffer_pool_pages_data | 754 |
| Innodb_buffer_pool_bytes_data | 12353536 |
...
| Innodb_buffer_pool_pages_dirty | 6 |
| Innodb_buffer_pool_bytes_dirty | 98304 |
| Innodb_buffer_pool_pages_flushed | 30383 |
| Innodb_buffer_pool_pages_free | 130289 |
…
| Open_table_definitions | 540 |
| Open_tables | 1024 |
| Opened_table_definitions | 540 |
| Opened_tables | 700887 |
...
| Threads_connected | 5 |
...
| Threads_cached | 2 |
| Threads_connected | 5 |
| Threads_created | 7 |
| Threads_running | 1 |Überwachungsstatus der Engine anzeigen, z. B. InnoDB-Status
mysql> SHOW ENGINE INNODB STATUS\GDer InnoDB-Status zeigt auch den aktuellen Status von Transaktionen, die die Speicher-Engine verarbeitet. Es gibt Ihnen die Heap-Größe einer Transaktion, adaptive Hash-Indizes, die ihre Puffernutzung offenlegen, oder zeigt Ihnen die Innodb-Pufferpoolinformationen, genau wie im folgenden Beispiel:
---TRANSACTION 10798819, ACTIVE 0 sec inserting, thread declared inside InnoDB 1201
mysql tables in use 1, locked 1
1 lock struct(s), heap size 1136, 0 row lock(s), undo log entries 8801
MySQL thread id 68481, OS thread handle 139953970235136, query id 681821 localhost root copy to tmp table
ALTER TABLE NewAddressCode2_2 ENGINE=INNODB
…
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 528, free list len 43894, seg size 44423, 1773 merges
merged operations:
insert 63140, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 553193, node heap has 1 buffer(s)
Hash table size 553193, node heap has 637 buffer(s)
Hash table size 553193, node heap has 772 buffer(s)
Hash table size 553193, node heap has 1239 buffer(s)
Hash table size 553193, node heap has 2 buffer(s)
Hash table size 553193, node heap has 0 buffer(s)
Hash table size 553193, node heap has 1 buffer(s)
Hash table size 553193, node heap has 1 buffer(s)
115320.41 hash searches/s, 10292.51 non-hash searches/s
...
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 2235564032
Dictionary memory allocated 3227698
Internal hash tables (constant factor + variable factor)
Adaptive hash index 78904768 (35404352 + 43500416)
Page hash 277384 (buffer pool 0 only)
Dictionary cache 12078786 (8851088 + 3227698)
File system 1091824 (812272 + 279552)
Lock system 5322504 (5313416 + 9088)
Recovery system 0 (0 + 0)
Buffer pool size 131056
Buffer pool size, bytes 2147221504
Free buffers 8303
Database pages 120100
Old database pages 44172
Modified db pages 108784
Pending reads 0
Pending writes: LRU 2, flush list 342, single page 0
Pages made young 533709, not young 181962
3823.06 youngs/s, 1706.01 non-youngs/s
Pages read 4104, created 236572, written 441223
38.09 reads/s, 339.46 creates/s, 1805.87 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 12 / 1000 not 5 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 120100, unzip_LRU len: 0
I/O sum[754560]:cur[8096], unzip sum[0]:cur[0]
…Eine weitere Sache, die Sie hinzufügen sollten, Sie können auch das Performance-Schema und das sys-Schema verwenden, um den Speicherverbrauch und die Nutzung durch Ihren MySQL-Server zu überwachen. Standardmäßig sind die meisten Instrumentierungen standardmäßig deaktiviert, sodass Sie manuelle Dinge tun müssen, um dies zu verwenden.
Auf Austauschbarkeit prüfen
In jedem Fall ist es wahrscheinlich, dass MySQL seinen Speicher auf die Festplatte auslagert. Dies ist häufig eine sehr häufige Situation, insbesondere wenn der MySQL-Server und die zugrunde liegende Hardware nicht optimal auf die erwarteten Anforderungen abgestimmt sind. Es gibt bestimmte Fälle, in denen die Nachfrage nach Datenverkehr nicht vorhergesehen wurde. Der Speicher könnte zunehmend wachsen, insbesondere wenn fehlerhafte Abfragen ausgeführt werden, die dazu führen, dass viel Speicherplatz verbraucht oder verwendet wird, was zu einer Verschlechterung der Leistung führt, da Daten auf der Festplatte statt im Puffer ausgewählt werden. Führen Sie einfach den freemem-Befehl oder vmstat aus, wie unten,
, um auf Auslagerung zu prüfen[[email protected] ~]# free -m
total used free shared buff/cache available
Mem: 3790 2754 121 202 915 584
Swap: 1535 39 1496
[[email protected] ~]# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 40232 124100 0 937072 2 3 194 1029 477 313 7 2 91 1 0
0 0 40232 123912 0 937228 0 0 0 49 1247 704 13 3 84 0 0
1 0 40232 124184 0 937212 0 0 0 35 751 478 6 1 93 0 0
0 0 40232 123688 0 937228 0 0 0 15 736 487 5 1 94 0 0
0 0 40232 123912 0 937220 0 0 3 74 1065 729 8 2 89 0 0Sie können auch mit procfs nachsehen und Informationen sammeln, indem Sie beispielsweise zu /proc/vmstat oder /proc/meminfo gehen.
Perf, gdb und Valgrind mit Massif verwenden
Die Verwendung von Tools wie perf, gdb und valgrind hilft Ihnen, sich mit einer fortgeschritteneren Methode zur Bestimmung der MySQL-Speicherauslastung vertraut zu machen. Es gibt Zeiten, in denen ein interessantes Ergebnis zu einem Mysterium der Lösung des Speicherverbrauchs wird, was zu Ihrer Verwirrung in MySQL führt. Dies führt zu mehr Skepsis, und die Verwendung dieser Tools hilft Ihnen zu untersuchen, wie MySQL den Umgang mit Speicher von der Zuweisung bis zur Verwendung für die Verarbeitung von Transaktionen oder Prozessen verwendet. Dies ist zum Beispiel nützlich, wenn Sie beobachten, dass sich MySQL abnormal verhält, was zu einer fehlerhaften Konfiguration führen oder zu Speicherlecks führen könnte.
Zum Beispiel zeigt die Verwendung von perf in MySQL mehr Informationen in einem Bericht auf Systemebene:
[[email protected] ~]# perf report --input perf.data --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 54K of event 'cpu-clock'
# Event count (approx.): 13702000000
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ...................................................................................................................................................................................................
#
60.66% mysqld [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
2.79% mysqld libc-2.17.so [.] __memcpy_ssse3
2.54% mysqld mysqld [.] ha_key_cmp
1.89% mysqld [vdso] [.] __vdso_clock_gettime
1.05% mysqld mysqld [.] rec_get_offsets_func
1.03% mysqld mysqld [.] row_sel_field_store_in_mysql_format_func
0.92% mysqld mysqld [.] _mi_rec_pack
0.91% mysqld [kernel.kallsyms] [k] finish_task_switch
0.90% mysqld mysqld [.] row_search_mvcc
0.86% mysqld mysqld [.] decimal2bin
0.83% mysqld mysqld [.] _mi_rec_check
….Da dies ein spezielles Thema zum Vertiefen sein kann, empfehlen wir Ihnen, sich diese wirklich guten externen Blogs als Referenz anzusehen, perf Basics for MySQL Profiling, Finding MySQL Scaling Problems Using perf oder zu lernen, wie es geht debugge mit valgrind mit massif.
Effizienter Weg zur Überprüfung der MySQL-Speicherauslastung
Die Verwendung von ClusterControl erleichtert alle lästigen Routinen wie das Durchgehen Ihrer Runbooks oder sogar das Erstellen Ihrer eigenen Playbooks, die Berichte für Sie liefern. In ClusterControl haben Sie Dashboards (unter Verwendung von SCUMM), wo Sie einen schnellen Überblick über Ihre(n) MySQL-Knoten haben können. Beispiel:Anzeigen des allgemeinen MySQL-Dashboards
Sie können die Leistung des MySQL-Knotens bestimmen
Sie sehen, dass die obigen Bilder Variablen zeigen, die sich auf die Nutzung des MySQL-Speichers auswirken. Sie können überprüfen, wie die Metriken für Sortier-Caches, temporäre Tabellen, verbundene Threads, Abfrage-Cache oder Speicher-Engines im Innodb-Pufferpool oder im Schlüsselpuffer von MyISAM sind.
Die Verwendung von ClusterControl bietet Ihnen ein Dienstprogramm aus einer Hand, mit dem Sie auch ausgeführte Abfragen überprüfen können, um die Prozesse (Abfragen) zu ermitteln, die sich auf eine hohe Speicherauslastung auswirken können. Unten finden Sie ein Beispiel,
Das Anzeigen der Statusvariablen von MySQL ist ziemlich einfach,
Sie können sogar zu Leistung -> Innodb-Status gehen, um den anzuzeigen aktuellen InnoDB-Status Ihrer Datenbankknoten. Wenn in ClusterControl ein Vorfall erkannt wird, versucht es, den Vorfall zu sammeln, und zeigt den Verlauf als Bericht an, der Ihnen den InnoDB-Status anzeigt, wie in unserem vorherigen Blog über MySQL Freeze Frame gezeigt.
Zusammenfassung
Die Fehlerbehebung und Diagnose Ihrer MySQL-Datenbank bei Verdacht auf hohe Speicherauslastung ist nicht so schwierig, solange Sie die zu verwendenden Verfahren und Tools kennen. Die Verwendung des richtigen Tools bietet Ihnen mehr Flexibilität und schnellere Produktivität, um Korrekturen oder Lösungen mit der Chance auf bessere Ergebnisse bereitzustellen.
