MySQL auf EC2/EBS. Zu langsam?

Question

Ich habe eine MySQL m2.2xlarge Instanz auf AWS. Das MySQL-Datenverzeichnis befindet sich im Root-EBS /. Es ist ein einzelnes EBS nicht RAID. Wir haben drei Haupttabellen. Einer von ihnen Table C, der größte Inhalt, wird nur die letzten Tage der Daten verwendet. Die Insert-Rate in diesen Tabellen beträgt ungefähr 80.000 Zeilen A DAY. Die 3 Tabellen haben rund 42 Millionen Zeilen. Die innodb_buffer_pool_size hat ~ 30 GB des Instanz-RAM.

Table A das wichtigste ist, ist die Datenlänge ~ 33GB und Index ~ 11GB Table B Datenlänge ~ 8 GB und Index ~ 5GB

Auf unserer Website die beiden Hauptanfragen (Latenz weise) hat, sind dies wie: unter < 50 ms jeweils

SELECT * FROM TableA WHERE id in (.....) 

SELECT * FROM TableB JOIN .... WHERE id in (.....) 

In den meisten Seiten der (...) werden einige ~ 50 letzten ids mit diesen Abfragen sein. Aber auf einigen anderen Seiten treffen wir auf ältere IDs und die Latenz für diese Abfragen steigt auf 500ms, 800ms, bis zu 1,5 Sekunden.

Ich habe einen Test gemacht, wo ich nach einem Mysql-Neustart eine SELECT id FROM TableB gemacht habe, um den Index in den Cache/Speicher zu zwingen. Die Abfrage wäre immer noch langsam. Dann habe ich eine SELECT * FROM TableB gemacht. Und jetzt, mit der ganzen Tabelle im Cache/Speicher, werden die Abfragen sehr schnell (< 50ms).

Meine Frage:> 500 ms,> 1000ms ist eine angemessene Latenz für eine Abfrage, die Zeilen nur durch PRIMARY KEY abruft? Sogar in einer 42M-Tabelle? Selbst wenn alle Zeilen auf der Festplatte liegen? Es scheint zu viel für mich.

Würde das Verschieben von MySQL-Daten in ephemeren Speicher (/ mnt) dies verbessern? Wäre die Verwendung von Provisioned IOPS hilfreich?

Answer 1

Haftungsausschluss: Ich bin überhaupt kein Experte für (My) SQL-Leistung, sondern nur die AWS-Aspekte Ihres Anwendungsfalls kommentieren.

Mit diesem aus dem Weg, gibt es mehr Fragen zu beantworten, in erster Linie:

Would bewegt MySQL-Daten zu ephemeren Speichern (/ mnt) diese verbessern?

Ich habe eine Antwort auf die gleiche Frage zur Verfügung gestellt Will moving data from EBS to ephemeral storage improve MySQL query performance?, überprüfen Sie es bitte für einige wichtige Details aus - TL; DR: Sie definitiv nicht wollen, das zu tun, wenn Sie irgendwelche Haltbarkeit braucht (es sei denn, Sie wissen genau, was Sie tun), und Performance-Gewinne durch ephemeren Speicher in der Vergangenheit sind bestenfalls zweifelhaft, wenn auch nicht falsch aus heutiger Sicht.

Würde die Verwendung von Provisioned IOPS helfen?

Absolut, sind Provisioned IOPS Volumes speziell speziell auf die Bedürfnisse von I/O-intensive Workloads gerecht zu werden, vor allem Datenbank-Workloads, die auf die Speicherleistung und Konsistenz in I/O-Durchsatz random access empfindlich sind, finden Sie in der Post Fast Forward - Provisioned IOPS for EBS Volumes für eine allgemeine Einführung.

• Bitte beachten Sie, dass diese im Idealfall (aber nicht notwendigerweise) mit EBS-Optimized Instances Hand in Hand gehen, die eine optimierte Konfiguration Stack verwenden und bietet zusätzliche, dedizierte Kapazitäten für EBS I/O.Diese Optimierung bietet die beste Leistung für Ihre EBS-Volumes, indem Konflikte zwischen EBS-E/A und anderem Datenverkehr von Ihrer Amazon EC2-Instanz minimiert werden.

• Insbesondere sollten Sie durch den dedizierten Abschnitt Increasing EBS Performance, lesen, die Adressen, wie man Blick auf die I/O-Leistung, die Sie benötigen und Ihre Möglichkeiten zur Steigerung der EBS Leistung diese Anforderungen mit RAID und/oder zu treffen Provisionierte IOPS abhängig von Ihrem Anwendungsfall.

Meine Frage:> 500 ms,> 1000 ms ist eine vernünftige Latenz für eine Abfrage, die nur Zeilen, die von PRIMARY KEY ruft? Sogar in einer 42M-Tabelle? Selbst wenn alle Zeilen auf der Festplatte liegen? Es scheint zu viel für mich.

Wie erwähnt kann ich nicht die Werte beurteilen als solche, aber angesichts Ihrer Spezifikation, die Sie scheinen Speicher Anstoßes zu haben, sofern die m2.2xlarge Instanz verfügt ‚nur‘ 34,2 GiB Arbeitsspeicher und Sie Zuweisung ~ 30GB für die innodb_buffer_pool_size bereits - das scheint mir ein bisschen hoch zu sein angesichts der anderen Speicheranforderungen des Betriebssystems und/oder MySQL, so dass möglicherweise bereits ein Austausch involviert ist, was perfekt das Cache/Speicher-Erwärmungsverhalten erklären würde.

• Als eine allgemeine Empfehlung für Datenbank-Workloads es der größte Knall für den Dollar zu sein scheint in diesen Tagen bei weitem zu einfach Ihre Daten-Set gewährleisten vollständig in den Arbeitsspeicher passt, die als einfacher ist, je mit der Fülle von Instanztypen (falls überhaupt erst möglich).

Schließlich empfehle ich die sehr kürzlich erschienenen Beitrag über Improving PostgreSQL performance on AWS EC2 zu lesen - die Empfehlungen dort in erster Linie die AWS-Seite der Dinge ansprechen, wie gut und gelten auch entsprechend für MySQL; Abschnitt Durable Datenbanken ziemlich fasst meine Vorschläge oben:

Für eine dauerhafte Datenbank, in der Sie Ihre Daten kümmern, was Sie anstelle einer hohen I/O-Instanz wollen, ist ein EBS Optimized instance, die Netzwerkbandbreite garantiert hat die EBS-Speicherserver. Verwenden Sie EBS-Volumes mit provisioned IOPs und streichen Sie für optimale Ergebnisse eine Gruppe von EBS-Volumes in ein RAID10-Array. Siehe increasing EBS performance.

Answer 2

Wenn Sie IN-Anweisung conatins SQL-Unterabfrage als EC2-Instanz kann sehr langsam sein, wie standardmäßig verwendet es MySQL 5.5 (für mor Detail Blick auf MySQL is extremely slow on EC2)