Schrecklicher Rückgang der MySQL-Leistung nach dem Upgrade auf Ubuntu 16.04 MySQL 5.7.12

2823
Igor Chudov

Ich habe einen Entwicklungsserver, den ich kürzlich von 14.04 auf 16.04 aktualisiert habe.

Ich habe eine Datenbank 'Algebra', die Daten für meine Website algebra.com hostet. Es ist eine Q & A-Website, die Fragen und Antworten mit einer 1 zu N-Beziehung enthält.

Nach dem Upgrade verschlechterte sich die Leistung derselben genauen Datenbankabfrage dramatisch.

Beispielsweise dauerte eine Abfrage, die Fragen und Antworten anhand der Fragen-ID zusammenfügt, weniger als eine halbe Sekunde. Nach dem Upgrade dauert es eine Minute.

Da dies ein Entwicklungsserver ist, kann ich ihn mit dem Produktionsserver vergleichen, auf dem Ubuntu 14.04 weiterhin ausgeführt wird und die gleiche Abfrage nur 0,38 Sekunden dauert.

Hier sind die Abfragepläne

mysql> explain SELECT  -> questions.id, questions.email, questions.topic, questions.question,  -> questions.date,  -> questions.deleted,  -> questions.is_spam,  -> questions.solved,  ->  -> questions.tb_id,  -> questions.tb_isbn,  -> questions.tb_title,  -> questions.tb_edition,  -> questions.tb_chapter,  -> questions.tb_problem,  ->  -> solutions.id, solutions.author author, solutions.date, solutions.answer  -> FROM questions, solutions  -> WHERE  -> questions.solved = 1  -> AND questions.id = solutions.question  -> AND questions.deleted != 1  -> AND questions.is_spam != 1  -> ORDER BY solutions.date DESC  -> LIMIT 50;

Auf dem "guten Server":

+----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+ | 1 | SIMPLE | solutions | ALL | solutions_by_question | NULL | NULL | NULL | 650770 | Using filesort | | 1 | SIMPLE | questions | eq_ref | PRIMARY | PRIMARY | 4 | algebra.solutions.question | 1 | Using where | +----+-------------+-----------+--------+-----------------------+---------+---------+----------------------------+--------+----------------+ 2 rows in set (0.00 sec)

Auf dem "Bad Server":

+----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+ | 1 | SIMPLE | questions | NULL | ALL | PRIMARY | NULL | NULL | NULL | 482186 | 8.10 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | solutions | NULL | ref | solutions_by_question | solutions_by_question | 4 | algebra.questions.id | 1 | 100.00 | Using index condition | +----+-------------+-----------+------------+------+-----------------------+-----------------------+---------+----------------------+--------+----------+----------------------------------------------+

Die Datenbankinhalte sind mehr oder weniger gleich, die Entwicklungsdatenbank ist eine Sicherung des Servers von gestern Abend.

Irgendwelche Ideen, wo ich mit dieser wilden Gänsejagd beginnen kann, die den Leistungsabfall versteht?

Vielen Dank!

2
Versuchen Sie es mit einem expliziten Join. Sind auch die Daten gleich? Daniel B vor 7 Jahren 0
Sie haben sehr unterschiedliche Ausgaben für den guten Server und den fehlerhaften Server ... DavidPostill vor 7 Jahren 0
Sie müssen verschiedene Versionen von MYSQL ausführen, da Ihre Ergebnisse unterschiedlich sind. Eine gibt 640 KB Zeilen zurück, die andere 450 KB. Die MySQL-Version ist also eindeutig auf eine dokumentierte Änderung zurückzuführen, die dazu führt, dass die Abfrage andere Ergebnisse liefert. In der Spalte "Extra" und "Schlüssel" finden Sie alles, was Sie wissen müssen. Ramhound vor 7 Jahren 0
Was speziell mit der Abfrage falsch ist, liegt hier leider außerhalb des Geltungsbereichs. Ramhound vor 7 Jahren 0
Ja, die Daten sind gleich (ein Tag Unterschied). Ich führe tatsächlich verschiedene Versionen von Mysql aus, da ich, wie Titel und Beschreibung sagen, auf ein zwei Jahre älteres Release von Ubuntu umgestiegen bin. Das sieht nach einer sehr langweiligen Garten-Sortenabfrage aus, und ich bin überrascht, dass mysql im 21. Jahrhundert damit nicht umgehen konnte, auch wenn eine zwei Jahre alte Version es gut beherrschte. Igor Chudov vor 7 Jahren 0

2 Antworten auf die Frage

1
Sean Wilson

Wenn Sie auf einen Ubuntu-Server mit 16.04 aktualisiert haben und 5.7.12 verwenden, stoßen Sie zumindest teilweise auf einen RAM-Speicher und einige dynamische Optimierungen / Standardeinstellungen, die auf dem verfügbaren Arbeitsspeicher des Servers basieren weniger als ideal eingestellt. Dies war für viele Menschen problematisch, vor allem aber für kleinere Server / VPS mit geringem RAM.

Suchen Sie in laracasts.com nach MySQL 5.7 Speicherverlust

https://www.reddit.com/r/mysql/comments/4gnj93/mysql_5712_ubuntu_1604_ridiculous_memory/

Es gibt andere Probleme, von denen einige 5.7.13 natürlich behoben wurden ...

http://mysqlentomologist.blogspot.com/2016/06/fun-with-bugs-43-bugs-fixed-in-mysql.html

Es wurden auch verschiedene Optimierungen / Änderungen vorgenommen, die sich darauf auswirken, ob Sie InnoDB oder MyISAM verwenden. Um ein Beispiel zu geben: Ein kürzlich installierter VPS mit 2 GB RAM, der beim Neustart von MySQL etwa 320 MB RAM verbraucht, steigt langsam an, bis er 1 GB für eine im Leerlauf befindliche App verbraucht, im Wartungsmodus ... mit null Verkehr oder db-Abfragen (dh.) war eine OpenCart-Installation, die MyISAM verwendet ... was ich nicht wünschen würde, wenn jemand versucht, sich vorwärts zu bewegen ... aber das war ein Fall von "beeil dich und lass uns das tun und dies und ....") . Daher erfordert diese spezielle Instanz mehr Zeit und Zeit, um mit dem gleichen schwachen Leistungsproblem von MySQL fortzufahren, da MyISAM in der App eingesetzt wird, Speicherverluste aufgetreten sind und einige schlechte Standardwerte vom Oracle-Team in die Wildnis geworfen wurden.

Sicher, Sie möchten wahrscheinlich Ihre Abfragen und Verknüpfungen für die neuen Updates optimieren. Aber gleichzeitig werden Sie wahrscheinlich viel Mühe aufwenden und nichts erreichen, weil das zugrunde liegende Gedächtnis wie ein Siebproblem ausläuft. Wenn Sie Optimierungen durchlaufen, können Sie dies auch mit einem anderen MySQL-Server tun, als dem, der Probleme für Sie verursacht.

Ihre Optionen sind, wie langsam MySQL beim Beheben von Fehlern ist, folgende Optionen:

1) Ausreiten und Warten auf Repo-Updates, die das Problem beheben

2) deinstalliere die aktuelle Version und gehe zurück zu einer vorherigen (aber warum?)

3) Ersetzen Sie es durch MariaDB oder Percona

Wenn Sie einen neuen Ubuntu 16.04-Server starten, würde ich die Repositorys ändern, bevor Sie Benutzeragenten für die Remoteverwaltung anschließen oder Serververwaltungspanels installieren, sodass Sie sich auf einer MariaDB / Percona-Spur befinden. Oder verfolgen Sie die offiziellen MySQL-Repos anstelle der Ubuntu-Repos, damit Sie schneller Fixes erhalten.

Die sichere und unmittelbare Lösung (sicherlich intelligenter als die Verlängerung früherer Versionen mit Fehlern und einem wichtigen Kompatibilitätsbruchpunkt im Release-Stream) ist der Wechsel zu MariaDB oder Percona. Wenn Sie eine App verwenden, die sowohl PostgreSQL als auch MySQL verwenden kann, wechseln Sie zu Postgre - falls dies nicht unpraktisch ist.

Ich würde meine Zeit nicht damit verschwenden, die Datenbank zu optimieren, bis ich auf 5.7.13 aktualisiert und die Ergebnisse überwacht habe oder zu MariaDB oder Percona gewechselt bin. Optimierung / Fehlerbehebung 5.7.12 ist nur ein schwarzes Loch, das an Ihrer Zeit und Ihren Ressourcen saugt.

0
colan

Im Einzelnen handelt es sich um den Fehler Excessive memory, der in memory / innodb / os0file ab 5.7.8 verwendet wird .

Es wird in Ubuntu als übermäßiger RAM-Verbrauch des mysqld-Daemons in Ubuntu 16.04 verfolgt, und es gibt auch eine Diskussion über Reddit .

Verwandte Probleme