24 votos

límite de linux fondo de color (las páginas)

Fondo de flushing en linux pasa cuando ya sea demasiado escrito datos pendientes (ajustable a través de /proc/sys/vm/dirty_background_ratio) o un tiempo de espera para las escrituras pendientes que se alcanza (/proc/sys/vm/dirty_expire_centisecs). A menos que otro límite es ser golpeado (/proc/sys/vm/dirty_ratio), más los datos pueden ser almacenados en caché. Además escribe bloqueará.

En teoría, esto debería crear un fondo en el proceso de la escritura de páginas sucias, sin molestar a otros procesos. En la práctica, no molestar a ningún proceso de hacer no está en caché de lectura o escritura sincrónica. Mal. Esto es debido a que el fondo de rubor en realidad escribe al 100% de la velocidad del dispositivo y cualquier otro dispositivo de las solicitudes en este momento se retrasará (porque todas las colas y escribir-cachés en la carretera están llenos).

Hay alguna manera de limitar la cantidad de peticiones por segundo que el proceso de descarga se realiza, o de otra manera efectiva de dar prioridad a otro dispositivo de e/S?

18voto

korkman Puntos 1061

Después de un montón de benchmarking con sysbench, he llegado a esta conclusión:

Para sobrevivir (en cuanto al rendimiento) una situación en la que

  • un mal proceso de copia de inundaciones páginas sucias
  • y hardware de caché de escritura está presente (posiblemente también sin que)
  • y sincrónica lee o escribe por segundo (IOPS) son críticos

acaba de volcar todos los ascensores, las colas y sucio de la página de la caché. El lugar correcto para páginas sucias es en la memoria RAM de que el hardware de caché de escritura.

Ajustar dirty_ratio (o nuevo dirty_bytes) tan bajo como sea posible, pero mantener un ojo en el rendimiento secuencial. En mi caso en particular, de 15 MB fueron las óptimas (echo 15000000 > dirty_bytes).

Esto es más un hack que una solución porque gigabytes de memoria RAM que ahora son utilizados para el almacenamiento en caché de lectura sólo que en lugar de sucio caché. Para el sucio caché a funcionar bien en esta situación, el núcleo de linux fondo baldeadora necesitaría promedio de la velocidad a la cual el dispositivo subyacente acepta solicitudes y ajustar fondo de flushing en consecuencia. No es fácil.


Especificaciones y términos de referencia para la comparación:

Prueba mientras dd ing ceros en el disco, sysbench mostró gran éxito, el impulso a 10 hilos fsync escribe en 16 kb de 33 a 700 IOPS (límite de tiempo de inactividad: 1500 IOPS) y solo hilo de rosca de 8 a 400 IOPS.

Sin carga, IOPS no se vieron afectados (~1500) y en el rendimiento ligeramente reducido (de 251 MB/s a 216 MB/s).

dd llame al:

dd if=/dev/zero of=dumpfile bs=1024 count=20485672

para sysbench, el test_file.0 fue preparado para ser unsparse con:

dd if=/dev/zero of=test_file.0 bs=1024 count=10485672

sysbench convocatoria de 10 hilos:

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

sysbench convocatoria de 1 subproceso:

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

Pequeños tamaños de bloque mostró aún más drástica de los números.

--file-block-size=4096 con 1 GB dirty_bytes:

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 dirty_bytes:

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 dirty_bytes de inactividad del sistema:

sysbench 0.4.12: multi-threaded la evaluación del sistema de referencia

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

Prueba Del Sistema:

  • Adaptec 5405Z (que es de 512 MB de caché de escritura con protección)
  • Intel Xeon L5520
  • 6 GiB de RAM @ 1066 MHz
  • Tarjeta madre Supermicro X8DTN (5520 Chipset)
  • 12 seagate barracuda 1 TB de discos
    • 10 en linux software raid 10
  • el kernel 2.6.32
  • sistema de ficheros xfs
  • la rama inestable de debian

En suma, ahora estoy seguro de que esta configuración funcionará bien en ralentí, carga alta e incluso en situaciones de carga de la base de datos de tráfico que de otra forma se habrían muerto de hambre por secuenciales de tráfico. Rendimiento secuencial es mayor que el de dos enlaces gigabit puede entregar de todos modos, así que no hay problema en reducir un poco.

Gracias por la lectura y comentarios!

2voto

Jonathan Mayhak Puntos 4183

Aunque la sintonización de los parámetros del núcleo detenido el problema, es posible que tus problemas de rendimiento fueron el resultado de un error en el controlador de la 5405Z controlador que se fija en un 1 de Febrero de 2012 actualización de firmware. Las notas de la versión de decir "se ha Corregido un problema por el que el firmware puede bloquearse durante la e/S de alto estrés." Tal vez la difusión de la I/O como hizo fue suficiente para evitar que este error se activa, pero eso es sólo una conjetura.

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 era el caso para su situación en particular, pensé que esto podría beneficiar a los usuarios que vienen a través de este post en el futuro. Vimos algunos mensajes como el siguiente en nuestra salida de dmesg que finalmente 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

Aquí están los números de modelo de la RAID de Adaptec los controladores que aparecen en las notas de la versión de firmware que tiene el alta e/S de colgar revisión: 2045, 2405, 2405Q, 2805, 5085, 5405, 5405Z, 5445, 5445Z, 5805, 5805Q, 5805Z, 5805ZQ, 51245, 51645, 52445.

0voto

gcores Puntos 6618

¿Cuál es su promedio para el Sucio en /proc/meminfo? Esto no debería exceder normalmente de /proc/sys/vm/dirty_ratio. En un servidor de archivos dedicado tengo dirty_ratio establece en un porcentaje muy alto de la memoria (90), como voy a superar nunca. Su dirty_ration es demasiado bajo, cuando le pegas, todo juego de dados, lo levanta.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: