bzip2 trop lent. Plusieurs cœurs sont disponibles
J'exécute cette commande:
pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2
Cela prend trop de temps. Je regarde les processus avec top. Le processus bzip2 prend environ 95% et postgres 5% d'un cœur. L'entrée wa est faible. Cela signifie que le disque n'est pas le goulot d'étranglement.
Que puis-je faire pour augmenter les performances?
Laissez peut-être bzip2 utiliser plus de cœurs. Les serveurs ont 16 cœurs.
Ou utiliser une alternative à bzip2?
Que puis-je faire pour augmenter les performances?
Il existe de nombreux algorithmes de compression et bzip2 Est l'un des plus lents. Plain gzip a tendance à être beaucoup plus rapide, à une compression généralement pas bien pire. Lorsque la vitesse est la plus importante, lzop est ma préférée. Mauvaise compression, mais oh si vite.
J'ai décidé de m'amuser et de comparer quelques algorithmes, y compris leurs implémentations parallèles. Le fichier d'entrée est la sortie de la commande pg_dumpall Sur mon poste de travail, un fichier SQL de 1913 Mo. Le matériel est un ancien i5 quadricœur. Les heures sont des heures d'horloge murale de la compression uniquement. Les implémentations parallèles sont définies pour utiliser les 4 cœurs. Tableau trié par vitesse de compression.
Algorithm Compressed size Compression Decompression
lzop 398MB 20.8% 4.2s 455.6MB/s 3.1s 617.3MB/s
lz4 416MB 21.7% 4.5s 424.2MB/s 1.6s 1181.3MB/s
brotli (q0) 307MB 16.1% 7.3s 262.1MB/s 4.9s 390.5MB/s
brotli (q1) 234MB 12.2% 8.7s 220.0MB/s 4.9s 390.5MB/s
zstd 266MB 13.9% 11.9s 161.1MB/s 3.5s 539.5MB/s
pigz (x4) 232MB 12.1% 13.1s 146.1MB/s 4.2s 455.6MB/s
gzip 232MB 12.1% 39.1s 48.9MB/s 9.2s 208.0MB/s
lbzip2 (x4) 188MB 9.9% 42.0s 45.6MB/s 13.2s 144.9MB/s
pbzip2 (x4) 189MB 9.9% 117.5s 16.3MB/s 20.1s 95.2MB/s
bzip2 189MB 9.9% 273.4s 7.0MB/s 42.8s 44.7MB/s
pixz (x4) 132MB 6.9% 456.3s 4.2MB/s 7.9s 242.2MB/s
xz 132MB 6.9% 1027.8s 1.9MB/s 17.3s 110.6MB/s
brotli (q11) 141MB 7.4% 4979.2s 0.4MB/s 3.6s 531.6MB/s
Si les 16 cœurs de votre serveur sont suffisamment inactifs pour que tous puissent être utilisés pour la compression, pbzip2 Vous donnera probablement une accélération très importante. Mais vous avez encore besoin de plus de vitesse et vous pouvez tolérer ~ 20% de fichiers plus gros, gzip est probablement votre meilleur choix.
Mise à jour: J'ai ajouté les résultats brotli (voir la réponse TOOGAMs) au tableau. brotlis Le paramètre de qualité de compression a un impact très important sur le taux de compression et la vitesse, j'ai donc ajouté trois paramètres (q0, q1 et q11). La valeur par défaut est q11, Mais elle est extrêmement lente et pire que xz. q1 Semble très bien cependant; le même taux de compression que gzip, mais 4 à 5 fois plus rapide!
Mise à jour: Ajouté lbzip2 (Voir le commentaire de gmathts) et zstd (le commentaire de Johnny) au tableau, et trié par vitesse de compression. lbzip2 Remet la famille bzip2 En marche en compressant trois fois plus vite que pbzip2 Avec un excellent taux de compression! zstd semble également raisonnable mais est battu par brotli (q1) à la fois en rapport et en vitesse.
Ma conclusion initiale que plain gzip est le meilleur pari commence à sembler presque stupide. Bien que pour l'ubiquité, il ne peut toujours pas être battu;)
Utilisez pbzip2.
Le manuel dit:
pbzip2 est une implémentation parallèle du compresseur de fichiers de tri de blocs bzip2 qui utilise pthreads et permet une accélération quasi linéaire sur les machines SMP. La sortie de cette version est entièrement compatible avec bzip2 v1.0.2 ou plus récent (c'est-à-dire: tout ce qui est compressé avec pbzip2 peut être décompressé avec bzip2).
Il détecte automatiquement le nombre de processeurs dont vous disposez et crée des threads en conséquence.
- Le brotli de Google est un format plus récent qui a récemment gagné en popularité dans les navigateurs, car il présente une compression impressionnante, une vitesse impressionnante et peut-être la combinaison/l'équilibre le plus impressionnant de ces deux fonctionnalités.
Quelques données:
Comparaison des algorithmes de compression Brotli, Deflate, Zopfli, LZMA, LZHAM et Bzip2
- par exemple, ce graphique rapportant des nombres montrant que Brotli est environ 6-14 plus rapide que Bzip2.
CanIUse.com: feature: brotli montre le support de Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (mais pas Opera Mini ou Microsoft Internet Explorer).
Comparaison: Brotli vs dégonflage vs zopfli vs lzma vs lzham vs bzip2
- Si vous recherchez la vitesse de compression, alors ce que vous cherchez, c'est quelles lignes sont plus à droite sur ce graphique. (Les entrées en haut de ce graphique montrent un taux de compression serré. Plus élevé = plus serré. Cependant, si la vitesse de compression est votre priorité, alors vous voudrez faire plus attention aux lignes qui atteignent plus à droite sur le graphique.)
- Le ZStandard de Facebook est une autre option, s'efforçant de réduire les bits mais également de se concentrer sur le stockage des données de manière à réduire les prédictions manquées, permettant ainsi une vitesse plus rapide. Sa page d'accueil est à: Compression de données plus petite et plus rapide avec ZStandard
- Lézard n'obtient pas un niveau de compression aussi élevé que Brotli ou ZStandard, mais peut être quelque peu proche dans le taux de compression, et être un peu plus rapide (au moins selon ce graphique = qui concerne la vitesse, bien que cela signale une décompression)
Vous n'avez pas mentionné de système d'exploitation. Si Windows, 7-Zip avec ZStandard (versions) est une version de 7-Zip qui a été modifiée pour prendre en charge l'utilisation de tous ces algorithmes.
Utilisez zstd . Si c'est assez bon pour Facebook, ça l'est probablement aussi pour vous.
Plus sérieusement, c'est en fait assez bon . Je l'utilise pour tout maintenant car cela fonctionne, et il vous permet d'échanger la vitesse pour un rapport à grande échelle (le plus souvent, la vitesse compte plus que la taille de toute façon car le stockage est bon marché, mais la vitesse est un goulot d'étranglement).
À des niveaux de compression qui atteignent une compression globale comparable à celle de bzip2, c'est beaucoup plus rapide, et si vous êtes prêt à payer un peu plus de temps CPU, vous pouvez presque obtenir des résultats similaires à LZMA (bien qu'alors il sera plus lent que bzip2). À des taux de compression légèrement inférieurs, il est beaucoup, beaucoup plus rapide que bzip2 ou toute autre alternative traditionnelle.
Maintenant, vous compressez un vidage SQL, ce qui est à peu près aussi embarrassant que compressé. Même les compresseurs les plus pauvres obtiennent de bons résultats sur ce type de données.
Vous pouvez donc exécuter zstd avec un niveau de compression inférieur, qui s'exécutera des dizaines de fois plus rapidement tout en atteignant 95 -99% la même compression sur ces données.
En prime, si vous le faites souvent et souhaitez investir un peu plus de temps, vous pouvez "entraîner" le compresseur zstd à l'avance, ce qui augmente à la fois le taux de compression et la vitesse. Notez que pour que la formation fonctionne bien, vous devrez lui fournir des enregistrements individuels, pas le tout. De la façon dont l'outil fonctionne, il attend de nombreux petits échantillons quelque peu similaires pour la formation, pas un énorme blob.
Il semble que l'ajustement (l'abaissement) de la taille du bloc puisse avoir un impact significatif sur le temps de compression.
Voici quelques résultats de l'expérience que j'ai faite sur ma machine. J'ai utilisé la commande time pour mesurer le temps d'exécution. input.txt est un fichier texte de ~ 250 Mo contenant des enregistrements json arbitraires.
Utilisation de la taille de bloc par défaut (la plus grande) (--best sélectionne simplement le comportement par défaut):
# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz
real 0m48.918s
user 0m48.397s
sys 0m0.767s
En utilisant la plus petite taille de bloc (--fast argument):
# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz
real 0m33.859s
user 0m33.571s
sys 0m0.741s
Ce fut une découverte un peu surprenante, étant donné que la documentation dit:
La vitesse de compression et de décompression n'est pratiquement pas affectée par la taille du bloc