Çok sayıda büyük dosyayı hızlıca sıkıştırın

16

Günlük üretilen ve yaklaşık 150 farklı günlük dosyası arasında dağıtılan yaklaşık 200 GB günlük verilerim var.

Geçici bir konuma dosyaları taşır ve geçici dizinde tar-bz2 yapan bir komut dosyası var.

200 GB günlükler yaklaşık 12-15 GB olarak sıkıştırıldığından iyi sonuçlar elde ediyorum.

Sorun, dosyaları sıkıştırmanın sonsuza kadar sürmesidir. Cron işi günlük 2:30 am çalışır ve 5 kadar çalışmaya devam: 00-6: 00 PM.

Sıkıştırma hızını artırmanın ve işi daha hızlı tamamlamanın bir yolu var mı? Herhangi bir fikir?

Diğer süreçler ve tüm endişe etmeyin, sıkıştırma olur konumu üzerindedir NAS ve ben adanmış üzerinde NAS monte çalıştırabilir VM ve oradan sıkıştırma komut dosyasını çalıştırın.

İşte referans için üst çıktı :

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh

— anu
kaynak

2

Birden fazla CPU'nuz varsa ve bunu birden çok tar dosyasına böldüyseniz veya bölebilirseniz, birden fazla sıkıştırma çalıştırabilirsiniz.

— Jeff Schaller

@JeffSchaller birden fazla bzip2 işlemi farklı dosyaları sıkıştırmak ama aynı tar.bz2dosyaya yazmak mümkün olabilir mi?

— anu

2

Günlük dosyaları NAS'a taşınmadan önce yerel diskte mi oluşturuluyor? Eğer öyleyse sıkıştır sonra hareket et; bu şekilde sıkıştırma sırasında 100 (taşıma) yerine 115 (100 okuma + 15 yazma) yerine ağ üzerinden yalnızca 15 Gb veri gönderiyorsunuz. Alternatif olarak, bir bzip2 işleminde CPU bağlı olabileceğiniz gibi görünüyor, bu nedenle paralel olarak (CPU başına bir) çoklu çalıştırmak yardımcı olabilir (siz G / Ç sınırına ulaşana kadar). Veya daha basit bir sıkıştırma kullanın (örneğin "gzip -1"). Çok fazla disk alanı kazanmaz, ancak daha hızlı çalışır.

— Stephen Harris

@Sukminder Kesinlikle bunu deneyeceğim ve boyuttaki farkı göreceğim. Teşekkürler.

— anu

Sizin topçıkış gösterileri senin tek dişli olduğunu bzip2süreci tek çekirdek tükenmek üzere olduğunu, ancak (Bir işlemi% 100 CPU kullanan -> bir dört çekirdekli sistem üzerinde çalışan olduğunuzu 25.1%kullanıcı uzay CPU süresi,% 74 boşta). Yani küçük değişikliklerle, başka bir şey darboğaz haline gelmedikçe 4 kat daha hızlı gidebilirsiniz. Gilles'i dikkatle okuyun. Sıkıştırma için CPU'yu verileri tutan disklerle aynı kutuda kullanmayı düşünün. (Hatta dosyalarınızdan bazılarını bir kutuda, diğerini diğerinde sıkıştırabilir ve arşivleyebilirsiniz, böylece her iki CPU da kullanılır.)

— Peter Cordes

25

İlk adım, darboğazın ne olduğunu bulmaktır: disk G / Ç, ağ G / Ç veya CPU mu?

Darboğaz disk I / O ise, yapabileceğiniz çok şey yoktur. Disklerin çok sayıda paralel istek sunmadığından emin olun, çünkü bu yalnızca performansı düşürebilir.

Darboğaz ağ G / Ç'siyse, sıkıştırma işlemini dosyaların depolandığı makinede çalıştırın: daha CPU'lu bir makinede çalıştırmak yalnızca CPU darboğazdaysa yardımcı olur.

Darboğaz CPU ise, dikkate alınması gereken ilk şey daha hızlı bir sıkıştırma algoritması kullanmaktır. Bzip2 mutlaka kötü bir seçim değildir - ana zayıflığı dekompresyon hızıdır - ancak gzip kullanabilir ve sıkıştırma hızı için bir miktar fedakarlık yapabilir veya lzop veya lzma gibi diğer formatları deneyebilirsiniz. Sıkıştırma seviyesini de ayarlayabilirsiniz: bzip2 varsayılanı -9(maksimum blok boyutu, dolayısıyla maksimum sıkıştırma, aynı zamanda en uzun sıkıştırma süresi); ortam değişkenini sıkıştırma düzeyi 3'ü denemek BZIP2gibi bir değere ayarlayın -3. Bu iş parçacığı ve bu iş parçacığı genel sıkıştırma algoritmalarını tartışır; Özellikle bu blog yazısı derobert bahsettiği önermek bazı kriterler verdiğini gzip -9veyabzip2düşük bir seviyeye kıyasla iyi bir uzlaşma olabilir bzip2 -9. Lzma (7zip algoritması, bunun yerine kullanabileceğiniz gibi ) içeren bu diğer kıyaslama , düşük bir seviyede bzip2 sıkıştırma oranına daha hızlı ulaşabileceğini düşündürmektedir . Bzip2 dışında hemen hemen her seçenek dekompresyon süresini iyileştirir. Sıkıştırma oranının verilere bağlı olduğunu ve sıkıştırma hızının sıkıştırma programının sürümüne, nasıl derlendiğine ve yürütüldüğü CPU'ya bağlı olduğunu unutmayın.7ztar --lzmalzma

Darboğaz CPU ise ve birden fazla çekirdeğiniz varsa başka bir seçenek de sıkıştırmayı paralelleştirmektir. Bunu yapmanın iki yolu var. Herhangi bir sıkıştırma algoritmasıyla çalışan dosyalardan biri ayrı ayrı (tek tek veya birkaç grup halinde) parallelsıkıştırmak ve arşivleme / sıkıştırma komutlarını paralel olarak çalıştırmaktır. Bu, sıkıştırma oranını azaltabilir, ancak tek bir dosyanın alma hızını artırır ve herhangi bir araçla çalışır. Diğer yaklaşım, sıkıştırma aracının paralel bir uygulamasını kullanmaktır; bu iş parçacığı birkaç listeler.

— Gilles 'SO- şeytan olmayı bırak'
kaynak

4

"Darboğaz disk I / O ise, yapabileceğiniz pek bir şey yok." Bu muhtemelen burada doğrudur, çünkü sıkıştırma oranı zaten iyidir, ancak genel olarak I / O darboğazdayken daha iyi bir sıkıştırma oranı elde etmek için daha fazla CPU kullanmaya değer olabilir (farklı sıkıştırma ayarları veya farklı bir algoritma kullanarak). .. "Ben" i gerçekten azaltamazsınız (çünkü tüm verileri okumalısınız) ama bazen "O" 'yu önemli ölçüde azaltabilirsiniz :-)

— psmears

1

7z"Katı" bir arşiv oluşturmamayı veya "katı" blokların boyutunu sınırlamamayı söylerseniz , paralel LZMA iş parçacıklarını paralel olarak IIRC olarak çalıştıracaktır. günlük dosyası verileri, sıkıştırma için özel bir durumdur, çünkü yüksek oranda yedek olma eğilimindedir (satırlar arasında birçok benzerlik). Bu kesinlikle değer test var gzip, bzip2ve xzsadece herhangi bir seçenek ekarte etmek jenerik sıkıştırma kriterler bakarak yerine, OP'ın belirli günlük dosyaları üzerinde. Hatta hızlı kompresörler dikkate değerdir ( lzop, lz4, snappy).

— Peter Cordes

Bugünlerde tercih edilen LZMA kompresörü xz. --Lzma değil tar -Jveya kullanın --xz. .lzma"eski" bir dosya biçimi olarak kabul edilir . LZMA sıkıştırması için dosya biçimlerinin çoklu yinelemeleri biraz utanç verici ve ilk seferinde doğru olması gereken bir şey. Ancak AFAIK artık temelde iyi ve .xz aynı sıkıştırma akışı için başka bir dosya biçimiyle değiştirilmek üzere değil.

— Peter Cordes

7z mükemmel sıkıştırma ve çoklu iş parçacığı var, ancak arşiv biçimi nedeniyle (bir dizin veya belki hatalar gerekiyor?) Bir boru hattının ortasında kullanılabileceğini sanmıyorum - stdin ve stdout kullanmayacak aynı zamanda

— Xen2050

Bu gerçekten yardımsever ve anlayışlıydı. Ekibim NFS üzerindeki operasyonun büyük bir darboğaz olduğunu anladı.

— anu

16

pigzÇok iş parçacıklı sıkıştırmayla paralel gzip kurabilir ve katran kullanabilirsiniz. Sevmek:

tar -I pigz -cf file.tar.gz *

-ISeçenek nerede :

-I, --use-compress-program PROG
  filter through PROG

Tabii ki, NAS'ınızda birden fazla çekirdek / güçlü CPU yoksa, yine de CPU gücü ile sınırlandırılırsınız.

VM ve sıkıştırmanın üzerinde çalıştığı sabit disk / dizinin hızı da bir darboğaz olabilir.

— mazs
kaynak

1

Eğer bzip2 kullanmak istiyorsanız, kullanabileceğiniz pbzip2veya lbzip2.

— Radovan Garabík

2

Bu senin en iyi cevabın. Ancak önce, ilk hamlenizin orijinal dosyalarla aynı dosya sisteminde yer aldığından emin olun. Aksi takdirde, "taşıma" gerçekten bir byte-copy-sonra-delete. Aynı dosya sisteminde, bir hareket dosya sistemi bağlantılarının yeniden düzenlenmesidir. Bu, büyüklük derecelerinin daha hızlı olması. Yüzlerce Gigabayt büyüklüğündeki log dosyalarım için pigz tüm farkı yarattı. Kaç paralel iş parçacığı çalıştırılacağını söyleyebilirsiniz. İşlemcinizin birden fazla çekirdeği olduğu sürece, araştırmak için çok fazla zaman harcamazdım. Her durumda muhtemelen pigz isteyeceksiniz; Hızlanmanızı hemen alabilirsiniz.

— Mike S

Domuzcukladıktan sonra, sisteminizi daha ayrıntılı incelemek isterseniz htop ve iostat çıktılarınıza bakın ve sistem performansınızı gözlemleyin. Ama yine de, pigz olmadan büyük dosyaları sıkıştırmaya çalışmayacağım. Modern çok çekirdekli bir sistemde, kullanmamak aptalca. Bu çok acil bir kazanç - göreceksin.

— Mike S

7

Şimdiye kadar verileri sıkıştırmanın en hızlı ve en etkili yolu, daha az veri üretmektir.

Ne tür günlükler üretiyorsunuz? 200 GB günlük sesler çok fazla (google veya bazı ISS değilseniz ...), 1 MB'lık metnin yaklaşık 500 sayfa olduğunu göz önünde bulundurun, böylece günde 100 milyon sayfa eşdeğeri metin oluşturursunuz, Kongre kütüphanesini bir hafta içinde doldurun.

Bir şekilde azaltabilir ve ihtiyacınız olan şeyleri günlüklerden alabilirseniz, günlük verilerinizi görün. Örneğin, kayıt seviyesini düşürerek veya ters kayıt formatını kullanarak. İstatistikler için günlükleri kullanıyorsanız, istatistikleri anında işleyin ve özetle birlikte bir dosyayı dökün ve depolama için sıkıştırmadan önce günlükleri filtreleyin.

— Emily L.
kaynak

1

Bu ilginç bir felsefi çözümdür. Yaşam sorunlarının çoğunun çözümü, problemi tamamen yaşamaktan kaçınmak değil. Bu, öneriyi yakından inceleyene ve bunu başarmak için geçmesi gereken 100 kişi ve 1000 onay olduğunu fark edene kadar.

— anu

1

@anu Soruyla ilgili bağlam verilmedi bu yüzden hiçbiri varsaymadım. Bana 1000'den fazla onay aldığınız yeri söyleyebilir misiniz? Bana öyle geliyor ki, bunu uydurmuşsun gibi.

— Emily L.

Bunu onaylayacağım. Bu, çoğu zaman gözden kaçan, ancak bir kez fark edildiğinde, yaşamın birçok sorununa göze çarpan bir çözümdür.

— jrw32982 Monica'yı

1

Artık orada çalışmıyorum, en azından bunun Apple'da bir sorun olduğunu açıklayabilirim. Daha özel olarak, çevrimiçi uygulama mağazasına hizmet veren hizmet yığınında ... bu yüzden 1000 onay onayı neredeyse bir gerçek çünkü 1000 mikro hizmete sahipler ve her biri sıkıştırılması gereken günlükleri üretiyorlar ve kayıt seviyeleri vb ... Her neyse ... bu kurum içi btw için bir çözüm bulduk. Bu, başka bir mikro hizmete yüklenen paralel gzip'e hemen hemen eşdeğer.

— anu

3

Daha hızlı hale getirmek için sıkıştırma miktarını (kaydedilen alan açısından) azaltabilirsiniz. Başlangıç olarak, bzip2, daha küçük sıkıştırmasına rağmen, gzip'ten ÇOK daha yavaştır. Ayrıca, bzip2, gzip veya çoğu sıkıştırma programının sıkıştırma düzeyini, hız için işlem boyutu olarak değiştirebilirsiniz.

Hızı takas etmek istemiyorsanız, yine de LZMA kullanan bir kompresör (örneğin xz) kullanarak bir hız iyileştirmesi alırken aynı boyutta veya daha küçük olabilirsiniz.

Arama yaparsanız karşılaştırmalar bulacaksınız, ancak en iyi seçeneğiniz, hedef donanımınızda kendi dosyanızla bazı testler yapmaktır.

— Erics
kaynak

3

Tek gereksinim sıkıştırmanın hızlı olması , lz4'ü çok tavsiye ederim .

Sıkıştırma hızının sıkıştırma oranından daha önemli olduğu birçok yerde kullanılır (örneğin, ZFS gibi şeffaf sıkıştırmaya sahip dosya sistemleri)

— pdo
kaynak

Daha önce hiç duymamıştım, muhtemelen xz gibi kullanan her yere pratik olarak kurulmuş bir program var mı?

— Xen2050