Reduzieren Sie die Haltbarkeit in MySQL für die Leistung

Question

Meine Website hat gelegentlich ziemlich vorhersehbare Verkehrsausbrüche, die den Durchsatz um das 100-fache erhöhen. Zum Beispiel werden wir in einer Fernsehshow vorgestellt, und ich erwarte in der Stunde nach der Show, dass ich mehr als 100 mal mehr Verkehr als normal bekommen werde.

Mein Verständnis ist, dass MySQL (InnoDB) in der Regel meine Daten in einer Reihe von verschiedenen Orten hält:

• RAM Puffer
• commitlog
• Binärlog von
• tatsächlichen Tabellen
• Alle die oben genannten Stellen auf meinem DB-Slave

Dies ist zu viel "Dauerhaftigkeit", da ich auf einem EC2-Knoten bin und der größte Teil des Materials über die gleiche Netzwerkleitung geht (Dateisysteme sind an das Netzwerk angeschlossen). Außerdem sind die Laufwerke nur langsam. Die Daten haben keinen hohen Wert und ich würde eher eine kleine Chance von ein paar Minuten Datenverlust nehmen, anstatt eine hohe Wahrscheinlichkeit eines Ausfalls zu haben, wenn die Menge ankommt.

Während dieser Verkehr Bursts würde ich gerne alle diese I/O nur tun, wenn ich es mir leisten kann. Ich möchte nur so viel RAM wie möglich behalten (ich habe einen ordentlichen Stapel RAM verglichen mit der Datengröße, die über eine Stunde berührt wurde). Wenn Puffer knapp werden oder der I/O-Kanal nicht zu stark ausgelastet ist, möchte ich sichergehen, dass die Dinge zum Commit-Log oder Binär-Log geschickt werden, um an den Slave gesendet zu werden. Wenn und nur wenn der I/O-Kanal nicht überlastet ist, würde ich gerne auf die tatsächlichen Tabellen zurückschreiben.

Mit anderen Worten, ich möchte, dass MySQL/InnoDB einen "Write Back" -Cache-Algorithmus anstelle eines "Write-Through" -Cache-Algorithmus verwendet. Kann ich es davon überzeugen?

Wenn dies nicht möglich ist, interessiere ich mich für allgemeine MySQL Tipps zur Optimierung der Schreibleistung. Bei den meisten Dokumenten geht es um die Optimierung der Leseperformance. Wenn ich jedoch eine große Anzahl von Benutzern erhalte, erstelle ich für alle Konten Accounts.

Answer 1

Zum großen Teil macht InnoDB dies bereits.

Wenn Sie Daten festschreiben, werden sie zu Wiederherstellungszwecken in die Protokolldatei geschrieben, Änderungen am Tabellenbereich (Daten) werden jedoch erst später als Hintergrundprozess ("Prüfpunkt") ausgeführt.

Sie können angeben, wie viele IOPS (http://en.wikipedia.org/wiki/IOPS) Sie in neueren InnoDB Releases in diesem Hintergrundprozess widmen wollen (innodb_io_capacity) und unter der Voraussetzung, dass Sie Ihre innodb_log_file_size groß genug InnoDB gesetzt werden für eine Weile hinter fallen und fangen wieder nach oben später.

Wenn InnoDB im Hintergrund zu weit zurückfällt, kann es zu Leistungseinbußen kommen, wenn Sie das Ende Ihrer Protokolldateien erreicht haben und wieder durchfahren müssen.Sehen Sie die Zeile 'none' bei diesen Benchmarks: http://www.mysqlperformanceblog.com/2009/09/15/which-adaptive-should-we-use/

Answer 2

Wenn Sie mit einem zusätzlichen Risiko leben können, werden diese beiden Änderungen Ihre Schreibleistung erheblich steigern.

Set innodb_flush_log_at_trx_commit = 0
Set sync_binlog = 0

Zusätzlich Ihre Buffer Pool-Größe sollte etwa 70-80% der Server-Speicher sein. Die Erhöhung der Protokolldateigröße und der Protokollpuffergröße können ebenfalls zu einem gewissen Grad helfen.