¿Cómo puedo probar el efecto de ionice (contra un dispositivo usando el planificador cfq)?

Estoy tratando de construir un experimento para medir el efecto de ionice. Lo que me gustaría hacer es (por otra respuesta en serverfault ) causar I / O bastante frecuente que un proceso suficientemente "niced" es hambre de cualquier E / S.

Sobre la base de otra respuesta en serverfault , creo que necesito causar al menos una operación real de E / S a un dispositivo común CFQ-programado cada 250ms. Mi pensamiento era escribir un programa trivial que tiene un bucle que

  • Escribe en un archivo (configurable) en el dispositivo común,
  • Hace un fsync() (para forzar una operación definida de E / S),
  • Usa usleep() para retrasar una cantidad configurable de tiempo
  • Periódicamente utiliza lseek() para truncar el archivo (para que no llene el sistema de archivos)

A continuación, iniciar una instancia del programa utilizando ionice -c3 (clase de planificación de inactividad ) en contra de un archivo en el dispositivo común. Ejecuto simultáneamente varias instancias con la clase de planificación predeterminada ( best-effort ), especificando un archivo diferente en el dispositivo común (variando los valores de retardo).

Mi hipótesis era que para valores de retardo de 250 ms o más en el proceso de "mejor esfuerzo", vería progreso realizado por el proceso "ocioso"; Para valores inferiores a 250 ms, vería poco o ningún progreso realizado por el proceso "inactivo".

Mi observación fue que no hubo diferencias en el desempeño de los dos procesos; Ambos hicieron progresos similares. Sólo para estar seguro (en caso de que el reloj de pared indica que el proceso de "mejor esfuerzo" estaba realizando E / S mucho más rápido que cada 250ms), empecé múltiples instancias simultáneas del proceso de "mejor esfuerzo" especificando no (cero) retrasar. Sin embargo, no veía ninguna diferencia en el rendimiento entre los procesos en las dos clases de programación.

Sólo para estar seguro, revisé la clase del planificador:

 $ cat /sys/block/xvda/queue/scheduler noop anticipatory deadline [cfq] 

¿Qué es lo que me falta acerca de cómo funciona el planificador cfq?

Si es importante, esto está en un kernel 2.6.18.

One Solution collect form web for “¿Cómo puedo probar el efecto de ionice (contra un dispositivo usando el planificador cfq)?”

Intentaría medir el efecto usando un generador de carga como el stress -in o el stress -dn , donde "n" es el número de procesos. Corre eso en una ventana. Intente nmon o iostat en otro e intente un proceso de aplicación representativo en el mismo dispositivo de bloque. Vea cómo cambia el tiempo de servicio en iostat con varios ajustes de ionice (o pruebe la respuesta desde su aplicación).

En cuanto a cfq, parecía haber cambios a lo largo del ciclo de vida de RHEL5 (en 2.6.18). Era bastante notable en mis servidores de aplicaciones que tuve que pasar a la noop y los elevadores de deadline debido a los problemas de contención.

El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.