Mariadb MySQL Tuner Bericht verwirrend

7

Ich möchte Sie bitten, den Bericht von mysqltuner bezüglich der MariaDB-Datenbank zu präzisieren. Der mysqltuner wurde mit --nogood flag aufgerufen!

 >>  MySQLTuner 1.7.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[!!] Currently running unsupported MySQL version 10.0.29-MariaDB-0ubuntu0.16.04.1

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: (0B)
[!!] Log file  doesn't exist
[!!] Log file  isn't readable.

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA 
[--] Data in InnoDB tables: 380M (Tables: 417)

-------- Security Recommendations ------------------------------------------------------------------
[--] There are 605 basic passwords in the list.

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 15s (812 q [54.133 qps], 275 conn, TX: 258K, RX: 108K)
[--] Reads / Writes: 100% / 0%
[--] Binary logging is disabled
[--] Physical Memory     : 31.3G
[--] Max MySQL memory    : 10.0G
[--] Other process memory: 1.2G
[--] Total buffers: 8.4G global + 10.7M per thread (150 max threads)
[--] P_S Max memory usage: 34M
[--] Galera GCache Max memory usage: 0B
[!!] Slow queries: 27% (221/812)
[!!] Query cache may be disabled by default due to mutex contention.
[!!] Query cache efficiency: 0.0% (0 cached / 521 selects)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 35.0M
[--] Sys schema isn't installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 8 thread(s).
[--] Using default value is good enough for your version (10.0.29-MariaDB-0ubuntu0.16.04.1)

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.2% (24M used / 134M cache)
[!!] Read Key buffer hit rate: 80.0% (10 cached / 2 reads)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (12.5 %): 512.0M * 2/8.0G should be equal 25%
[--] InnoDB Buffer Pool Chunk Size not used or defined in your version
[!!] InnoDB Write Log efficiency: 0% (2 hits/ 0 total)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- RocksDB Metrics ---------------------------------------------------------------------------
[--] RocksDB is disabled.

-------- Spider Metrics ----------------------------------------------------------------------------
[--] Spider is disabled.

-------- Connect Metrics ---------------------------------------------------------------------------
[--] Connect is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    MySQL started within last 24 hours - recommendations may be inaccurate
    Consider installing Sys schema from https://github.com/mysql/mysql-sys
Variables to adjust:
    query_cache_type (=0)
    query_cache_limit (> 256K, or use smaller result sets)
    innodb_log_file_size * innodb_log_files_in_group should be equals to 1/4 of buffer pool size (=4G) if possible.

Was mich verwirrt, ist der Abschnitt "Empfehlungen für Protokolldateien". Ich weiß nicht wirklich, was ich damit anfangen soll. Dann auch diese Zeile:

[!!] Query cache may be disabled by default due to mutex contention.

Ich bin auch sehr neugierig, warum es mir empfehlen würde, query_cache_type auf 0 zu ändern und query_cache_limit zu erhöhen?

Ich bin mir bewusst, dass es seit mindestens 24 Stunden nicht mehr läuft, weil ich die Konfiguration bereits angepasst und meine Datenbank neu gestartet habe. Ich habe Anpassungen vorgenommen, die meinem Wissen über MariaDB entsprechen, aber mit diesen wenigen Dingen bin ich verwirrt.

— user119791
quelle

Sie sollten den Bericht von MySQL Tuner mit längerer Laufzeit aktualisieren. 15 Sekunden sind nicht genug!

— Philippe Delteil

7

Ich kann diese Zeile erklären

[!!] Query cache may be disabled by default due to mutex contention.

Die InnoDB-Speicher-Engine und der Abfrage-Cache befinden sich in einem ständigen Kriegszustand (siehe meinen 1,5 Jahre alten Beitrag Warum ist query_cache_type ab MySQL 5.6 standardmäßig deaktiviert? )

mysqltuner empfiehlt, query_cache_type auf 0 zu setzen, damit Sie den Abfragecache explizit deaktivieren. Bitte vergessen Sie nicht, query_cache_size ebenfalls auf 0 zu setzen . Andernfalls tritt das Mutexing-Verhalten ohnehin passiv auf.

Wie ich in meinem alten Beitrag sagte , müssen Sie den Abfrage-Cache nicht unbedingt deaktivieren, wenn Sie die Größe Ihrer häufigsten Ergebnismengen vernünftigerweise kennen. Wenn Sie diese Größe herausfinden können, können Sie query_cache_limit und query_cache_min_res_unit als Ober- und Untergrenze der Ergebnismengengrößen festlegen. Nur dann können Sie query_cache_type auf 1 setzen.

Wie für Ihre Protokolldatei-Empfehlungen

[--] Log file: (0B)
[!!] Log file  doesn't exist
[!!] Log file  isn't readable.

Vielleicht könnte dies das erklären

[!!] Currently running unsupported MySQL version 10.0.29-MariaDB-0ubuntu0.16.04.1

Es ist möglich, dass mysqltuner sich nicht auf Protokolldateien in dieser Version von MariaDB beziehen kann, wie dies bei unterstützten Versionen der Fall ist.

— RolandoMySQLDBA
quelle

Ihre Aussagen zum Abfrage-Cache gelten auch für MariaDB 10.xx?

— Ivanov

Bedeutet das, dass Sie empfehlen, den Cache auszuschalten? Würde sich das auf die Leistung auswirken? In diesem Fall wäre ich bereit, Messungen durchzuführen, um query_cache_limit und query_cache_min_res_unit korrekt festzulegen und query_cache auszuführen. Ich kann zwar auch Redis verwenden, um Abfrageergebnisse zwischenzuspeichern, wenn dies einfacher wäre (aber ich nehme an, MariaDb würde die Cache-Ungültigmachung ohne zusätzliche Arbeit behandeln?). Ich bin nicht wirklich DBA, irgendwelche Tipps zum Messen dieser Größe? Ich verwende ORM und kann es daher nicht wirklich in meiner Anwendung messen.

— Pzaj

3

Vertrauen Sie nicht (verlassen Sie sich nur darauf) - für mysqltunner müssen alle Einstellungen basierend auf der tatsächlichen Überwachung und dem Laden angepasst werden.

Protokolldateigröße von einer Seite - Es wird eine Größe von 0,5 bis 1 Stunde aller Transaktionen in diesem Zeitraum empfohlen

aber von der anderen Seite - wenn es mehr als 1-2 GB Neustart nach dem Absturz kann Ewigkeiten dauern. Als größere Protokolle - als längerer Start.

So balanciert es immer zwischen.

Beginnen Sie mit 512 MB pro Datei (insgesamt 1 GB) und erhöhen Sie bei hohem Ladevorgang auf 1024 GB

besser zu überprüfen, was drin ist:

Slow queries: 27% (221/812)

welche abfragen
warum langsam?
ist es nach Datengröße? oder durch falsche Indizes?

Dies könnte mehr für die Leistung geben

— a_vlad
quelle

1

Vielen Dank für Ihre Kommentare. Ich werde einen Blick auf die Größe der Protokolldatei werfen und Ihre Empfehlungen anwenden. Was langsame Abfragen betrifft, haben Sie Recht, das ist eine Sache, die ich überprüfen werde. Ich habe in meiner Frage nicht danach gefragt, weil ich weiß, wie ich damit umgehen soll. Ich kann Ihnen vorerst nur sagen, dass sie alle unter 20 ms liegen und nur vollständige Scans durchführen. Einige von ihnen verwenden tmp_table und tmp_disk_table, da ich die Reihenfolge nach Klauseln nehme. Dies ist etwas, das ich zu optimieren versuchen werde, sobald ich Tools gefunden habe, mit denen ich potenziell fehlende Indizes identifizieren kann

— pzaj

2

Die Ausgabe ist praktisch nutzlos, da das System nur 15 Sekunden lang ausgeführt wurde. Warten Sie mindestens einen Tag.

Trotzdem ist der Prozentsatz der "langsamen" Abfragen schrecklich. Schalten Sie das Slowlog ein, warten Sie einen Tag und verwenden Sie pt-query-Digest, um die schlimmsten Abfragen zu finden. Dann lass uns darüber diskutieren.

Ich hätte nicht gedacht, dass InnoDB ohne eine Protokolldatei laufen könnte! (Oder bezieht es sich vielleicht auf eine andere Protokolldatei?) Später heißt es innodb_log_file_sizejedoch 512M. Das sollte vorerst eine anständige Größe sein. (Sie müssen sich vorerst auf andere Themen konzentrieren.)

Für Produktionssysteme mit vielen Schreibvorgängen ist dies die beste QC-Einstellung:

query_cache_type = OFF
query_cache_size = 0

Wenn Sie eine andere Bewertung wünschen, geben Sie bitte SHOW VARIABLES;und SHOW GLOBAL STATUS;(nach mindestens einem Tag auf).

— Rick James
quelle

Ja, 15 Sekunden ist nicht genug Zeit.

— Philippe Delteil