Ho un'istanza di MySQL su due server dedicati. Uno per la produzione, l'altro per la piattaforma di test.

I 2 server sono praticamente uguali, l'unica differenza è il controller RAID e il volume virtuale (HD sono gli stessi). Sulla produzione, c'è un controller RAID HW dedicato e un volume RAID 10. Dall'altro, il controller RAID sembra essere un software (Lenovo ThinkServer RAID 110i) e il volume è RAID 5.

Abbiamo notato che durante gli commit di MySQL abbiamo un alto interesse:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 e dm-14-8 sono correlati alle partizioni del database.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Ho il sospetto che il controller raid, come posso essere sicuro?

La mia risposta aveva 2 parti: indagine sul driver del dispositivo a blocchi; e l'ottimizzazione che vale la pena guardare con il tuo caso d'uso. Ma ho rimosso l'ultima parte in quanto è stato riferito che può portare alla perdita di dati. Vedi commenti

Indagine sull'hardware

Ho capito che per la stessa applicazione ma su 2 diversi set di hardware le prestazioni sono molto diverse e ti piacerebbe capire il perché. Pertanto propongo innanzitutto un mezzo per aiutarti a trovare una risposta per il "perché".

Per quanto riguarda le prestazioni, mi riferisco spesso alla Linux Performance Map fornita da Brendan Gregg sul suo blog. Si può vedere che per un livello basso (il più vicino all'hardware) uno strumento come blktracesarebbe perfetto.

Non conoscendo davvero questo strumento, cerco in giro e ho trovato questo articolo interessante su blktrace di Marc Brooker. Fondamentalmente suggerisce quanto segue: eseguire una traccia I / O usando blktrace; usando lo strumento btt per estrarre informazioni da questa traccia. Sarebbe qualcosa del genere (per una traccia di 30 s):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

L'output può essere piuttosto lungo, ma cerca le voci D2C. Ti darà un'idea del tempo necessario affinché un I / O consegnato al driver del dispositivo venga segnalato come completato da questo driver.

Esempio di output (in dnf upgradeesecuzione su una VM VirtualBox sul mio laptop occupato):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

Mostra una media deludente di 45 ms per I / O con un massimo di 3,94 s nel caso peggiore !!

Per altri modi di utilizzare blktrace per eseguire questa indagine, leggi l'articolo di Marc Brooker, molto istruttivo.

Il processo jbd2 è per journaling ext4. È logico che il filesystem debba scrivere nel journal durante i commit di mysql, questo non dovrebbe essere motivo di preoccupazioni. La quantità di carico causata da jbd è influenzata dai parametri di montaggio per le partizioni dm-10-8 e dm-14-8. È probabilmente preferibile avere un journaling molto conservativo nella partizione del database per assicurarsi che il database non venga danneggiato se succede qualcosa e il server si riavvia accidentalmente. È possibile selezionare un'altra opzione di montaggio journal nell'ambiente di test solo per confronto.