bzip2太慢了。多核可用

我正在執行這個命令：

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

時間太長了。我用top. bzip2 程序大約佔一個核心的 95%，postgres 佔 5%。入口wa很低。這意味著磁碟不是瓶頸。

我可以做些什麼來提高性能？

也許讓 bzip2 使用更多的核心。伺服器有 16 個核心。

或者使用 bzip2 的替代品？

我可以做些什麼來提高性能？

周圍有很多壓縮算法，並且bzip2是較慢的算法之一。普通gzip的往往要快得多，通常壓縮效果不會差很多。當速度是最重要的時候，lzop是我最喜歡的。壓縮很差，但是太快了。

我決定找點樂子，比較一些算法，包括它們的並行實現。輸入文件是pg_dumpall我工作站上命令的輸出，一個 1913 MB 的 SQL 文件。硬體是較舊的四核 i5。時間是僅壓縮的掛鐘時間。並行實現設置為使用所有 4 個核心。表按壓縮速度排序。

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

如果您的伺服器的 16 個核心足夠空閒，所有核心都可以用於壓縮，pbzip2那麼可能會給您帶來非常顯著的加速。但是您仍然需要更高的速度，並且您可以容忍大約 20% 的文件，gzip這可能是您最好的選擇。

**更新：**我brotli在表格中添加了（參見 TOOGAMs 答案）結果。brotlis 壓縮質量設置對壓縮比和速度的影響非常大，所以我添加了三個設置（q0、q1和q11）。預設值為q11，但它非常慢，並且仍然比xz. q1不過看起來很不錯；壓縮比相同gzip，但速度快 4-5 倍！

更新：lbzip2將（見 gmathts 評論）和（zstdJohnny 的評論）添加到表中，並按壓縮速度對其進行排序。以三倍的壓縮速度，以出色的壓縮比，lbzip2讓家人重回正軌！看起來也很合理，但在比例和速度上都被擊敗了。bzip2``pbzip2``zstd``brotli (q1)

我最初的結論是平原gzip是最好的選擇，這開始看起來幾乎是愚蠢的。雖然無處不在，但它仍然無法被擊敗；）

引用自：https://serverfault.com/questions/872749