Cómo obtener un buen rendimiento de lectura concurrente desde el disco

Me gustaría hacer una pregunta y luego seguirla con mi propia respuesta, pero también ver qué respuestas tienen otras personas.

Tenemos dos archivos grandes que nos gustaría leer de dos hilos separados al mismo tiempo. Un hilo leerá secuencialmente el archivo A mientras que el otro hilo leerá secuencialmente el archivo B. No hay bloqueo ni comunicación entre los hilos, ambos leen secuencialmente lo más rápido que pueden y ambos descartan de inmediato los datos que leen.

Nuestra experiencia con esta configuración en Windows es muy pobre. El rendimiento combinado de los dos subprocesos es del orden de 2-3 MiB / seg. La unidad parece estar pasando la mayor parte de su tiempo buscando hacia atrás y hacia adelante entre los dos archivos, presumiblemente leyendo muy poco después de cada búsqueda.

Si deshabilitamos uno de los subprocesos y observamos temporalmente el rendimiento de un solo subproceso, obtendremos un ancho de banda mucho mejor (~ 45 MiB / seg para esta máquina). Claramente, el mal rendimiento de dos hilos es un artefacto del programador de disco del sistema operativo.

¿Hay algo que podamos hacer para mejorar, el rendimiento concurrente de lectura de subprocesos? Tal vez mediante el uso de diferentes API o ajustando los parámetros del planificador del disco del sistema operativo de alguna manera.

Algunos detalles

Los archivos están en el orden de 2 GiB cada uno en una máquina con 2GiB de RAM. A los efectos de esta pregunta, consideramos que no están almacenados en caché y perfectamente desfragmentados. Hemos utilizado herramientas de desfragmentación y reiniciado para garantizar que este sea el caso.

No estamos utilizando API especiales para leer estos archivos. El comportamiento es repetible en varias API estándar de pantano como CreateFile de Win32, fopen de C, std :: ifstream de C ++, FileInputStream de Java, etc.

Cada hilo gira en un bucle haciendo llamadas a la función de lectura. Hemos variado el número de bytes solicitados a la API en cada iteración de valores entre 1 KB y 128 MB. Variar esto no ha tenido ningún efecto, por lo que claramente la cantidad que el sistema operativo está leyendo físicamente después de cada búsqueda de disco no está dictada por este número. Esto es exactamente lo que se debe esperar.

La dramática diferencia entre el rendimiento de uno y dos hilos es repetible en Windows 2000, Windows XP (32 bits y 64 bits), Windows Server 2003, y también con y sin hardware RAID5.

Respuestas a la pregunta(12)

Su respuesta a la pregunta