uso paralelo correcto de xargs

Estoy usando xargspara llamar a un script de Python para procesar unos 30 millones de archivos pequeños. Espero usar xargspara paralelizar el proceso. El comando que estoy usando es:

find ./data -name "*.json" -print0 |
  xargs -0 -I{} -P 40 python Convert.py {} > log.txt

Básicamente, Convert.pyleerá en un pequeño archivo json (4kb), procesará y escribirá en otro archivo de 4kb. Estoy corriendo en un servidor con 40 núcleos de CPU. Y no se está ejecutando ningún otro proceso intenso de CPU en este servidor.

Al monitorear htop (por cierto, ¿hay alguna otra buena manera de monitorear el rendimiento de la CPU?), Encuentro que -P 40no es tan rápido como se esperaba. A veces, todos los núcleos se congelarán y disminuirán casi a cero durante 3-4 segundos, luego se recuperarán al 60-70%. Luego trato de disminuir el número de procesos paralelos -P 20-30, pero aún no es muy rápido. El comportamiento ideal debe ser la aceleración lineal. ¿Alguna sugerencia para el uso paralelo de xargs?

xargs parallelism

— Yan Zhu
fuente

Lo más probable es que sea afectado por E / S: el sistema no puede leer los archivos lo suficientemente rápido. Intente iniciar más de 40: de esta manera, estará bien si algunos de los procesos tienen que esperar E / S.

— Ole Tange

¿Qué tipo de procesamiento hace el script? ¿Alguna base de datos / red / io involucrada? ¿Cuánto tiempo dura?

— Fox

Yo segundo @OleTange. Ese es el comportamiento esperado si ejecuta tantos procesos como núcleos y sus tareas están vinculadas a IO. Primero, los núcleos esperarán en IO su tarea (suspensión), luego se procesarán y luego se repetirán. Si agrega más procesos, los procesos adicionales que actualmente no se ejecutan en un núcleo físico habrán dado inicio a operaciones de E / S paralelas que, cuando terminen, eliminarán o al menos reducirán los períodos de suspensión en sus núcleos.

— PSkocik

1- ¿Tienes habilitado hyperthreading? 2- en lo que tienes allí arriba, log.txt se sobrescribe con cada llamada a convert.py ... no estoy seguro de si este es el comportamiento previsto o no.

— Bichoy

xargs -Py se >está abriendo para condiciones de carrera debido al problema de media línea gnu.org/software/parallel/… Usar GNU Parallel en su lugar no tendrá ese problema.

— Ole Tange

Respuestas:

Estaría dispuesto a apostar que su problema es Python . No dijo qué tipo de procesamiento se está realizando en cada archivo, pero suponiendo que solo está haciendo el procesamiento en memoria de los datos, el tiempo de ejecución estará dominado por el inicio de 30 millones de máquinas virtuales de Python (intérpretes).

Si puede reestructurar su programa de Python para tomar una lista de archivos, en lugar de solo uno, obtendrá una gran mejora en el rendimiento. Aún puede usar xargs para mejorar aún más el rendimiento. Por ejemplo, 40 procesos, cada uno procesando 1000 archivos:

find ./data -name "*.json" -print0 |
  xargs -0 -L1000 -P 40 python Convert.py

Esto no quiere decir que Python sea un lenguaje malo / lento; simplemente no está optimizado para el tiempo de inicio. Verá esto con cualquier lenguaje virtual basado en máquina o interpretado. Java, por ejemplo, sería aún peor. Si su programa fue escrito en C, todavía habría un costo de iniciar un proceso separado del sistema operativo para manejar cada archivo, pero sería mucho menor.

A partir de ahí, puede jugar -Ppara ver si puede obtener un poco más de velocidad, tal vez al aumentar el número de procesos para aprovechar los procesadores inactivos mientras se leen / escriben los datos.

— James Scriven
fuente

En primer lugar, considere las restricciones:

¿Cuál es la restricción en cada trabajo? Si se trata de E / S, es probable que pueda salirse con múltiples trabajos por núcleo de CPU hasta llegar al límite de E / S, pero si es intensivo en CPU, será peor que ejecutar inútilmente más trabajos al mismo tiempo que los núcleos de CPU.

Entiendo estas cosas es que GNU Parallel le daría un mejor control sobre la cola de trabajos, etc.

Vea GNU paralelo vs & (quiero decir fondo) vs xargs -P para una explicación más detallada de cómo los dos difieren.

— Stephen
fuente

Como otros dijeron, verifique si está vinculado a E / S. Además, la página de manual de xargs sugiere usar -ncon -P, no mencionas la cantidad de Convert.pyprocesos que ves ejecutándose en paralelo.

Como sugerencia, si está vinculado a E / S, puede intentar usar un dispositivo de bloqueo SSD, o intentar hacer el procesamiento en un tmpfs (por supuesto, en este caso debe verificar si hay suficiente memoria, evitando el intercambio debido a tmpfs presión (creo), y la sobrecarga de copiar los datos en primer lugar).

— spuk
fuente