Sehr langsame Migrationen

Question

Ich habe einen (KVM) Debian 8 VM Server es läuft MySQL 5.5.58 und PHP7.1 lokal Ich habe einen ähnlichen Rechner (Vagrant VM, Debian 8, VirtualBox). Lokal laufen meine Migrationen < 20 Sekunden, wenn ich sie in eine SQL-Datei ablege und die SQL-Datei importiere, dauert es ungefähr 2-3 Sekunden.

Allerdings laufen auf dem (KVM) Debian 8 VM Server Migrationen zwischen 10-20 Minuten. Ich habe versucht, CPU-Anzahl und RAM zu erhöhen, ohne Erfolg.

Es gibt jedoch zwei Dinge, die greately Leistung verbessern, aber noch nicht wirklich brauchbar:

1. Convert Migrationsdateien in rohe SQL und führt, die etwa 20 bis 50 Sekunden dauern.
2. Setzen Sie innodb_flush_log_at_trx_commit=0 und führen Sie Migrationen durch. Dadurch wird die Migrationslaufzeit auf ca. 4-5 Minuten reduziert, was immer noch nicht nutzbar ist.

my.cnf

[mysqld] 
sync_binlog = 0 
federated = 1 
innodb_use_sys_malloc = 0 
innodb_file_per_table = 1 
innodb_stats_on_metadata = 0 
innodb_buffer_pool_instances = 1 
query_cache_type = 0 
innodb_buffer_pool_size = 1G 
innodb_log_file_size = 768M 
innodb_flush_log_at_trx_commit = 2 
innodb_flush_method = O_DIRECT 
user  = mysql 
pid-file = /var/run/mysqld/mysqld.pid 
socket  = /var/run/mysqld/mysqld.sock 
port  = 3306 
basedir  = /usr 
datadir  = /var/lib/mysql 
tmpdir  = /tmp 
lc-messages-dir = /usr/share/mysql 
skip-external-locking 
bind-address  = 127.0.0.1 
key_buffer  = 16M 
max_allowed_packet = 16M 
thread_stack  = 192K 
thread_cache_size  = 8 
myisam-recover   = BACKUP 
#max_connections  = 100 
#table_cache   = 64 
#thread_concurrency  = 10 
query_cache_limit = 1M 
query_cache_size  = 16M 

Dateisystem:

Filesystem  Size Used Avail Use% Mounted on 
/dev/vda   32G 6.0G 25G 20%/
udev    11M  0 11M 0% /dev 
tmpfs   422M 17M 406M 4% /run 
tmpfs   1.1G  0 1.1G 0% /dev/shm 
tmpfs   5.3M  0 5.3M 0% /run/lock 
tmpfs   1.1G  0 1.1G 0% /sys/fs/cgroup 
tmpfs   211M  0 211M 0% /run/user/2031 

Was habe ich getestet und geprüft:

1. Sicherstellen, dass ich die gleiche Version von allem als lokal myqsl, php, Composer-Pakete verwenden keine Abweichungen hier verwenden.
2. Getestet VM Festplatten-FIO-Geschwindigkeiten, um sicherzustellen, gibt es keinen Engpass hier versucht Schreiben/Lesen einzelne große Datei sowie Tousands von kleinen Dateien mit hoher Geschwindigkeit auf der ganzen Linie (Festplatte ist SSD und gesund).
3. Zusätzliche Kerne und überwachte CPU-Auslastung während der Migration hinzugefügt, ist es ziemlich klein.
4. Zeitgesteuerte Ausführung von Laravel getUp Methode von Migrator. Das zeitgesteuerte Lesen der Migrationsdatei von der Festplatte, das Erstellen einer neuen Klasse und das Ausführen der Abfrage scheinen alle < 1s pro Migration used microtime(true) auszuführen.
5. Überprüft MySQL langsame Abfragen für alle langsamen Abfragen wurde nichts gefunden, Migrationen sind wirklich sehr einfach CREATE TABLE Aussagen.
6. Versucht, MySQL 5.7 zu installieren, gab es keine Verbesserung.
7. Versucht, den MySQL-Pool zu vergrößern und die RAM-Größe zu protokollieren.
8. Sicher, dass ich InnoDB verwende.

Hinweis: Diese in jeder Hinsicht geschieht MySQL verwenden ich mit MySQL getestet auf dem Host installiert ist. Ich habe Docker mysql gleichen Problem installiert. Ich habe vagrant instance und mysql innerhalb desselben Problems installiert.

Diese innodb_flush_log_at_trx_comit scheint den Unterschied zu machen, was bedeutet, dass ich etwas mit mysql vermasselt, nur nicht sicher warum. Migrationen jeder läuft wie es ist Transaktion scheint etwas verursacht Wartezeit hier nicht sicher, was noch zu prüfen.

Answer 1

Ihre Raw SQL hat wahrscheinlich eine Unordnung von INSERT Abfragen darin.

Bearbeiten Die von MySQLDump generierte SQL hat sicherlich viele Einfügungen darin. Das Füllen eines Test-DBMS erfolgt häufig über eine versionsgesteuerte SQL-Datei. Here's some q&a about doing it in docker.

Wickeln Sie jede Serie von 100 Abfragen oder so (die tatsächliche Zahl spielt keine Rolle) in Transaktionen, indem Sie START TRANSACTION; am Anfang und COMMIT; am Ende setzen. Das wird das Durcheinander beseitigen, das mit Autocommit geht. Sie erhalten eine SQL-Datei suchen etwas wie dieses:

START TRANSACTION; 
INSERT ...; 
... (more inserts) 
INSERT ...;  
COMMIT; 
START TRANSACTION; 
INSERT ...; 
... (more inserts) 
INSERT ...;  
COMMIT; 
START TRANSACTION; 
INSERT ...; 
... (more inserts) 
INSERT ...;  
COMMIT; 

Vermeiden horsing um mit innodb Parameter; Die Standardwerte sind im Allgemeinen ziemlich gut und müssen nur für große dynamische Lasten geändert werden.

Und erwarten Sie nicht, dass Ihre VMs so gut funktionieren wie Ihr Laptop. Die Zeiten, in denen Server schneller waren als Laptops, sind weg (für die meisten von uns).