Cómo usar GNU en paralelo de manera efectiva

Supongamos que quiero encontrar todas las coincidencias en el archivo de texto comprimido:

$ gzcat file.txt.gz | pv --rate -i 5 | grep some-pattern

pv --rateutilizado aquí para medir el rendimiento del tubo. En mi máquina es de aproximadamente 420Mb / s (después de la descompresión).

Ahora estoy tratando de hacer grep paralelo usando GNU paralelo.

$ gzcat documents.json.gz | pv --rate -i 5 | parallel --pipe -j4 --round-robin grep some-pattern

Ahora el rendimiento se reduce a ~ 260Mb / s. Y lo que es un parallelproceso más interesante en sí mismo es usar mucha CPU. Más que grepprocesos (pero menos que gzcat).

EDITAR 1 : he probado diferentes tamaños de bloque ( --block), así como diferentes valores para -N/ -Lopciones. Nada me ayuda en este punto.

¿Qué estoy haciendo mal?

Estoy realmente sorprendido de que consigas 270 MB / s usando GNU Parallel's --pipe. Mis pruebas generalmente alcanzan un máximo de alrededor de 100 MB / s.

Su cuello de botella es más probable en GNU Paralelo: --pipeno es muy eficiente. --pipepart, sin embargo, es: Aquí puedo obtener del orden de 1 GB / s por núcleo de CPU.

Lamentablemente, existen algunas limitaciones en el uso --pipepart:

• El archivo debe ser buscable (es decir, sin tubería)
• Debe poder encontrar el inicio de un registro con --recstart / - recend (es decir, sin archivo comprimido)
• El número de línea es desconocido (por lo que no puede tener un registro de 4 líneas).

Ejemplo:

parallel --pipepart -a bigfile --block 100M grep somepattern

grep es muy efectivo: no tiene sentido ejecutarlo en paralelo. En su comando, solo la descompresión necesita más CPU, pero esto no puede ser paralelo.

Dividir la entrada por paralelo necesita más CPU que obtener líneas coincidentes por grep.

El cambio de situación si desea usar en lugar de grep algo que necesita mucha más CPU para cada línea, entonces el paralelo tendría más sentido.

Si desea acelerar esta operación, mire dónde hay cuellos de botella, probablemente sea descompresión (luego ayuda a usar otra herramienta de descompresión o mejor CPU) o - leer desde el disco (luego ayude a usar otra herramienta de descompresión o un mejor sistema de disco).

Según mi experiencia, a veces es mejor usar lzma (-2 por ejemplo) para comprimir / descomprimir archivos, tiene una compresión más alta que gzip, por lo que es mucho menos lo que se necesita leer en el disco y la velocidad es comparable.

La descompresión es el cuello de botella aquí. Si la descompresión no está paralelizada internamente, no la logrará usted mismo. Si tiene más de un trabajo como ese, entonces, por supuesto, ejecútelos en paralelo, pero su tubería por sí sola es difícil de paralelizar. Dividir una secuencia en secuencias paralelas casi nunca vale la pena, y puede ser muy doloroso con la sincronización y la fusión. A veces solo tiene que aceptar que múltiples núcleos no ayudarán con cada tarea que esté ejecutando.

En general, la paralelización en shell debería estar principalmente en el nivel de procesos independientes.