Annonce
#1 Mon 18 January 2021 23:55
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 848
Décompression parallélisée des fichiers .7z
Le 7z que j'utilise sous Linux, n'est visiblement pas parallélisé. La décompression de fichiers prends un temps fou.
J'ai essayé diverses options (mal documentées), mais rien de trouvé de probant.
Cela m'a une fois de plus agacé hier en décompressant la BD Topo SQL/WGS84... et quand un truc m'agace, je contourne l'obstacle !
On peut demander à 7z de décompresser un seul fichier d'une archive, pourquoi ne pas le faire en parallèle ?
7z l archive.7z | grep ' \.\.\.\.A ' | sed 's/^.* //' | parallel -j 8 7z x -bd archive.7z {}
Explication:
- le premier 7z sort la liste du contenu de l'archive
- le grep ne converse que les lignes faisant référence à des fichiers
- le sed supprime le début de ligne jusqu'au dernier espace où commence le chemin d'accès du fichier
- on pipe ça à GNU parallel pour paralléliser (-j 8 = 8 threads)
- et 7z est appelé pour décompresser chaque fichier
Décompresser les archives des orthos HR va devenir un plaisir !
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#2 Tue 19 January 2021 01:28
- Shot2
- Participant actif
- Date d'inscription: 22 Jan 2020
- Messages: 112
Re: Décompression parallélisée des fichiers .7z
Il me semble que les archives 7zip de l'IGN sont solides - de prime abord j'aurais tendance à vouloir créer autant de threads qu'il y a de blocs contenant des fichiers à extraire, afin d'éviter de parcourir plusieurs fois un même bloc (fût-ce en parallèle).
edit : et même comme ça, ce serait semble-t-il suboptimal (certains fichiers étant à cheval sur plusieurs blocs).
edit² : il y a assurément de bonnes raisons à l'adoption du .7z (>4GB, multiplateforme, split-archive...), mais le choix de gros blocs + forte compression est un peu curieux.
Dernière modification par Shot2 (Tue 19 January 2021 01:45)
Hors ligne
#3 Tue 19 January 2021 11:26
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 848
Re: Décompression parallélisée des fichiers .7z
Rien de tel qu'un petit bench pour confirmer (ou pas) l'intérêt du procédé et les remarques de Shot2 à propos des blocs !
J'ai commencé avec une décompresion de la BDTopo SQL WGS84 qui fait 24Go en 7z (de et sur SSD):
- normale : 31', environ 12Mo/s en lecture, 70Mo/s en écriture... et pas forcément en même temps !
- parallélisée : 19'24s, pics en écriture à plus de 400Mo/s lors du plus fort parallélisme (SSD SATA limitant, je continuerai sur un NVMe)
Les petits fichiers sont rapidement décompressés, les plus gros prennent du temps, du coup il y a un maximum de gain lié au parallélisme au début.
L'idéal serait de lancer la décompression par taille de fichiers décroissante, pour être sûr que démarrer au plus tôt ceux qui prendrons le plus de temps et c'est d'autant plus valable qu'on n'a pas beaucoup de coeurs.
Pour faire ce tri, ajout d'un sed et d'un sort:
7z l archive.7z | grep ' \.\.\.\.A ' | sed 's/^.* \.\.\.\.A //' | sort -nr | sed 's/^.* //' | parallel -j 8 7z x -bd archive.7z {}
14'20" temps divisé par 2.
Le gain est-il supérieur sur les orthos où les fichiers sont de tailles similaires ?
Donc deuxième test, sur l'ortho HR du 91 (un peu plus de 8Go en 7z)...
- normale : 8'41
- parallèlisée : 7'
Les blocs sont effectivement limitant... ils font 2Go, le réglage correspondant au niveau de compression "normal" et donc les 200 dalles de cette ortho font que chaque bloc sera décompressé en moyenne 40 fois, ce qui occupe les coeurs de mes CPU pour pas grand chose.
Donc... j'ai recompressé ces orthos avec le niveau de compression "fast" qui a des blocs de 128Mo
Première surprise : l'archive est plus petite (de 1%) !
Deuxième surprise à la décompression :
- normale : 1' (plus de 8x plus rapide)
- parallélisée : 5" <- oui 5 SECONDES = 100 fois plus rapide que la décompression normale du 7z d'origine
CONCLUSION:
Merci d'avance aux empaqueteurs de données 7z de l'IGN de rajouter par exemple l'option -mx=3 ou -ms=128m
Sur des données peu compressibles, on gagne marginalement en taille d'archive et énormément en temps de décompression.
Sur des données très compressibles,
Une doc complète sur les multiples options de 7z : https://documentation.help/7-Zip/method.htm
Encore un test en cours en recompressant la BDTopo avec -ms=128m
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
#4 Tue 19 January 2021 11:44
- Shot2
- Participant actif
- Date d'inscription: 22 Jan 2020
- Messages: 112
Re: Décompression parallélisée des fichiers .7z
Ou plus simple : laisser la compression normale (-mx5, perte de temps pour du raster déjà compressé mais efficace pour grapiller un peu de volume sur .sql...) tout en désactivant la compression solide (-ms=off). Accès direct à chaque fichier, un seul fichier corrompu en cas de bit pourri, déduplication facilitée entre archives stockant un même fichier...
En bonus si on est joueur : compression différente selon le type de fichier (p.ex. "store" pour le raster compressé, puis "maximum" pour le reste, pdf shp sql etc.) mais ça complique la procédure.
Dernière modification par Shot2 (Tue 19 January 2021 11:47)
Hors ligne
#5 Tue 19 January 2021 19:10
- cquest
- Participant assidu
- Date d'inscription: 6 Jan 2013
- Messages: 848
Re: Décompression parallélisée des fichiers .7z
Résultat de la BDTopo SQL, non "solide", donc sans les blocs... 14' à décompresser, donc identique et ça correspond visiblement au fichier le plus long à décompresser seul.
Christian Quest - https://amicale.net/@cquest sur Mastodon (terminé twitter/X)
Membre fondateur et porte parole d'OpenStreetMap France
A l'origine de opendatArchives, OpenEventDatabase
Hors ligne
