Wir haben in den letzten Tagen die Obergrenzen unserer IOPs erreicht. Wir haben ein paar Mal mehr IOPS bereitgestellt. 1250 -> 2500 -> 4500. Bei jedem Schritt haben wir schnell gemerkt, dass wir alle verfügbaren IOPS nutzten, da es zwischen den Lese- und Schreibvorgängen das Maximum erreichen würde.
Heute Morgen hatten wir endlich einen weiteren Großkunden an Bord und unsere CPU, unser Speicher und unsere IOPS waren voll ausgelastet. Ich habe mich entschieden, einen größeren Datenbanktyp bereitzustellen, um das System am Laufen zu halten. Wir sind von db.m5.xlarge auf db.m5.2xlarge umgestiegen. Mit dem Upgrade haben wir auch die IOPs auf 8000 erhöht.
Jetzt wird unsere CPU im Vergleich dazu stark beansprucht und unsere IOPS liegen praktisch bei 0. Die App scheint zu reagieren, aber unsere Aufgabenwarteschlangen sind ziemlich langsam.
Es hat sich kein Code geändert, nur die Datenbank. Was übersehe ich? Meldet RDS nicht richtig?
Sie werden die Sprünge bei den Lese-IOPS in den letzten drei Tagen bemerken, diese stehen im Zusammenhang mit den höheren IOPS-Bestimmungen.
Antwort1
Sie haben wahrscheinlich eine Abfrage, die nicht funktioniert hat. (Danke für die gute Beschreibung. Hier ist die wahrscheinliche Erklärung.)
Ein Beispiel. Angenommen, eine Abfrage durchsucht eine 7 GB große Tabelle (ohne nützlichen Index usw.) mit 70 Millionen Zeilen.
Fall 1: RAM = 8 GB; innodb_buffer_pool_size= 6 GB. Die Abfrage löscht alles aus dem Cache, um den Scan abzuschließen. Dies erfordert eine solide E/A. Alle anderen Abfragen sind ebenfalls betroffen – ihre Daten wurden ebenfalls aus dem RAM gelöscht.
Fall 2: RAM = 16 GB; innodb_buffer_pool_size= 12 GB. Der erste Scan lädt die gesamte Tabelle in den Cache. Nachfolgende Ausführungen dieser Abfrage erfordern keine E/A-Vorgänge. Sogar die anderen Abfragen werden schneller ausgeführt, da es keine Konkurrenz um den Cache gibt.
In beiden Fällen wird wahrscheinlich eine Menge CPU-Leistung durch die Betrachtung aller 70 Millionen Zeilen verbraucht.
Plan A: Geben Sie Geld für mehr RAM, CPU und nicht benötigte IOPs aus.
Plan B: Finden Sie diese sehr unartige Abfrage und lassen Sie sich von uns bei der Optimierung helfen. Dann können Sie zu einer günstigeren VM zurückkehren.
Geben Sie die Abfrage und SHOW CREATE TABLEdie beteiligten Tabellen an. Die Lösung kann so einfach sein wie das Hinzufügen eines zusammengesetzten Indexes oder das Umformulieren der Abfrage.
Antwort2
Der Schlüssel war hier, überhaupt nichts zu tun. „Wie durch Zauberei“ normalisierte sich unsere CPU auf den erwarteten Wert. Die gute Nachricht war, dass ich mehrere wunde Stellen in unseren Abfragen, ein paar übereifrige Sperren und eine MENGE Wissen über die Optimierung von InnoDB/RDS/MySQL entdeckte.
Vielleicht hat RDS die Indizes langsam optimiert oder es ist etwas, das ich nicht ganz verstehe, aber jetzt ist unsere Latenz erstaunlich und der Durchsatz und die Nutzung genau dort, wo ich sie mit 4 weiteren Kernen und 2x Speicher erwarten würde.
