Seit MySQL ursprünglich geforkt wurde, um MariaDB zu bilden, wurde es umfassend unterstützt und schnell von einem großen Publikum in der Open-Source-Datenbank-Community angenommen. Ursprünglich ein Drop-in-Ersatz, hat MariaDB begonnen, sich von MySQL abzuheben, insbesondere mit der Veröffentlichung von MariaDB 10.2.
Trotzdem gibt es immer noch keinen wirklich verräterischen Unterschied zwischen MariaDB und MySQL, da beide Engines haben, die kompatibel sind und nativ miteinander laufen können. Seien Sie also nicht überrascht, wenn das Tuning Ihres MariaDB-Setups einen ähnlichen Ansatz hat wie das Tuning von MySQL.
In diesem Blog wird die Optimierung von MariaDB erörtert, insbesondere von Systemen, die in einer Linux-Umgebung ausgeführt werden.
MariaDB Hardware- und Systemoptimierung
MariaDB empfiehlt, dass Sie Ihre Hardware in der folgenden Prioritätsreihenfolge verbessern...
Speicher
Arbeitsspeicher ist der wichtigste Faktor für Datenbanken, da Sie damit die Server-Systemvariablen anpassen können. Mehr Arbeitsspeicher bedeutet größere Schlüssel- und Tabellen-Caches, die im Arbeitsspeicher gespeichert werden, damit Festplatten darauf zugreifen können, eine Größenordnung langsamer, und anschließend reduziert wird.
Denken Sie jedoch daran, dass das einfache Hinzufügen von mehr Speicher möglicherweise nicht zu drastischen Verbesserungen führt, wenn die Servervariablen nicht so eingestellt sind, dass sie den zusätzlich verfügbaren Speicher nutzen.
Die Verwendung von mehr RAM-Steckplätzen auf dem Motherboard erhöht die Busfrequenz und es gibt mehr Latenz zwischen dem RAM und der CPU. Das bedeutet, dass die Verwendung der höchsten RAM-Größe pro Steckplatz vorzuziehen ist.
Festplatten
Schneller Festplattenzugriff ist entscheidend, da sich die Daten letztendlich dort befinden. Die Schlüsselzahl ist die Festplattensuchzeit (ein Maß dafür, wie schnell sich die physische Festplatte bewegen kann, um auf die Daten zuzugreifen). Wählen Sie daher Festplatten mit einer möglichst geringen Suchzeit. Sie können auch dedizierte Festplatten für temporäre Dateien und Transaktionsprotokolle hinzufügen.
Schnelles Ethernet
Mit den entsprechenden Anforderungen an Ihre Internetbandbreite bedeutet schnelles Ethernet, dass es schneller auf Clientanfragen reagieren kann, Replikationsantwortzeiten zum Lesen von Binärprotokollen über die Slaves, schnellere Antwortzeiten sind auch sehr wichtig, besonders bei Galera -basierte Cluster.
Prozessor
Obwohl Hardware-Engpässe oft woanders liegen, ermöglichen schnellere Prozessoren eine schnellere Durchführung von Berechnungen und eine schnellere Rücksendung der Ergebnisse an den Client. Neben der Prozessorgeschwindigkeit sind auch die Busgeschwindigkeit und die Cache-Größe des Prozessors wichtige Faktoren, die es zu berücksichtigen gilt.
Ihren Festplatten-E/A-Scheduler einstellen
E/A-Scheduler existieren als Möglichkeit, Plattenzugriffsanforderungen zu optimieren. Es führt E/A-Anforderungen an ähnlichen Orten auf der Festplatte zusammen. Dies bedeutet, dass das Festplattenlaufwerk nicht so oft suchen muss und eine enorme Gesamtreaktionszeit verbessert und Festplattenoperationen spart. Die empfohlenen Werte für die E/A-Leistung sind noop und Deadline.
noop ist nützlich, um zu prüfen, ob komplexe E/A-Planungsentscheidungen anderer Planer keine Regressionen der E/A-Leistung verursachen. In einigen Fällen kann es für Geräte hilfreich sein, die die E/A-Planung selbst durchführen, als intelligenter Speicher, oder für Geräte, die nicht auf mechanische Bewegung angewiesen sind, wie z. B. SSDs. Normalerweise ist der DEADLINE I/O-Scheduler für diese Geräte die bessere Wahl, aber aufgrund des geringeren Overheads kann NOOP bei bestimmten Workloads eine bessere Leistung erzielen.
Für Deadline ist es ein latenzorientierter I/O-Scheduler. Jedem I/O-Request ist eine Deadline zugeordnet. Normalerweise werden Anforderungen in Warteschlangen (Lesen und Schreiben) gespeichert, die nach Sektornummern sortiert sind. Der DEADLINE-Algorithmus verwaltet zwei zusätzliche Warteschlangen (Lesen und Schreiben), in denen die Anforderungen nach Frist sortiert werden. Solange keine Anforderung abgelaufen ist, wird die „Sektor“-Warteschlange verwendet. Wenn Zeitüberschreitungen auftreten, werden Anforderungen aus der „Deadline“-Warteschlange bearbeitet, bis keine abgelaufenen Anforderungen mehr vorhanden sind. Im Allgemeinen bevorzugt der Algorithmus Lesevorgänge gegenüber Schreibvorgängen.
Für PCIe-Geräte (NVMe-SSD-Laufwerke) haben sie ihre eigenen großen internen Warteschlangen zusammen mit schnellem Service und benötigen oder profitieren nicht davon, einen I/O-Scheduler einzurichten. Es wird empfohlen, keinen expliziten Konfigurationsparameter für den Scheduler-Modus zu haben.
Sie können Ihre Planer-Einstellung überprüfen mit:
cat /sys/block/${DEVICE}/queue/schedulerZum Beispiel sollte es so aussehen:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqUm es dauerhaft zu machen, bearbeiten Sie die Konfigurationsdatei /etc/default/grub, suchen Sie nach der Variablen GRUB_CMDLINE_LINUX und fügen Sie Aufzug wie unten hinzu:
GRUB_CMDLINE_LINUX="elevator=noop"Limit für offene Dateien erhöhen
Um eine gute Serverleistung zu gewährleisten, darf die Gesamtzahl der Clientverbindungen, Datenbankdateien und Protokolldateien die maximale Dateideskriptorgrenze des Betriebssystems (ulimit -n) nicht überschreiten. Linux-Systeme begrenzen die Anzahl der Dateideskriptoren, die ein Prozess öffnen kann, auf 1.024 pro Prozess. Auf aktiven Datenbankservern (insbesondere Produktionsservern) kann das Standardsystemlimit leicht erreicht werden.
Um dies zu erhöhen, bearbeiten Sie /etc/security/limits.conf und spezifizieren oder fügen Sie Folgendes hinzu:
mysql soft nofile 65535
mysql hard nofile 65535Dies erfordert einen Systemneustart. Anschließend können Sie dies bestätigen, indem Sie Folgendes ausführen:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Optional können Sie dies über mysqld_safe einstellen, wenn Sie den mysqld-Prozess über mysqld_safe starten,
[mysqld_safe]
open_files_limit=4294967295oder wenn Sie systemd verwenden,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadAuslagerung unter Linux für MariaDB einstellen
Linux Swap spielt eine große Rolle in Datenbanksystemen. Es verhält sich wie Ihr Reserverad in Ihrem Fahrzeug, wenn böse Speicherlecks Ihre Arbeit stören, wird die Maschine langsamer ... aber in den meisten Fällen ist sie immer noch brauchbar, um die zugewiesene Aufgabe zu erledigen.
Um Änderungen an Ihrer Swapiness anzuwenden, führen Sie einfach aus,
sysctl -w vm.swappiness=1Dies geschieht dynamisch, ohne dass der Server neu gestartet werden muss. Um es dauerhaft zu machen, bearbeiten Sie /etc/sysctl.conf und fügen Sie die Zeile
hinzuvm.swappiness=1Es ist ziemlich üblich, swappiness=0 zu setzen, aber seit der Veröffentlichung neuer Kernel (z. B. Kernel> 2.6.32-303) wurden Änderungen vorgenommen, sodass Sie vm.swappiness=1 setzen müssen.
Dateisystemoptimierungen für MariaDB
Die gängigsten Dateisysteme, die in Linux-Umgebungen mit MariaDB verwendet werden, sind ext4 und XFS. Es sind auch bestimmte Setups verfügbar, um eine Architektur mit ZFS und BRTFS zu implementieren (wie in der MariaDB-Dokumentation referenziert).
Darüber hinaus müssen die meisten Datenbank-Setups die Dateizugriffszeit nicht aufzeichnen. Möglicherweise möchten Sie dies deaktivieren, wenn Sie das Volume in das System einbinden. Bearbeiten Sie dazu Ihre Datei /etc/fstab. Auf einem Volume namens /dev/md2 sieht es beispielsweise so aus:
/dev/md2 / ext4 defaults,noatime 0 0Erstellen einer optimalen MariaDB-Instanz
Speichern Sie Daten auf einem separaten Volume
Es ist immer ideal, Ihre Datenbankdaten auf einem separaten Volume zu trennen. Dieses Volume ist speziell für diese Arten von schnellen Speichervolumes wie SSD-, NVMe- oder PCIe-Karten gedacht. Wenn beispielsweise Ihr gesamtes Systemvolume ausfällt, haben Sie Ihr Datenbankvolume sicher und können sicher sein, dass es nicht beeinträchtigt wird, falls Ihre Speicherhardware ausfällt.
MariaDB optimieren, um Speicher effizient zu nutzen
innodb_buffer_pool_size
Der einzustellende Primärwert auf einem Datenbankserver mit ausschließlich/hauptsächlich XtraDB/InnoDB-Tabellen kann in diesen Umgebungen auf bis zu 80 % des Gesamtspeichers eingestellt werden. Wenn Sie auf 2 GB oder mehr eingestellt sind, sollten Sie wahrscheinlich auch innodb_buffer_pool_instances anpassen. Sie können dies dynamisch festlegen, wenn Sie MariaDB>=10.2.2 Version verwenden. Andernfalls ist ein Neustart des Servers erforderlich.
tmp_memory_table_size/max_heap_table_size
Für tmp_memory_table_size (tmp_table_size), wenn Sie es mit großen temporären Tabellen zu tun haben, bietet eine höhere Einstellung eine Leistungssteigerung, da es im Speicher gespeichert wird. Dies ist üblich bei Abfragen, die häufig GROUP BY, UNION oder Unterabfragen verwenden. Wenn max_heap_table_size jedoch kleiner ist, gilt die untere Grenze. Wenn eine Tabelle das Limit überschreitet, konvertiert MariaDB sie in eine MyISAM- oder Aria-Tabelle. Sie können sehen, ob eine Erhöhung erforderlich ist, indem Sie die Statusvariablen Created_tmp_disk_tables und Created_tmp_tables vergleichen, um zu sehen, wie viele temporäre Tabellen von den insgesamt erstellten auf die Festplatte konvertiert werden mussten. Häufig sind komplexe GROUP BY-Abfragen für die Überschreitung des Limits verantwortlich.
Bei max_heap_table_size ist dies die maximale Größe für von Nutzern erstellte MEMORY-Tabellen. Der für diese Variable festgelegte Wert gilt nur für die neu erstellten oder neu erstellten Tabellen und nicht für die vorhandenen. Der kleinere von max_heap_table_size und tmp_table_size begrenzt auch interne In-Memory-Tabellen. Wenn die maximale Größe erreicht ist, wird bei allen weiteren Versuchen, Daten einzufügen, der Fehler „Tabelle ... ist voll“ angezeigt. Temporäre Tabellen, die mit CREATE TEMPORARY erstellt wurden, werden nicht in Aria konvertiert, wie es bei internen temporären Tabellen der Fall ist, sondern es wird auch ein Fehler „Tabelle voll“ ausgegeben.
innodb_log_file_size
Große Speicher mit Hochgeschwindigkeitsverarbeitung und schneller I/O-Festplatte sind nicht neu und haben ihren angemessenen Preis, wie es empfohlen wird. Wenn Sie mehr Leistungsgewinne bevorzugen, insbesondere während und bei der Verarbeitung Ihrer InnoDB-Transaktionen, ist es sinnvoll, die Variable innodb_log_file_size auf einen größeren Wert wie 5 GB oder sogar 10 GB einzustellen. Erhöhen bedeutet, dass die größeren Transaktionen ausgeführt werden können, ohne dass vor dem Festschreiben Festplatten-E/A ausgeführt werden müssen.
join_buffer_size
In manchen Fällen fehlt Ihren Abfragen die richtige Indizierung oder es gibt einfach Fälle, in denen Sie diese Abfrage ausführen müssen. Außer wenn es aus der Client-Perspektive stark aufgerufen oder aufgerufen wird, ist das Setzen dieser Variable am besten auf Sitzungsebene. Erhöhen Sie ihn, um schnellere vollständige Joins zu erhalten, wenn das Hinzufügen von Indizes nicht möglich ist, obwohl Sie Speicherprobleme berücksichtigen, da Joins immer die Mindestgröße zuweisen.
Stellen Sie Ihr max_allowed_packet ein
MariaDB hat dieselbe Natur wie MySQL, wenn es um die Behandlung von Paketen geht. Es teilt Daten in Pakete auf und der Client muss den Wert der max_allowed_packet-Variablen kennen. Der Server verfügt über einen Puffer zum Speichern des Hauptteils mit einer maximalen Größe, die diesem max_allowed_packet-Wert entspricht. Wenn der Client mehr Daten als die max_allowed_packet-Größe sendet, wird der Socket geschlossen. Die Direktive max_allowed_packet definiert die maximale Paketgröße, die gesendet werden kann.
Ein zu niedriger Wert kann dazu führen, dass eine Abfrage stoppt und ihre Client-Verbindung schließt, was ziemlich häufig zu Fehlern wie ER_NET_PACKET_TOO_LARGE oder Verbindung zum MySQL-Server während der Abfrage verloren führt. Im Idealfall, insbesondere bei den meisten heutigen Anwendungsanforderungen, können Sie diese Einstellung auf 512 MiB festlegen. Wenn es sich um eine Anwendung mit geringem Bedarf handelt, verwenden Sie einfach den Standardwert und setzen Sie diese Variable nur bei Bedarf per Sitzung, wenn die zu sendenden oder zu empfangenden Daten zu groß sind als der Standardwert (16 MiB seit MariaDB 10.2.4). Bei bestimmten Workloads, die die Verarbeitung großer Pakete erfordern, müssen Sie ihn entsprechend Ihren Anforderungen höher einstellen, insbesondere bei der Replikation. Wenn max_allowed_packet auf dem Slave zu klein ist, führt dies auch dazu, dass der Slave den I/O-Thread stoppt.
Threadpool verwenden
In einigen Fällen ist diese Einstellung möglicherweise nicht erforderlich oder wird für Sie nicht empfohlen. Threadpools sind am effizientesten in Situationen, in denen Abfragen relativ kurz sind und die Last CPU-gebunden ist (OLTP-Workloads). Wenn die Arbeitslast nicht CPU-gebunden ist, möchten Sie möglicherweise trotzdem die Anzahl der Threads begrenzen, um Speicher für die Datenbankspeicherpuffer zu sparen.
Die Verwendung von Threadpool ist eine ideale Lösung, insbesondere wenn Ihr System Kontextwechsel erfährt und Sie Wege finden, dies zu reduzieren und eine geringere Anzahl von Threads als die Anzahl von Clients zu verwalten. Allerdings sollte diese Zahl auch nicht zu gering sein, da wir auch die verfügbaren CPUs maximal ausnutzen wollen. Daher sollte idealerweise ein einziger aktiver Thread für jede CPU auf der Maschine vorhanden sein.
Sie können thread_pool_max_threads, thread_pool_min_threads für die maximale und die minimale Anzahl von Threads festlegen. Im Gegensatz zu MySQL ist dies nur in MariaDB vorhanden.
Setzen Sie die Variable thread_handling, die festlegt, wie der Server Threads für Client-Verbindungen handhabt. Neben Threads für Client-Verbindungen gilt dies auch für bestimmte interne Server-Threads, wie z. B. Galera-Slave-Threads.
Tue deinen Tabellen-Cache + max_connections
Wenn Sie gelegentlich in der Prozessliste auf den Status von Opening-Tabellen und Closing-Tabellen stoßen, kann dies bedeuten, dass Sie Ihren Tabellen-Cache erhöhen müssen. Sie können dies auch über die Eingabeaufforderung des MySQL-Clients überwachen, indem Sie SHOW GLOBAL STATUS LIKE 'Open%table%' ausführen; und die Statusvariablen überwachen.
Für max_connections, wenn Ihre Anwendung viele gleichzeitige Verbindungen erfordert, können Sie dies auf 500 setzen.
Für table_open_cache soll es die Gesamtzahl Ihrer Tabellen sein, aber es ist am besten, Sie fügen mehr hinzu, abhängig von der Art der Abfragen, die Sie bedienen, da temporäre Tabellen ebenfalls zwischengespeichert werden sollen. Wenn Sie beispielsweise 500 Tabellen haben, ist es sinnvoll, mit 1500 zu beginnen.
Setzen Sie Ihre table_open_cache_instances auf 8. Dies kann die Skalierbarkeit verbessern, indem Konflikte zwischen Sitzungen reduziert werden. Der Cache für offene Tabellen kann in mehrere kleinere Cache-Instanzen der Größe table_open_cache / table_open_cache_instances partitioniert werden.
Für InnoDB fungiert table_definition_cache als weiche Grenze für die Anzahl offener Tabelleninstanzen im InnoDB-Datenwörterbuch-Cache. Der zu definierende Wert legt die Anzahl der Tabellendefinitionen fest, die im Definitionscache gespeichert werden können. Wenn Sie eine große Anzahl von Tabellen verwenden, können Sie einen großen Tabellendefinitionscache erstellen, um das Öffnen von Tabellen zu beschleunigen. Der Tabellendefinitions-Cache benötigt weniger Speicherplatz und verwendet im Gegensatz zum normalen Tabellen-Cache keine Dateideskriptoren. Der Mindestwert ist 400. Der Standardwert basiert auf der folgenden Formel, begrenzt auf 2000:
MIN(400 + table_open_cache / 2, 2000)Wenn die Anzahl der geöffneten Tabelleninstanzen die Einstellung table_definition_cache überschreitet, beginnt der LRU-Mechanismus damit, Tabelleninstanzen zum Entfernen zu markieren und sie schließlich aus dem Data Dictionary-Cache zu entfernen. Das Limit hilft bei der Bewältigung von Situationen, in denen erhebliche Mengen an Arbeitsspeicher verwendet würden, um selten verwendete Tabelleninstanzen bis zum nächsten Serverneustart zwischenzuspeichern. Die Anzahl der Tabelleninstanzen mit zwischengespeicherten Metadaten könnte höher sein als die durch table_definition_cache definierte Grenze, da über- und untergeordnete Tabelleninstanzen mit Fremdschlüsselbeziehungen nicht in die LRU-Liste aufgenommen und nicht aus dem Speicher entfernt werden.
Im Gegensatz zum table_open_cache verwendet der table_definition_cache keine Dateideskriptoren und ist viel kleiner.
Umgang mit dem Abfrage-Cache
Am besten empfehlen wir, den Abfrage-Cache in Ihrem gesamten MariaDB-Setup zu deaktivieren. Sie müssen sicherstellen, dass query_cache_type=OFF und query_cache_size=0 ist, um den Abfrage-Cache vollständig zu deaktivieren. Im Gegensatz zu MySQL unterstützt MariaDB den Abfrage-Cache immer noch vollständig und hat keine Pläne, seine Unterstützung für die Verwendung des Abfrage-Cache zurückzuziehen. Es gibt einige Leute, die behaupten, dass der Abfrage-Cache ihnen immer noch Leistungsvorteile bringt. Dieser Beitrag von Percona Der MySQL-Abfrage-Cache:Schlimmster Feind oder bester Freund enthüllt jedoch, dass der Abfrage-Cache, wenn er aktiviert ist, zu einem Overhead führt und eine schlechte Serverleistung aufweist.
Wenn Sie beabsichtigen, den Abfrage-Cache zu verwenden, stellen Sie sicher, dass Sie Ihren Abfrage-Cache überwachen, indem Sie SHOW GLOBAL STATUS LIKE 'Qcache%'; ausführen. Qcache_inserts enthält die Anzahl der zum Abfrage-Cache hinzugefügten Abfragen, Qcache_hits enthält die Anzahl der Abfragen, die den Abfrage-Cache verwendet haben, während Qcache_lowmem_prunes die Anzahl der Abfragen enthält, die aufgrund von Speichermangel aus dem Cache gelöscht wurden. Zu gegebener Zeit kann die Verwendung und Aktivierung des Abfrage-Cache fragmentiert werden. Ein hoher Wert von Qcache_free_blocks relativ zu Qcache_total_blocks kann auf eine Fragmentierung hinweisen. Um es zu defragmentieren, führen Sie FLUSH QUERY CACHE aus. Dadurch wird der Abfrage-Cache defragmentiert, ohne Abfragen zu löschen.
Überwachen Sie immer Ihre Server
Es ist sehr wichtig, dass Sie Ihre MariaDB-Knoten richtig überwachen. Gängige Überwachungstools (wie Nagios, Zabbix oder PMM) sind verfügbar, wenn Sie dazu neigen, kostenlose und Open-Source-Tools zu bevorzugen. Für Unternehmens- und vollgepackte Tools empfehlen wir Ihnen, ClusterControl auszuprobieren, da es nicht nur Überwachung bietet, sondern auch Leistungsratgeber, Warnungen und Alarme bietet, die Ihnen helfen, Ihre Systemleistung zu verbessern und auf dem Laufenden zu bleiben Trends, während Sie mit dem Support-Team in Kontakt treten. Die Datenbanküberwachung mit ClusterControl ist kostenlos und Teil der Community Edition.
Fazit
Das Optimieren Ihres MariaDB-Setups ist fast der gleiche Ansatz wie bei MySQL, jedoch mit einigen Unterschieden, da es sich in einigen seiner unterstützten Ansätze und Versionen unterscheidet. MariaDB ist jetzt eine andere Entität in der Datenbankwelt und hat schnell das Vertrauen der Community ohne FUD gewonnen. Sie haben ihre eigenen Gründe, warum es auf diese Weise implementiert werden muss, daher ist es sehr wichtig, dass wir wissen, wie man dies abstimmt und Ihre MariaDB-Server optimiert.
