bzip2 terlalu lambat. Beberapa core tersedia

31

Saya menjalankan perintah ini:

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

Itu terlalu lama. Saya melihat proses dengan top. Proses bzip2 memakan waktu sekitar 95% dan postgres 5% dari satu inti. The waentri rendah. Ini berarti disk bukanlah hambatan.

Apa yang dapat saya lakukan untuk meningkatkan kinerja?

Mungkin biarkan bzip2 menggunakan lebih banyak core. Server memiliki 16 core.

Atau gunakan alternatif untuk bzip2?

Apa yang dapat saya lakukan untuk meningkatkan kinerja?

performance postgresql gzip

— guettli
sumber

8

Kecuali jika Anda membutuhkan bzip2 untuk alasan warisan, sudah pengalaman pribadi saya bahwa xz memberikan kompresi / waktu yang lebih baik daripada bzip2. Ini juga di-threaded jika Anda mendapatkan program yang cukup baru, dan ini memungkinkan Anda meningkatkan skala waktu dan penggunaan memori dari gzipish hingga masif tergantung pada apa yang Anda inginkan.

— Perkins

6

"pigz" adalah pilihan lain - ini menghasilkan keluaran gzip daripada keluaran bzip2. Dan pada dasarnya semuanya mengerti gzip.

— Criggie

Anda dapat mencoba mengenkripsi secara simetris dengan GnuPG dengan kompresi bzip2; tampaknya sangat cepat dibandingkan dengan hanya mengompresnya, untuk beberapa alasan yang tidak diketahui, bahkan dengan tingkat kompresi tertinggi. Mungkin saja algoritmanya bisa lebih cepat daripada efisiensi program kompresi reguler saya, yang berbasis GUI.

— Shule

2

Anda belum menyatakan persyaratan algoritme alternatif Anda. Bzip2 dapat dipisahkan. Apakah itu penting bagi Anda?

— Martin Smith

7

" Apa yang bisa saya lakukan untuk meningkatkan kinerja? " - tidak mengompresnya? Anda tidak benar-benar mengatakan bahwa Anda membutuhkannya dikompresi, dan tidak melakukan pekerjaan selalu lebih cepat daripada melakukan pekerjaan. Buat disk bottleneck.

— TessellatingHeckler

49

Ada banyak algoritma kompresi di sekitar, dan bzip2merupakan salah satu yang lebih lambat. Plain gzipcenderung lebih cepat secara signifikan, biasanya kompresi tidak jauh lebih buruk. Ketika kecepatan adalah yang paling penting, lzopadalah favorit saya. Kompresi yang buruk, tapi oh begitu cepat.

Saya memutuskan untuk bersenang-senang dan membandingkan beberapa algoritma, termasuk implementasi paralel mereka. File input adalah output dari pg_dumpallperintah di workstation saya, file SQL 1913 MB. Perangkat kerasnya adalah quad-core i5 yang lebih lama. Waktu adalah waktu dinding-jam hanya kompresi. Implementasi paralel diatur untuk menggunakan semua 4 core. Tabel diurutkan berdasarkan kecepatan kompresi.

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

Jika 16 core server Anda cukup siaga sehingga semua dapat digunakan untuk kompresi, pbzip2mungkin akan memberi Anda kecepatan yang sangat signifikan. Tetapi Anda masih membutuhkan kecepatan lebih dan Anda dapat mentolerir ~ 20% file yang lebih besar, gzipmungkin merupakan taruhan terbaik Anda.

Pembaruan: Saya menambahkan brotli(lihat jawaban TOOGAM) ke tabel. brotlis pengaturan kualitas kompresi memiliki dampak yang sangat besar pada rasio kompresi dan kecepatan, jadi saya menambahkan tiga pengaturan ( q0, q1, dan q11). Standarnya adalah q11, tetapi sangat lambat, dan masih lebih buruk daripada xz. q1terlihat sangat bagus; rasio kompresi yang sama seperti gzip, tetapi 4-5 kali lebih cepat!

Perbarui: Ditambahkan lbzip2(lihat komentar gmathts) dan zstd(komentar Johnny) ke tabel, dan urutkan berdasarkan kecepatan kompresi. lbzip2mengembalikan bzip2keluarga dalam menjalankan dengan mengompres tiga kali lebih cepat pbzip2dengan rasio kompresi yang hebat! zstdjuga terlihat masuk akal tetapi dikalahkan oleh brotli (q1)rasio dan kecepatan.

Kesimpulan asli saya bahwa polos gzipadalah taruhan terbaik mulai terlihat hampir konyol. Meskipun untuk mana-mana, itu masih tidak dapat dikalahkan;)

— marcelm
sumber

1

Untuk tabel ish serupa dengan algoritma yang jauh lebih banyak, lihat mattmahoney.net/dc/text.html .

— Dougal

1

@Dougal Cukup adil. Tes saya pada data yang sama seperti OP sekalipun ( pg_dumpalloutput), jadi mungkin sedikit lebih representatif :)

— marcelm

1

zstd adalah satu lagi yang hilang dari tabel - untuk mengompresi file log kami, saya menemukan bahwa proses zstd inti tunggal mengungguli 16 inti pbzip2 dengan rasio kompresi yang sebanding.

— Johnny

1

lz4lzopomong-omong sedikit lebih cepat dan lebih efisien daripada , omong-omong. Ini menggunakan lebih banyak RAM, yang relevan dalam sistem embedded.

— Daniel B

1

Jika Anda ingin menguji versi multi-utas, Anda bisa mencobanya zstd -T4juga. Untuk pengaturan yang sangat cepat, Anda dapat mencoba zstd -T4 -1, sebagai zstddefault -3, yang mungkin merupakan pengaturan yang Anda uji.

— Cyan

37

Gunakan pbzip2.

The pengguna mengatakan:

pbzip2 adalah implementasi paralel dari kompresor blok-sortir file bzip2 yang menggunakan pthreads dan mencapai speedup dekat-linear pada mesin SMP. Output dari versi ini sepenuhnya kompatibel dengan bzip2 v1.0.2 atau lebih baru (yaitu: apa pun yang dikompresi dengan pbzip2 dapat didekompresi dengan bzip2).

Ini secara otomatis mendeteksi jumlah prosesor yang Anda miliki dan membuat utas yang sesuai.

— ToriumBR
sumber

Tidak apa-apa jika Anda mengompres file, ini bekerja sangat buruk melalui pipa

— camelccc

@camelccc Mengapa Anda mengatakan itu? Saya tidak menemukan itu menjadi masalahnya, sama sekali. Anda membutuhkan produsen cepat atau buffer yang besar pada pipa di depannya untuk kinerja yang optimal, tapi itu sama-sama benar pixzdan pigzpada pipa juga.

— Michael - sqlbot

Tergantung seberapa besar kompresinya. Jika Anda memiliki buffer yang besar tidak apa-apa seperti yang Anda katakan, jika Anda menyalurkan sesuatu yang jauh lebih besar daripada ram fisik, saya telah menemukan banyak hal bisa menjadi lebih menarik. Seperti yang Anda katakan mungkin benar untuk semua algoritma kompresi.

— camelccc

4

bzip2 dapat menggunakan sedikit ram, jadi menjalankan 16 pekerja bzip sekaligus dapat mengkonsumsi ram non-sepele, lebih dari 1GB. BTW, lbzip2tampaknya memberikan kecepatan yang lebih baik, penggunaan memori dan kompresi yang sedikit lebih baik daripada pbzip2. Ada tolok ukur di sini: vbtechsupport.com/1614

— gmatht

@ gmatht lbzip2terlihat bagus! Saya menambahkannya ke jawaban saya :)

— marcelm

8

Google brotli adalah format yang lebih baru yang telah memperoleh beberapa dukungan luas dalam browser baru-baru ini, karena memiliki beberapa kompresi yang mengesankan, beberapa kecepatan yang mengesankan, dan mungkin kombinasi / keseimbangan yang paling mengesankan dari kedua fitur tersebut.

Beberapa data:

Perbandingan Algoritma Kompresi Brotli, Deflate, Zopfli, LZMA, LZHAM dan Bzip2
- misalnya, angka pelaporan grafik ini menunjukkan Brotli kira-kira 6-14 lebih cepat dari Bzip2.
CanIUse.com: fitur: brotli menunjukkan dukungan oleh Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (tetapi bukan Opera Mini atau Microsoft Internet Explorer).

Perbandingan: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2
- Jika Anda mencari kecepatan kompresi, maka yang Anda cari adalah garis mana yang lebih jauh pada grafik ini. (Entri ke atas bagan ini menunjukkan rasio kompresi yang ketat. Lebih tinggi = lebih ketat. Namun, jika kecepatan kompresi adalah prioritas Anda, maka Anda harus lebih memperhatikan garis apa yang mencapai lebih jauh tepat pada grafik.)
Perbandingan: Rasio Kompresi vs Kecepatan Kompresi untuk Metode ZStandard 7-Zip
ZStandard Facebook adalah pilihan lain, berusaha untuk mengurangi bit tetapi juga memiliki fokus tinggi untuk menyimpan data dengan cara yang mengurangi prediksi yang terlewat, sehingga memungkinkan kecepatan yang lebih cepat. Halaman beranda adalah di: Kompresi data lebih kecil dan lebih cepat dengan ZStandard
Lizard tidak mendapatkan kompresi yang cukup tinggi seperti Brotli atau ZStandard, tetapi mungkin agak dekat dalam rasio kompresi, dan menjadi sedikit lebih cepat (setidaknya menurut bagan ini tentang kecepatan, walaupun itu melaporkan dekompresi)

Anda tidak menyebutkan sistem operasi. Jika Windows, 7-Zip dengan ZStandard (Rilis) adalah versi 7-Zip yang telah dimodifikasi untuk memberikan dukungan untuk menggunakan semua algoritma ini.

— TOOGAM
sumber

Menarik, saya pernah mendengar brotlisebelumnya, tetapi saya lupa tentang itu. Saya menambahkannya ke tabel tolok ukur dalam jawaban saya! Saya sebenarnya sedikit kecewa dengan kinerjanya, kecuali pada pengaturan kualitas 1, di mana ia memberikan rasio kompresi yang sama seperti gzippada kecepatan yang jauh lebih tinggi.

— marcelm

2

Gunakan zstd . Jika itu cukup baik untuk Facebook, itu mungkin cukup baik untuk Anda juga.

Pada catatan yang lebih serius, sebenarnya cukup bagus . Saya menggunakannya untuk semuanya sekarang karena itu hanya berfungsi, dan memungkinkan Anda bertukar kecepatan untuk rasio dalam skala besar (paling sering, kecepatan lebih penting daripada ukuran karena penyimpanan murah, tetapi kecepatan adalah hambatan).
Pada level kompresi yang mencapai kompresi keseluruhan yang sebanding dengan bzip2, ini secara signifikan lebih cepat, dan jika Anda bersedia membayar ekstra dalam waktu CPU, Anda hampir dapat mencapai hasil yang mirip dengan LZMA (walaupun kemudian akan lebih lambat daripada bzip2). Pada rasio kompresi yang sedikit lebih buruk, ini jauh, jauh lebih cepat daripada bzip2 atau alternatif utama lainnya.

Sekarang, Anda mengompresi dump SQL, yang sepele memalukan untuk kompres seperti itu. Bahkan kompresor termiskin mendapat skor bagus pada data semacam itu.
Jadi Anda bisa menjalankan zstddengan tingkat kompresi yang lebih rendah, yang akan berjalan puluhan kali lebih cepat dan masih mencapai 95-99% kompresi yang sama pada data itu.

Sebagai bonus, jika Anda akan sering melakukan ini dan ingin menginvestasikan waktu ekstra, Anda dapat "melatih" zstdkompresor sebelumnya, yang meningkatkan rasio kompresi dan kecepatan. Perhatikan bahwa agar pelatihan berjalan dengan baik, Anda harus memberinya catatan individual, bukan semuanya. Cara alat ini bekerja, ia mengharapkan banyak sampel kecil dan agak mirip untuk pelatihan, bukan satu gumpalan besar.

— Damon
sumber

lebih baik lagi, gunakan pzstd (versi paralel) pada mesin multicore

— borowis

1

Sepertinya menyesuaikan (menurunkan) ukuran blok dapat berdampak signifikan pada waktu kompresi.

Berikut adalah beberapa hasil percobaan yang saya lakukan pada mesin saya. Saya menggunakan timeperintah untuk mengukur waktu eksekusi. input.txtadalah file teks ~ 250MB yang berisi catatan json sewenang-wenang.

Menggunakan ukuran blok default (terbesar) ( --besthanya memilih perilaku default):

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

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

Menggunakan ukuran blok terkecil ( --fastargumen):

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

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

Ini adalah penemuan yang agak mengejutkan, mengingat dokumen itu mengatakan:

Kecepatan kompresi dan dekompresi secara virtual tidak terpengaruh oleh ukuran blok

— Jakub Kukul
sumber

Favorit saya saat ini adalah pbzip2. Sudahkah Anda mencoba ini juga? Pertanyaan ini adalah tentang lingkungan di mana 16 core tersedia.

— guettli

@guettli sayangnya saya harus tetap menggunakan bzip. Saya menggunakannya untuk pekerjaan Hadoop dan bzip adalah salah satu kompresi bawaan di sana. Jadi dengan cara itu sudah diparalelkan.

— Jakub Kukul