bzip2 çok yavaş. Birden fazla çekirdek kullanılabilir

31

Bu komutu çalıştırıyorum:

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

Bayağı uzun sürer. Süreçlere bakıyorum top. Bzip2 işlemi yaklaşık% 95 alır ve bir çekirdeğin% 5'ini verir. waGiriş düşüktür. Bu, diskin tıkanıklık olmadığı anlamına gelir.

Performansı arttırmak için ne yapabilirim?

Belki bzip2'nin daha fazla çekirdek kullanmasına izin verin. Sunucuların 16 çekirdeği var.

Veya bzip2'ye alternatif mi kullanıyorsunuz?

Performansı arttırmak için ne yapabilirim?

performance postgresql gzip

— guettli
kaynak

8

Eski nedenlerle bzip2'ye ihtiyacınız olmadığı sürece, xz'in bzip2'den daha iyi sıkıştırma / zaman verdiği kişisel deneyimim oldu. Yeterince yeni bir program alırsanız aynı zamanda iş parçacıklıdır ve istediğiniz zamana bağlı olarak zaman ve bellek kullanımını gzipish'ten masiflere kadar ölçeklendirmenize olanak tanır.

— Perkins,

6

"pigz" başka bir seçenektir - bzip2 çıkışı yerine gzip çıktısı üretir. Ve temelde her şey gzip'i anlar.

— Criggie

Simetrik olarak bnuip2 sıkıştırmalı GnuPG ile şifrelemeyi deneyebilirsiniz; bilinmeyen bir nedenden ötürü, en yüksek sıkıştırma seviyesinde bile, sadece sıkıştırmayla karşılaştırıldığında şaşırtıcı derecede hızlı görünüyor. Algoritmanın, GUI tabanlı düzenli sıkıştırma programımın verimliliğinden daha hızlı olması mümkündür.

— Shule

2

Alternatif algoritmanızın gerekliliklerini belirtmediniz. Bzip2 ayrılabilir. Bu senin için önemli mi?

— Martin Smith,

7

" Performansı artırmak için ne yapabilirim? " - sıkıştırmayın mı? Aslında sıkıştırılmaya ihtiyacınız olduğunu söylemiyorsunuz ve iş yapmamak iş yapmaktan her zaman daha hızlı. Diski tıkanıklığı açın.

— TessellatingHeckler

49

Etrafında birçok sıkıştırma algoritması vardır ve bzip2en yavaşlarından biridir. Düz gzip, genellikle çok daha kötü olmayan bir sıkıştırma durumunda, çok daha hızlı olma eğilimindedir. Hız en önemli olduğunda lzop, favorim. Zayıf sıkıştırma, ama oh çok hızlı.

Paralel uygulamaları da dahil olmak üzere biraz eğlenmeye ve birkaç algoritmayı karşılaştırmaya karar verdim. Giriş dosyası, pg_dumpalliş istasyonumdaki bir 1913 MB SQL dosyası olan komutun çıktısıdır . Donanım eski bir dört çekirdekli i5. Zamanlar sadece sıkıştırmanın duvar saatidir. Paralel uygulamalar, tüm 4 çekirdeği kullanacak şekilde ayarlanmıştır. Tablo sıkıştırma hızına göre sıralanır.

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

Sunucunuzun 16 çekirdeği, tümü sıkıştırma için kullanılabilecek kadar boşta ise pbzip2, muhtemelen size çok önemli bir hızlanma sağlayacaktır. Ancak hala daha fazla hıza ihtiyacınız var ve ~% 20 daha büyük dosyalara katlanabilirsiniz gzip, muhtemelen en iyi seçeneğiniz budur.

Güncelleme:brotli Tabloya sonuçları ekledim (TOOGAM'ın cevabına bakınız). brotliBen üç ayar eklendi böylece s sıkıştırma kalitesi ayarı, sıkıştırma oranı ve hız üzerinde çok büyük bir etkisi vardır ( q0, q1ve q11). Varsayılan q11, ancak son derece yavaş ve hala daha kötü xz. q1olsa çok iyi görünüyor; aynı sıkıştırma oranı gzip, ancak 4-5 kat daha hızlı!

Güncelleme:lbzip2 Tabloya eklenmiş (bkz. Gmathts yorum) ve zstd(Johnny'nin yorumu) ve sıkıştırma hızına göre sıraladı. Sıkıştırma oranıyla üç kat daha hızlı baskı lbzip2yaparak bzip2aileyi tekrar koşuya sokar pbzip2! zstdAyrıca makul görünüyor ama brotli (q1)hem oran hem de hız ile yeniliyor.

Orijinal sonucum ova gzipen iyi bahis olduğu sonucuna göre aptalca görünmeye başlıyor. Her yerde olmasına rağmen, yine de yenemezsin;)

— marcelm
kaynak

1

Çok daha fazla algoritmaya sahip benzer bir tablo için, mattmahoney.net/dc/text.html adresini ziyaret edin .

— Dougal

1

@Dougal Fuarı yeterince. Testim OP ile benzer verilere rağmen (açık pg_dumpallbiraz daha temsili :) muhtemelen bu yüzden, çıkış)

— marcelm

1

zstd, tablodaki eksik bir diğeridir - log dosyalarımızı sıkıştırmak için, tek bir çekirdek zstd işleminin, benzer sıkıştırma oranlarına sahip 16 çekirdek pbzip2'den daha iyi performans gösterdiğini gördüm.

— Johnny,

1

lz4bu arada slighty, daha hızlı ve daha verimli lzop. Gömülü sistemlerde ilgili olsa da, daha fazla RAM kullanır.

— Daniel B

1

Çok iş parçacıklı sürümleri denemek istiyorsanız, siz de deneyebilirsiniz zstd -T4. Çok hızlı ayarlar için deneyebileceğiniz zstd -T4 -1gibi zstdhiç varsayılan -3sen test ayar muhtemelen olan.

— Camgöbeği

37

Pbzip2'yi kullanın.

Manuel diyor ki:

pbzip2, SMP makinelerinde pthreads kullanan ve doğrusalya yakın hızlanma sağlayan bzip2 blok sıralama dosya kompresörünün paralel bir uygulamasıdır. Bu sürümün çıktısı bzip2 v1.0.2 veya daha yenisiyle tam uyumludur (yani: pbzip2 ile sıkıştırılmış herhangi bir şey bzip2 ile açılabilir).

Sahip olduğunuz işlemci sayısını otomatik olarak algılar ve buna göre iş parçacığı oluşturur.

— ThoriumBR
kaynak

Bir dosyayı sıkıştırıyorsanız sorun değil, bu korkunç olsa da bir borudan çalışıyor

— camelccc

@ camelccc Neden böyle söylüyorsun? Bunu hiç de böyle bulmuyorum. Bir fast yapımcı veya en iyi performans için önündeki borunun üzerinde büyük bir tampona ihtiyaç, ama bu aynı derecede doğrudur pixzve pigzbir boruya de.

— Michael - sqlbot

Sıkıştırtığı şeyin ne kadar büyük olduğuna bağlı. Büyük bir tampon belleğiniz varsa, söylediğiniz gibi sorun yok, fiziksel koçtan çok daha büyük bir şeyi kullanıyorsanız, işlerin daha ilginç hale gelebileceğini öğrendim. Dediğiniz gibi herhangi bir sıkıştırma algoritması için muhtemelen doğrudur.

— camelccc

4

bzip2 adil bir miktar ram kullanabilir, bu nedenle bir seferde 16 bzip çalışanı çalıştırmak 1GB'ın üzerinde önemsiz olmayan bir koç tüketebilir. Btw, lbzip2daha iyi hız, bellek kullanımı ve biraz daha iyi sıkıştırma vermiş gibi görünüyor pbzip2. Burada kriterler var: vbtechsupport.com/1614

— gmatht

@gmatht lbzip2güzel görünüyor! Cevabımı ekledim :)

— marcelm

8

Google'ın brotli'si, son zamanlarda tarayıcılarda geniş bir destek alan, daha etkileyici bir sıkıştırma, etkileyici bir hız ve bu özelliklerin her ikisinin de en etkileyici kombinasyon / dengesi olduğundan, daha yeni bir formattır.

Birkaç veri:

Brotli, Deflate, Zopfli, LZMA, LZHAM ve Bzip2 Sıkıştırma Algoritmalarının Karşılaştırılması
- örneğin, bu çizelge Brotli'yi Bzip2'den yaklaşık 6-14 daha hızlı olduğunu gösteren rakamları bildirmektedir.
CanIUse.com: özelliği: brotli , Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (Opera Mini veya Microsoft Internet Explorer değil) tarafından verilen desteği gösterir.

Karşılaştırma: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2
- Sıkıştırma hızı arıyorsanız, aradığınız şey bu tabloda daha doğru olan satırlardır. (Bu tablonun üstündeki girişler sıkı sıkıştırma oranını gösterir. Daha yüksek = daha sıkı. Ancak, sıkıştırma hızı önceliğiniz ise, grafikte hangi çizgilerin daha fazla ulaştığına daha fazla dikkat etmek istersiniz.)
Karşılaştırma: Sıkıştırma Oranı - 7-Zip ZStandard Yöntemler için Sıkıştırma Hızı
Facebook'un ZStandard'ı, bitleri azaltmak için çabalamakla kalmayıp, aynı zamanda eksik tahminleri azaltacak şekilde veri depolamaya odaklanarak yüksek hıza izin veren bir başka seçenektir. Ana sayfasında: ZStandard ile daha küçük ve daha hızlı veri sıkıştırma
Kertenkele , Brotli veya ZStandard kadar yüksek bir sıkıştırma oranı elde etmiyor, ancak sıkıştırma oranına biraz yaklaşabilir ve biraz daha hızlı olabilir (en azından dekompresyon bildirmesine rağmen, hız ile ilgili bu çizelgeye göre ).

Bir işletim sisteminden bahsetmediniz. Eğer Windows, ZStandardlı 7-Zip (Bültenleri) , bu algoritmaların tümünü kullanmak için destek sağlamak üzere değiştirilmiş olan 7-Zip versiyonudur.

— TOOGAM
kaynak

İlginç, daha brotliönce duymuştum , ama unuttum. Cevabımdaki kriter tablosuna ekledim! Aslında gzipdaha yüksek bir hızda olduğu gibi aynı sıkıştırma oranını sağladığı kalite ayarı 1 dışında performansından biraz hayal kırıklığına uğradım .

— marcelm

2

Zstd kullanın . Facebook için yeterince iyiyse, muhtemelen sizin için de yeterince iyidir.

Daha ciddi bir notta, aslında oldukça iyi . Şimdi her şey için kullanıyorum, çünkü sadece çalışıyor ve büyük ölçekte oranla işlem yapmanıza olanak tanıyor (çoğu zaman, depolama ucuz olduğu için hız yine de büyüklükten daha önemli, ancak hız bir darboğazdır).
Bzip2 ile karşılaştırılabilir toplam sıkıştırma elde eden sıkıştırma seviyelerinde, çok daha hızlıdır ve CPU süresinde bir miktar ekstra ödeme yapmaya razıysanız , neredeyse LZMA'ya benzer sonuçlar elde edebilirsiniz (bununla birlikte bzip2'den daha yavaş olacaktır). Hafifçe daha kötü sıkıştırma oranlarında, bzip2'den veya diğer ana akım alternatiflerden çok, çok daha hızlıdır.

Şimdi, olabildiğince sıkıştırmak için utanç verici derecede önemsiz olan bir SQL dökümü sıkıştırıyorsunuz. En fakir kompresörler bile bu tür verilerden iyi puan alıyor.
Böylece zstd, onlarca kez daha hızlı çalışacak ve bu verilerde% 95-99 oranında aynı sıkıştırma elde edersiniz, daha düşük bir sıkıştırma seviyesiyle çalışabilirsiniz .

Bir bonus olarak, bunu sık sık yapacaksanız ve biraz daha fazla zaman harcamak istiyorsanız, zstdkompresörü önceden "çalıştırabilir" , böylece hem sıkıştırma oranını hem de hızını artırabilirsiniz. Eğitimin iyi çalışması için her şeyi değil, ayrı ayrı kayıtları beslemeniz gerekeceğini unutmayın. Aracın çalışma şekli, çok büyük bir blob değil, birçok küçük ve biraz da benzer eğitim örnekleri bekliyor.

— Damon
kaynak

daha iyisi, çok çekirdekli makinelerde pzstd (paralel sürüm) kullanın

— borowis

1

Blok boyutunu ayarlamak (düşürmek) sıkıştırma süresine önemli bir etkisi olabilir gibi gözüküyor.

İşte makinemde yaptığım deneyin bazı sonuçları. timeYürütme süresini ölçmek için komutu kullandım . input.txtkeyfi json kayıtları içeren bir ~ 250mb metin dosyasıdır.

Varsayılan (en büyük) blok boyutunu kullanma ( --bestyalnızca varsayılan davranışı seçer):

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

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

En küçük blok boyutunu kullanma ( --fastargüman):

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

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

Dokümantasyonun dediği gibi, bu biraz şaşırtıcı bir keşif oldu:

Sıkıştırma ve açma hızı, blok büyüklüğünden neredeyse hiç etkilenmez

— Jakub Kukul
kaynak

Şu anki favorim pbzip2. Bunu da denedin mi? Bu soru 16 çekirdeğin bulunduğu bir ortam hakkında.

— guettli

@guettli ne yazık ki bzip ile bağlı kalmalıyım. Hadoop işleri için kullanıyorum ve bzip orada yerleşik sıkıştırma biridir. Yani bir şekilde zaten paralelleştirildi.

— Jakub Kukul