Solución 1:
Después de muchas pruebas comparativas con sysbench, llegué a esta conclusión:
Para sobrevivir (desde el punto de vista del rendimiento) a una situación en la que
- un proceso de copia malicioso inunda las páginas sucias
- y el caché de escritura del hardware está presente (posiblemente también sin eso)
- y las lecturas o escrituras síncronas por segundo (IOPS) son críticas
simplemente descargue todos los ascensores, colas y cachés de páginas sucias. El lugar correcto para las páginas sucias es la RAM de la caché de escritura de ese hardware.
Ajuste la relación sucia (o los nuevos bytes sucios) lo más bajo posible, pero vigile el rendimiento secuencial. En mi caso particular, 15 MB eran óptimos (echo 15000000 > dirty_bytes ).
Esto es más un truco que una solución porque los gigabytes de RAM ahora se usan solo para el almacenamiento en caché de lectura en lugar del caché sucio. Para que la caché sucia funcione bien en esta situación, el lavado de fondo del kernel de Linux necesitaría promediar la velocidad a la que el dispositivo subyacente acepta solicitudes y ajustar el lavado de fondo en consecuencia. No es fácil.
Especificaciones y puntos de referencia para la comparación:
Probado mientras dd Al poner ceros en el disco, sysbench mostró gran éxito , aumentando 10 subprocesos fsync escribe a 16 kB de 33 a 700 IOPS (límite de inactividad:1500 IOPS) y subproceso único de 8 a 400 IOPS.
Sin carga, las IOPS no se vieron afectadas (~1500) y el rendimiento se redujo ligeramente (de 251 MB/s a 216 MB/s).
dd llamar:
dd if=/dev/zero of=dumpfile bs=1024 count=20485672
para sysbench, test_file.0 se preparó para ser sencillo con:
dd if=/dev/zero of=test_file.0 bs=1024 count=10485672
llamada de sysbench para 10 subprocesos:
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
llamada de sysbench para un hilo:
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
Los tamaños de bloque más pequeños mostraron números aún más drásticos.
--file-block-size=4096 con 1 GB de bytes_sucios:
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 con 15 MB de bytes_sucios:
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 con 15 MB de bytes sucios en el sistema inactivo:
sysbench 0.4.12:punto de referencia de evaluación del sistema de subprocesos múltiples
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
Sistema de prueba:
- Adaptec 5405Z (eso es 512 MB de caché de escritura con protección)
- Intel Xeon L5520
- 6 GB de RAM a 1066 MHz
- Placa base Supermicro X8DTN (conjunto de chips 5520)
- 12 discos Seagate Barracuda de 1 TB
- 10 en software Linux RAID 10
- Núcleo 2.6.32
- Sistema de archivos xfs
- Debian inestable
En resumen, ahora estoy seguro de que esta configuración funcionará bien en situaciones inactivas, de alta carga e incluso de carga completa para el tráfico de la base de datos que, de otro modo, se habría visto privado de tráfico secuencial. El rendimiento secuencial es más alto de lo que dos enlaces gigabit pueden ofrecer de todos modos, por lo que no hay problema para reducirlo un poco.
Solución 2:
Aunque el ajuste de los parámetros del kernel detuvo el problema, en realidad es posible que sus problemas de rendimiento fueran el resultado de un error en el controlador Adaptec 5405Z que se solucionó en una actualización de firmware del 1 de febrero de 2012. Las notas de la versión dicen "Se solucionó un problema por el cual el firmware podía bloquearse durante un alto estrés de E/S". Quizás distribuir la E/S como lo hizo fue suficiente para evitar que se desencadenara este error, pero eso es solo una suposición.
Aquí están las notas de la versión:http://download.adaptec.com/pdfs/readme/relnotes_arc_fw-b18937_asm-18837.pdf
Incluso si este no fuera el caso de su situación particular, pensé que esto podría beneficiar a los usuarios que se encuentren con esta publicación en el futuro. Vimos algunos mensajes como el siguiente en nuestra salida dmesg que eventualmente nos llevó a la actualización del 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
Estos son los números de modelo de los controladores RAID de Adaptec que se enumeran en las notas de la versión del firmware que tiene la corrección de bloqueo de E/S alta:2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.