Comment utiliser GNU Parallel efficacement

Supposons que je veuille trouver toutes les correspondances dans un fichier texte compressé:

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

pv --rateutilisé ici pour mesurer le débit des tuyaux. Sur ma machine, c'est environ 420Mb / s (après décompression).

Maintenant j'essaye de faire du grep parallèle en utilisant GNU parallel.

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

Le débit est maintenant abaissé à ~ 260 Mo / s. Et ce qui est le plus intéressant parallel, c'est d'utiliser beaucoup de CPU. Plus que des grepprocessus (mais moins que gzcat).

EDIT 1 : J'ai essayé différentes tailles de blocs ( --block), ainsi que différentes valeurs pour -N/ -Loptions. Rien ne m'aide à ce stade.

Qu'est-ce que je fais mal?

Je suis vraiment surpris que vous obteniez 270 Mo / s en utilisant GNU Parallel's --pipe. Mes tests atteignent généralement un maximum d'environ 100 Mo / s.

Votre goulot d'étranglement est très probablement dans GNU Parallel: --pipen'est pas très efficace. --pipepart, cependant, est: Ici, je peux obtenir de l'ordre de 1 Go / s par cœur de processeur.

Malheureusement, il existe quelques limitations à l'utilisation --pipepart:

• Le fichier doit être recherché (c'est-à-dire sans pipe)
• Vous devez pouvoir trouver le début d'un enregistrement avec --recstart / - recend (c'est-à-dire pas de fichier compressé)
• Le numéro de ligne est inconnu (vous ne pouvez donc pas avoir un enregistrement de 4 lignes).

Exemple:

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

grep est très efficace - cela n'a aucun sens de l'exécuter en parallèle. Dans votre commande, seule la décompression a besoin de plus de cpu, mais cela ne peut pas être mis en parallèle.

Le fractionnement des entrées par parallèle nécessite plus de CPU que d'obtenir des lignes correspondantes par grep.

Changement de situation si vous souhaitez utiliser au lieu de grep quelque chose qui nécessite beaucoup plus de cpu pour chaque ligne - alors parallèle aurait plus de sens.

Si vous souhaitez accélérer cette opération - regardez où se trouvent les goulots d'étranglement - c'est probablement la décompression (puis aide à utiliser un autre outil de décompression ou un meilleur processeur) ou - la lecture à partir du disque (puis aide à utiliser un autre outil de décompression ou un meilleur système de disque).

D'après mon expérience - il est parfois préférable d'utiliser lzma (-2 par exemple) pour compresser / décompresser des fichiers - il a une compression plus élevée que gzip, donc beaucoup moins de données doivent être lues sur le disque et la vitesse est comparable.

La décompression est ici le goulot d'étranglement. Si la décompression n'est pas parallélisée en interne, vous n'y arriverez pas par vous-même. Si vous avez plus d'un travail comme celui-là, alors bien sûr, lancez-les en parallèle, mais votre pipeline en lui-même est difficile à paralléliser. La division d'un flux en flux parallèles n'en vaut presque jamais la peine et peut être très pénible avec la synchronisation et la fusion. Parfois, vous devez simplement accepter que plusieurs cœurs ne vous aideront pas pour chaque tâche que vous exécutez.

En général, la parallélisation en shell doit se faire principalement au niveau de processus indépendants.