bzip2 quá chậm. Nhiều lõi có sẵn

Tôi đang chạy lệnh này:

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

Nó lâu quá. Tôi nhìn vào các quá trình với top. Quá trình bzip2 chiếm khoảng 95% và postgres 5% của một lõi. Các wamục nhập thấp. Điều này có nghĩa là đĩa không phải là nút cổ chai.

Tôi có thể làm gì để tăng hiệu suất?

Có thể để bzip2 sử dụng nhiều lõi hơn. Các máy chủ có 16 lõi.

Hoặc sử dụng một thay thế cho bzip2?

Tôi có thể làm gì để tăng hiệu suất?

Có nhiều thuật toán nén xung quanh, và bzip2là một trong những thuật toán chậm hơn. Đồng bằng gzipcó xu hướng nhanh hơn đáng kể, thường không nén nhiều hơn. Khi tốc độ là quan trọng nhất, lzoplà yêu thích của tôi. Nén kém, nhưng oh quá nhanh.

Tôi quyết định có một số niềm vui và so sánh một vài thuật toán, bao gồm cả việc triển khai song song của chúng. Tệp đầu vào là đầu ra của pg_dumpalllệnh trên máy trạm của tôi, tệp SQL 1913 MB. Phần cứng là một i5 lõi tứ cũ hơn. Thời gian là thời gian đồng hồ treo tường của chỉ nén. Việc triển khai song song được thiết lập để sử dụng cả 4 lõi. Bảng được sắp xếp theo tốc độ nén.

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

Nếu 16 lõi của máy chủ của bạn không đủ để tất cả có thể được sử dụng để nén, pbzip2có thể sẽ giúp bạn tăng tốc rất đáng kể. Nhưng bạn cần nhiều tốc độ hơn và bạn có thể chịu được các tệp lớn hơn ~ 20%, gzipcó lẽ là lựa chọn tốt nhất của bạn.

Cập nhật: Tôi đã thêm brotli(xem câu trả lời của QUÁN) vào bảng. brotlis cài đặt chất lượng nén có tác động rất lớn về tỷ lệ nén và tốc độ, vì vậy tôi thêm ba thiết lập ( q0, q1và q11). Mặc định là q11, nhưng nó cực kỳ chậm, và vẫn còn tệ hơn xz. q1trông rất tốt mặc dù; tỷ lệ nén tương tự gzip, nhưng nhanh gấp 4-5 lần!

Cập nhật: Đã thêm lbzip2(xem bình luận của gmathts) và zstd(bình luận của Johnny) vào bảng và sắp xếp nó theo tốc độ nén. lbzip2đưa bzip2gia đình trở lại hoạt động bằng cách nén nhanh gấp ba lần pbzip2với tỷ lệ nén tuyệt vời! zstdcũng có vẻ hợp lý nhưng được đánh bại bởi brotli (q1)cả tỷ lệ và tốc độ.

Kết luận ban đầu của tôi rằng đơn giản gziplà đặt cược tốt nhất đang bắt đầu trông gần như ngớ ngẩn. Mặc dù đối với sự phổ biến, nó vẫn không thể bị đánh bại;)

Sử dụng pbzip2.

Các tay nói:

pbzip2 là một triển khai song song của trình nén tệp sắp xếp khối bzip2 sử dụng pthreads và đạt được tốc độ gần tuyến tính trên các máy SMP. Đầu ra của phiên bản này hoàn toàn tương thích với bzip2 v1.0.2 hoặc mới hơn (nghĩa là: mọi thứ được nén bằng pbzip2 đều có thể được giải nén bằng bzip2).

Nó tự động phát hiện số lượng bộ xử lý bạn có và tạo các luồng tương ứng.

• Brotli của Google là một định dạng mới hơn đã nhận được một số hỗ trợ rộng rãi trong các trình duyệt gần đây, vì nó có một số nén ấn tượng, một số tốc độ ấn tượng và có lẽ là sự kết hợp / cân bằng ấn tượng nhất của cả hai tính năng này.

  Một số dữ liệu:

  So sánh các thuật toán nén Brotli, Deflate, Zopfli, LZMA, LZHAM và Bzip2

  • ví dụ: biểu đồ này báo cáo các số hiển thị Brotli nhanh hơn khoảng 6-14 so với Bzip2.

  CanIUse.com: tính năng: brotli hiển thị hỗ trợ bởi Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (nhưng không phải Opera Mini hoặc Microsoft Internet Explorer).

  So sánh: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2

  • Nếu bạn đang tìm kiếm tốc độ nén, thì điều bạn đang tìm kiếm là dòng nào tiếp tục đúng trên biểu đồ này. (Các mục ở trên cùng của biểu đồ này hiển thị tỷ lệ nén chặt chẽ. Cao hơn = chặt hơn. Tuy nhiên, nếu tốc độ nén là ưu tiên của bạn, thì bạn sẽ muốn chú ý nhiều hơn đến những dòng nào tiếp cận ngay trên biểu đồ.)
  So sánh: Tỷ lệ nén so với tốc độ nén cho các phương pháp tiêu chuẩn 7-Zip

• ZSt Chuẩn của Facebook là một tùy chọn khác, cố gắng giảm bit nhưng cũng tập trung cao độ vào việc lưu trữ dữ liệu theo cách giảm dự đoán bị bỏ lỡ, do đó cho phép tốc độ nhanh hơn. Trang chủ của nó là: Nén dữ liệu nhỏ hơn và nhanh hơn với ZSt Chuẩn
• Lizard không có độ nén khá cao như Brotli hoặc ZSt Chuẩn, nhưng có thể hơi gần với tỷ lệ nén và nhanh hơn một chút (ít nhất là theo biểu đồ này về tốc độ, mặc dù đó là báo cáo giải nén)

Bạn đã không đề cập đến một hệ điều hành. Nếu Windows, 7-Zip với ZSt Chuẩn (Phát hành) là phiên bản 7-Zip đã được sửa đổi để cung cấp hỗ trợ cho việc sử dụng tất cả các thuật toán này.

Sử dụng zstd . Nếu nó đủ tốt cho Facebook, có lẽ nó cũng đủ tốt cho bạn.

Trên một lưu ý nghiêm trọng hơn, nó thực sự khá tốt . Tôi sử dụng nó cho mọi thứ bây giờ vì nó chỉ hoạt động và nó cho phép bạn trao đổi tốc độ theo tỷ lệ trên quy mô lớn (thông thường, tốc độ quan trọng hơn kích thước dù sao vì lưu trữ rẻ, nhưng tốc độ là một nút cổ chai).
Ở các mức nén đạt được mức nén tổng thể tương đương như bzip2, nó nhanh hơn đáng kể và nếu bạn sẵn sàng trả thêm một chút thời gian CPU, bạn gần như có thể đạt được kết quả tương tự như LZMA (mặc dù sau đó nó sẽ chậm hơn bzip2). Tại tỷ lệ nén sligthly tồi tệ hơn, nó là nhiều, nhiều hơn nhanh hơn bzip2 hoặc bất kỳ thay thế chủ đạo khác.

Bây giờ, bạn đang nén một kết xuất SQL, điều này chỉ đơn giản là tầm thường đáng xấu hổ để nén như nó có thể. Ngay cả những máy nén kém nhất cũng đạt điểm cao về loại dữ liệu đó.
Vì vậy, bạn có thể chạy zstdvới mức nén thấp hơn, sẽ chạy nhanh hơn hàng chục lần mà vẫn đạt được mức nén 95-99% tương tự trên dữ liệu đó.

Như một phần thưởng, nếu bạn sẽ làm việc này thường xuyên và muốn đầu tư thêm thời gian, bạn có thể "đào tạo" zstdmáy nén trước thời hạn, điều này làm tăng cả tỷ lệ nén và tốc độ. Lưu ý rằng để đào tạo để hoạt động tốt, bạn sẽ cần phải cung cấp cho nó hồ sơ cá nhân, không phải toàn bộ. Cách thức hoạt động của công cụ này, nó mong đợi nhiều mẫu nhỏ và hơi giống nhau để đào tạo, không phải là một đốm lớn.

Có vẻ như điều chỉnh (hạ thấp) kích thước khối có thể có tác động đáng kể đến thời gian nén.

Dưới đây là một số kết quả của thí nghiệm tôi đã làm trên máy của mình. Tôi đã sử dụng timelệnh để đo thời gian thực hiện. input.txtlà một tệp văn bản ~ 250mb chứa các bản ghi json tùy ý.

Sử dụng kích thước khối mặc định (lớn nhất) ( --bestchỉ chọn hành vi mặc định):

# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

Sử dụng kích thước khối nhỏ nhất ( --fastđối số):

# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

Đây là một khám phá hơi ngạc nhiên, vì xét rằng tài liệu nói:

Tốc độ nén và giải nén hầu như không bị ảnh hưởng bởi kích thước khối