Gli utenti lamentano che il sistema funziona lentamente quando mysqldump è in corso

Il database MYSQL (ibdata1) ha una dimensione di 73 GB ed è configurato per essere eseguito come server di database dedicato su Windows 2008 O / S per le tabelle INNODB. Stiamo eseguendo il backup usando mysqldump mysqldump --skip-opt --quick --single-transazione --create-opzioni --extended-insert --disable-keys --add-drop-table --completete-insert - set-charset - compress --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Il file di backup Proddb0635.sql è archiviato su un server separato dal server del database. La RAM è di 12 GB. La dimensione del pool di buffer INNODB è di 6 GB. Mem.pool aggiuntivo è di 32 MB. La dimensione della cache della query è di 2 GB La lunghezza del buffer netto è di 16 M max. dimensione del pacchetto 1 GB.

la versione di mysql è 5.0.67.

Quando il backup non è in esecuzione, gli utenti sono soddisfatti delle prestazioni.

Quando il backup è in esecuzione, la percentuale di hit del pool di buffer INNODB è elevata vicino al 100%. Non ci sono letture o scritture in sospeso. innodb wait free è 0. L'utilizzo della CPU non è elevato da minimo 9% a massimo 15% La percentuale di riscontri nella cache delle query è bassa di circa il 40% con o senza mysqlbackup in esecuzione. Attualmente Task Manager di Windows sta visualizzando che vengono utilizzati 10 GB di RAM. Devo aumentare la cache delle query con solo 2 GB di RAM disponibili? mysqlld-nt sta prendendo 9,2 GB di RAM e mysqldump sta prendendo 5 MB di RAM. Alos, ha notato che la dimensione del file di dump è la stessa in presenza o in assenza dell'opzione --compress.

Devo ridurre la dimensione del pool di buffer iNNODB?

Grazie

Esiste un problema noto in Windows, che quando si invia un file di grandi dimensioni a un altro server, tutta la memoria finisce per essere allocata nella cache di sistema anziché nei processi utente. È possibile consultare la sezione Memoria fisica (MB) del Task Manager per vedere quanta memoria è allocata nella cache di sistema.

Questo può essere risolto eseguendo il backup su un disco locale, quindi facendo in modo che la macchina remota estragga quel file.

Ecco alcuni pensieri che ho sul miglioramento delle prestazioni di mysqldump, date le tue circostanze. Ecco il tuo comando:

mysqldump --skip-opt --quick --single-transazione --create-opzioni --extended-insert --disable-keys --add-drop-table --complet-insert --set-charset --compress - -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

La prima cosa che noto è che stai reindirizzando l'output su un filesystem. Dice "devNas", quindi suppongo che si tratti di Network Attached Storage . Sono un fan del NAS per i backup, ma deve essere collegato su una scheda NIC fisica separata dal traffico di produzione . Potresti non saturare la larghezza di banda, ma sono comunque in competizione. Questo sarà più un problema a causa del flag --quick, poiché svuota ogni riga invece di tenerlo in memoria.

La prossima cosa che vedo è che hai invocato --compress. Sembra che tu stia eseguendo mysql localmente poiché non hai usato l'opzione -h. Ciò può utilizzare CPU locale non necessaria in questo contesto. --Compress è necessario? Comprime solo i dati tra il client mysqldump e il server mysql, non il contenuto del file.

Poi vedo che stai usando il flag --single-transazione. Ciò provocherà CPU aggiuntiva poiché sta testando ogni selezione come parte di mysqldump.

Questo non ha nulla a che fare con le prestazioni, ma stai usando --disable-keys che funziona solo su MyISAM ( manuale ).

Potresti voler sperimentare l'esecuzione di mysqldump in remoto da un host offline e lo spostamento del file di dump sul NAS dopo il completamento per portare il più fuori banda possibile di questa operazione.

OSSERVAZIONE # 1

Ecco qualcosa da tenere a mente quando si esegue un mysqldump contro InnoDB.

Qualunque pagina sporca esista nel pool di buffer InnoDB deve prima essere scaricata sul disco. Un mysqldump attiverà lo svuotamento di una tabella InnoDB che contiene ancora pagine sporche.

Esiste un'opzione server denominata innodb_max_dirty_pages_pct . Il valore predefinito è 75 è MySQL 5.5 e 90 nelle versioni di MySQL precedenti alla 5.5. In un ambiente di produzione è OK lasciare questo numero sul valore predefinito.

Per vedere se ci sono molte pagine sporche nel pool di buffer InnoDB, eseguire questo:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

A proposito una pagina è 16K come mostra questo:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

Quando si tratta di InnoDB e mysqldump, è possibile ridurre questo numero in due circostanze.

CIRCUMSTANCE 1: impostarlo permanentemente su 0

Aggiungilo a my.ini:

[mysqld]
innodb_max_dirty_pages_pct=0

Ciò manterrà il pool di buffer InnoDB snello e medio. La fase di svuotamento della tabella InnoDB in fase di dump sarà rapida perché alcune pagine sporche possibili (forse 0) dovranno essere svuotate prima che mysqldump funzioni su di essa.

L'unico inconveniente è che se si esegue il mysqldump da un DB altamente trafficato, potrebbe esserci un aumento minore dell'I / O di scrittura a causa dell'eliminazione più frequente della pagina sporca. Puoi determinare se è così senza riavviare mysql eseguendo questo:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Lasciare l'impostazione per 12-24 ore, se le prestazioni di scrittura sono accettabili, si è pronti per partire. In caso contrario, ripristinalo con:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUMSTANCE 2: impostarlo su 0 circa 1 ora prima di mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Esegui mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 90;

OSSERVAZIONE # 2

Hai --compplete-insert come opzione mysqldump. Ciò incorporerà i nomi delle colonne in ogni stato INSERT prima della clausola VALUES. Anche con --extended-insert, su ogni batch di righe che viene inserito i nomi delle colonne vengono inviati nel mysqldump. È possibile ridurre la quantità di byte inviati a mysqldump rimuovendo --complete-insert.

RACCOMANDAZIONE

Se si dispone di un altro Windows Server che può essere configurato come Slave, eseguire i mysqldumps da quello Slave anziché dalla macchina di produzione.