Solution 1 :
Après de nombreuses analyses comparatives avec sysbench, j'arrive à cette conclusion :
Pour survivre (en termes de performances) à une situation où
- un processus de copie malveillant inonde les pages sales
- et le cache en écriture matériel est présent (peut-être aussi sans cela)
- et les lectures ou écritures synchrones par seconde (IOPS) sont essentielles
videz simplement tous les ascenseurs, les files d'attente et les caches de pages sales. Le bon endroit pour les pages modifiées est dans la RAM de ce cache d'écriture matériel.
Ajustez dirty_ratio (ou new dirty_bytes) aussi bas que possible, mais gardez un œil sur le débit séquentiel. Dans mon cas particulier, 15 Mo étaient optimaux (echo 15000000 > dirty_bytes ).
Il s'agit plus d'un piratage que d'une solution, car des gigaoctets de RAM sont désormais utilisés pour la mise en cache en lecture uniquement au lieu du cache sale. Pour que le cache sale fonctionne bien dans cette situation, le vidage d'arrière-plan du noyau Linux devrait calculer la vitesse moyenne à laquelle le périphérique sous-jacent accepte les requêtes et ajuster le vidage d'arrière-plan en conséquence. Pas facile.
Spécifications et points de comparaison :
Testé en dd En mettant des zéros sur le disque, sysbench a connu un énorme succès , boostant les écritures fsync de 10 threads à 16 Ko de 33 à 700 IOPS (limite d'inactivité :1 500 IOPS) et un seul thread de 8 à 400 IOPS.
Sans charge, les IOPS n'étaient pas affectées (~1 500) et le débit était légèrement réduit (de 251 Mo/s à 216 Mo/s).
dd appeler :
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
pour sysbench, le test_file.0 a été préparé pour être clair avec :
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
appel sysbench pour 10 threads :
sysbench --test=fileio --file-num=1 --num-threads=10 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
appel sysbench pour un thread :
sysbench --test=fileio --file-num=1 --num-threads=1 --file-total-size=10G --file-fsync-all=on --file-test-mode=rndwr --max-time=30 --file-block-size=16384 --max-requests=0 run
Les tailles de bloc plus petites ont montré des nombres encore plus drastiques.
--file-block-size=4096 avec 1 Go d'octets sales :
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 30 Write, 30 Other = 60 Total
Read 0b Written 120Kb Total transferred 120Kb (3.939Kb/sec)
0.98 Requests/sec executed
Test execution summary:
total time: 30.4642s
total number of events: 30
total time taken by event execution: 30.4639
per-request statistics:
min: 94.36ms
avg: 1015.46ms
max: 1591.95ms
approx. 95 percentile: 1591.30ms
Threads fairness:
events (avg/stddev): 30.0000/0.00
execution time (avg/stddev): 30.4639/0.00
--file-block-size=4096 avec 15 Mo d'octets sales :
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 13524 Write, 13524 Other = 27048 Total
Read 0b Written 52.828Mb Total transferred 52.828Mb (1.7608Mb/sec)
450.75 Requests/sec executed
Test execution summary:
total time: 30.0032s
total number of events: 13524
total time taken by event execution: 29.9921
per-request statistics:
min: 0.10ms
avg: 2.22ms
max: 145.75ms
approx. 95 percentile: 12.35ms
Threads fairness:
events (avg/stddev): 13524.0000/0.00
execution time (avg/stddev): 29.9921/0.00
--file-block-size=4096 avec 15 Mo d'octets sales sur le système inactif :
sysbench 0.4.12 :benchmark d'évaluation de système multithread
Running the test with following options:
Number of threads: 1
Extra file open flags: 0
1 files, 10Gb each
10Gb total file size
Block size 4Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Calling fsync() after each write operation.
Using synchronous I/O mode
Doing random write test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 0 Read, 43801 Write, 43801 Other = 87602 Total
Read 0b Written 171.1Mb Total transferred 171.1Mb (5.7032Mb/sec)
1460.02 Requests/sec executed
Test execution summary:
total time: 30.0004s
total number of events: 43801
total time taken by event execution: 29.9662
per-request statistics:
min: 0.10ms
avg: 0.68ms
max: 275.50ms
approx. 95 percentile: 3.28ms
Threads fairness:
events (avg/stddev): 43801.0000/0.00
execution time (avg/stddev): 29.9662/0.00
Système de test :
- Adaptec 5405Z (c'est-à-dire 512 Mo de cache en écriture avec protection)
- Intel Xeon L5520
- 6 Gio de RAM à 1 066 MHz
- Carte mère Supermicro X8DTN (chipset 5520)
- 12 disques Seagate Barracuda 1 To
- 10 en RAID logiciel Linux 10
- Noyau 2.6.32
- Système de fichiers xfs
- Debian instable
En résumé, je suis maintenant sûr que cette configuration fonctionnera bien dans des situations d'inactivité, de charge élevée et même de charge complète pour le trafic de base de données qui, autrement, aurait été affamé par le trafic séquentiel. Le débit séquentiel est supérieur à ce que deux liaisons gigabit peuvent fournir de toute façon, donc pas de problème pour le réduire un peu.
Solution 2 :
Même si le réglage des paramètres du noyau a résolu le problème, il est en fait possible que vos problèmes de performances soient le résultat d'un bogue sur le contrôleur Adaptec 5405Z qui a été corrigé dans une mise à jour du micrologiciel du 1er février 2012. Les notes de version indiquent "Correction d'un problème où le micrologiciel pouvait se bloquer lors d'un stress d'E/S élevé". Peut-être qu'étaler les E/S comme vous l'avez fait était suffisant pour empêcher le déclenchement de ce bogue, mais ce n'est qu'une supposition.
Voici les notes de version :http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
Même si ce n'était pas le cas pour votre situation particulière, j'ai pensé que cela pourrait profiter aux utilisateurs qui rencontreraient ce message à l'avenir. Nous avons vu des messages comme celui-ci dans notre sortie dmesg qui nous a finalement conduit à la mise à jour du firmware :
aacraid: Host adapter abort request (0,0,0,0)
[above was repeated many times]
AAC: Host adapter BLINK LED 0x62
AAC0: adapter kernel panic'd 62.
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000000
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
sd 0:0:0:0: timing out command, waited 360s
sd 0:0:0:0: Unhandled error code
sd 0:0:0:0: SCSI error: return code = 0x06000028
Voici les numéros de modèle des contrôleurs RAID Adaptec qui sont répertoriés dans les notes de version du micrologiciel qui a le correctif de blocage d'E/S élevé :2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.