Warum funktioniert Percona pt-Online-Schema-Änderung so schlecht?

Question

Wir haben Percona OSC für eine Weile verwendet, um Änderungen an unserem MySQL-Schema vorzunehmen, ohne die Tabellen zu sperren, und es hat gut funktioniert, in der Regel eine neue Spalte oder einen Index zu "großen" innodb -Tabellen (~ 3,8 Millionen Zeilen) hinzuzufügen ein paar Stunden.

Die letzte Aktualisierung, die ich versuchte, war jedoch nur zu 40% nach 7 Stunden (über Nacht, während unserer ruhigsten Periode) abgeschlossen, mit einer Schätzung von weiteren 11 Stunden (die weiter zunimmt). Alle 4 GB des verfügbaren Speichers auf dem RedHat-Server wurden genutzt - 32 GB, die wir kürzlich von 16 GB aufgerüstet haben.

Also, was ist hier los? Warum konnte die Zeit plötzlich so hoch gesprungen sein? Haben wir gerade eine Art Schwelle erreicht, mit der percona/mysql/der Server nicht umgehen kann? Gibt es Konfigurationen, die wir optimieren können, um die Leistung zu verbessern?

Die Tabelle enthält 32 Spalten und 12 Indizes (einschließlich Primärschlüssel und 2 anderen eindeutigen Indizes). Ich weiß, das ist viel, aber wie ich bis vor kurzem sagte, hat es gut funktioniert.

Die Tabelle weist auch mehrere Fremdschlüssel auf, auf die wir mit der Methode drop_swap aktualisieren.

Der vollständige Befehl, den ich verwendet wurde:

pt-online-schema-change --execute --ask-pass --set-vars innodb_lock_wait_timeout=50 --alter-foreign-keys-method=drop_swap 
--alter "ADD is_current TINYINT(1) DEFAULT '1' NOT NULL" u=admin,p=XXXXXXX,D=xxxxx_live,t=applicant 

Die innodb_buffer_pool_size derzeit 2147483648 gesetzt ist - sollte dies erhöht werden? Wenn ja, um wie viel? Der Webserver (apache/php/symfony) läuft ebenfalls auf dieser Box.

Die letzte Änderung, die ich an dieser bestimmten Tabelle vorgenommen habe, war, die Sortierung von 1 Feld in utf8_bin zu ändern (die anderen Felder sind utf8_unicode_ci) - könnte das einen Unterschied machen?

Answer 1

Unter der Annahme, dass alle Dinge gleich sind, würde ich sagen, dass eine Art Schwellenwert überschritten wurde oder ein anderer Prozess die Datenbank lädt. Die Anzahl der verwendeten Indizes ist sehr hoch. pt-osc erstellt die neue leere geänderte Tabelle und beginnt dann mit dem Kopieren in "Chunks". Die für jeden Block benötigte Zeit wird dynamisch an die letzten 0,5 Sekunden angepasst (standardmäßig). Sie könnten "show processlist" überprüfen, um zu sehen, wer die Datenbank unter Druck setzt und welche Chunk-Größe pt-osc verwendet, um mehr Einsicht zu erhalten.

Answer 2

Wie groß ist diese Tabelle in Bezug auf MB/GB?

InnoDB speichert seine Seiten im Innodb-Pufferpool (innodb_buffer_pool_size), was für die Performance wichtig ist. Auf dedizierten Hosts mit> 4GB RAM empfehlen wir die Richtlinie von ca. 70-80% des Speichers sollte für den InnoDB-Pufferpool verwendet werden.

die SQL zu diesem Beitrag Verwenden Sie die logischen Größen Ihrer Tabellen und Indizes

https://www.percona.com/blog/2008/03/17/researching-your-mysql-table-sizes/

Mit diesen Informationen zu sammeln, werden Sie sofort sagen können, wenn die MySQL-Instanz (InnoDB-Engine) ist seine ausgehungert von der Erinnerung.

Wenn Ihr Arbeits-Dataset in den Arbeitsspeicher passt, toll, aber wenn nicht, entstehen wahrscheinlich Cache-Fehler und MySQL muss IO ausführen, um auf Datenträger-Ressourcen zuzugreifen, um die Seiten in den Pufferpool zu tauschen. (IO ist immer ein PITA in DB Land)

Die Art der pt-osc Arbeit ist es, eine neue modifizierte Kopie der Tabelle zu erstellen und füllen Sie die neue Version mit den Zeilen aus dem Original.Neue Zeilen werden auch mithilfe der vom Tool eingerichteten Trigger eingefügt/aktualisiert oder gelöscht. Um dieses Backfill auszuführen, muss es irgendwann alle Zeilen in dieser Tabelle berühren und ein Großteil der Tabelle könnte kalt sein (nicht im Pufferpool im RAM). Im Grunde genommen hat man auf der Maschine eine bescheidene Menge an RAM, aber InnoDB sieht nur 2 GB davon.

Sie haben Anwendungen, die auf dem Server auch laufen, also wird es einige Beobachtung auf Ihrer Seite nehmen, um zu tunen, aber ich würde erwarten, dass Sie das Niveau des dem Pufferpool zugeteilten Gedächtnisses beträchtlich erhöhen konnten. Ich würde auch erwarten, dass ein großer Teil Ihres RAM nicht verwendet wird, sondern dem Dateisystemcache zugewiesen wurde.

Wenn Ihre Tabelle nur ein paar hundert mb ist (was ich mit 4m Datensätzen und einem breiten Schema bezweifle), dann gibt es vielleicht tiefere Probleme zu überprüfen, aber ich bin zuversichtlich, dass mit einer Änderung der Pufferpoolgröße Sie sehen werden etwas bessere Leistung.

Überprüfen Sie auch, ob Ihr innodb_log_file_size auf Ihre Arbeitslast abgestimmt ist. Dies ist wichtig, damit MySQL IO verzögern kann. Wie groß ist die aktuelle Größe?