Linux File IO - Rendimiento de subprocesamiento múltiple - escribiendo en diferentes archivos

Question

Actualmente estoy trabajando en una aplicación de grabación de audio, que capta hasta 8 secuencias de audio de la red y guarda los datos en el disco (simplificado;)). En este momento, cada flujo se maneja con un hilo -> el mismo hilo también hace el trabajo de guardado en el disco.

Eso significa que tengo 8 hilos diferentes que realizan escrituras en el mismo disco, cada uno en un archivo diferente.

¿Cree que habría un aumento en el rendimiento de E/S del disco si todo el trabajo de escritura se realizara por un hilo común (que escribiría los datos en los archivos específicos)?

OS es un Linux embebido, el "disco" es una tarjeta CF, la aplicación está escrita en C

Gracias por sus ideas Nick

Answer 1

La respuesta corta: Dado que está escribiendo en un disco Flash, no esperaría que la cantidad de hilos marque la diferencia de una forma u otra. Pero si hiciera una diferencia, esperaría que los subprocesos múltiples fueran más rápidos que un solo subproceso, no más lento.

La respuesta larga:

me escribió un programa similar al que describes hace unos 6 años - se corrió en una tarjeta PowerPC Linux embebido y leyó/escribió varios archivos de audio simultáneas a/desde un disco duro SCSI manejar. Originalmente lo escribí con un solo hilo haciendo I/O, porque pensé que daría el mejor rendimiento, pero resultó que ese no era el caso.

En particular, cuando varios hilos estaban leyendo/escribiendo a la vez, la capa SCSI estaba al tanto de todas las solicitudes pendientes de todos los diferentes hilos y podía reordenar las solicitudes de E/S para buscar el cabezal de la unidad fue minimizado En el escenario de IO de subproceso único, por otro lado, la capa SCSI solo sabía acerca de la única solicitud de E/S pendiente "siguiente" y, por lo tanto, no podía hacer esa optimización. Eso significó un viaje adicional para el cabezal de la unidad en muchos casos, y por lo tanto, un menor rendimiento.

Por supuesto, su aplicación no utiliza SCSI o un disco rotativo con cabezales que necesitan búsqueda, por lo que puede no ser un problema para usted, pero puede haber otras optimizaciones que la capa de sistema de archivos/hardware puede hacer si es consciente de múltiples solicitudes simultáneas de E/S. La única forma real de averiguarlo es probar varios modelos y medir los resultados.

Mi sugerencia sería desacoplar las E/S de disco de su E/S de red moviendo su E/S de disco en un grupo de subprocesos. A continuación, puede variar el tamaño máximo de su grupo de subprocesos de E/S de 1 a N y, para cada tamaño, medir el rendimiento del sistema. Eso le daría una idea clara de lo que funciona mejor en su hardware particular, sin necesidad de reescribir el código más de una vez.

Answer 2

Si se incrustado Linux, supongo que su la máquina tiene solo un procesador/núcleo. En este caso, los hilos no mejorarán en absoluto el rendimiento de E/S. Por supuesto, el subsistema de bloques de Linux funciona bien en entornos concurrentes, pero en su caso (si mi conjetura acerca del número de núcleos es correcta) no puede haber una situación en la que varios hilos hagan algo simultáneamente.

Si mi suposición es incorrecta y usted tiene más de 1 núcleo, entonces le sugiero que haga una evaluación comparativa de E/S de disco. Escriba un programa que escriba una gran cantidad de datos de diferentes hilos y otro programa que haga lo mismo desde un solo hilo. Los resultados te mostrarán todo lo que quieres saber.

Answer 3

Creo que no hay una gran diferencia entre la solución multiproceso y la de corte único en su caso, pero en caso de subprocesamiento múltiple puede sincronizarse entre subprocesos de recepción y ningún subproceso puede afectar a otros subprocesos en caso de bloqueo en alguna llamada al sistema.
Hice particularmente lo mismo en el sistema integrado, el problema fue el alto uso de la CPU cuando kernel soltó muchas páginas sucias almacenadas en caché, el proceso de kernel de pdflush toma todo el tiempo de CPU en ese momento y si recibe stream vía udp puede se omitió debido a que la CPU estaba ocupada cuando llegó udp stream, así que resolví ese problema llamando al fdatasync() cada vez que recibí una cantidad no grande de datos.