Kompres sejumlah besar file besar dengan cepat

16

Saya memiliki sekitar 200 GB data log yang dihasilkan setiap hari, didistribusikan di antara sekitar 150 file log yang berbeda.

Saya memiliki skrip yang memindahkan file ke lokasi sementara dan melakukan tar-bz2 pada direktori sementara.

Saya mendapatkan hasil yang baik karena 200 GB log dikompresi menjadi sekitar 12-15 GB.

Masalahnya adalah perlu waktu lama untuk mengompres file. The cron pekerjaan berjalan di 2:30 setiap hari dan terus berjalan sampai 5: 00-6: 00.

Apakah ada cara untuk meningkatkan kecepatan kompresi dan menyelesaikan pekerjaan lebih cepat? Ada ide?

Jangan khawatir tentang proses lain dan semua, lokasi di mana kompresi terjadi adalah pada NAS , dan saya dapat menjalankan mount NAS pada VM khusus dan menjalankan skrip kompresi dari sana.

Berikut ini adalah output dari atas untuk referensi:

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
sumber

2

Jika Anda memiliki banyak CPU dan memiliki atau dapat membaginya menjadi beberapa file tar, Anda bisa menjalankan beberapa kompresi.

— Jeff Schaller

@ JeffSchaller apakah mungkin untuk mendapatkan beberapa proses bzip2 mengkompres file yang berbeda tetapi menulis ke tar.bz2file yang sama ?

— anu

2

Apakah file log dibuat di disk lokal sebelum pindah ke NAS? Jika demikian kompres kemudian pindah; dengan cara itu Anda hanya mengirim 15Gb data melalui jaringan daripada 100 (bergerak) kemudian 115 (100baca + 15write) saat mengompresi. Atau sepertinya Anda mungkin terikat CPU pada satu proses bzip2, jadi menjalankan beberapa secara paralel (satu per CPU) mungkin membantu (sampai Anda mencapai batas I / O). Atau gunakan kompresi yang lebih sederhana (mis. "Gzip -1"). Ini tidak akan menghemat banyak ruang disk tetapi akan berjalan lebih cepat.

— Stephen Harris

@Sukminder Saya pasti akan mencoba ini dan melihat perbedaan ukurannya. Terima kasih.

— anu

topOutput Anda menunjukkan bahwa bzip2proses single-threaded Anda memaksimalkan satu inti, tetapi Anda menjalankannya pada sistem quad-core (Satu proses menggunakan 100% CPU -> 25.1%waktu ruang-pengguna CPU, 74% menganggur). Jadi dengan perubahan kecil, Anda bisa menjadi 4x lebih cepat, kecuali ada hal lain yang menjadi hambatan. Baca jawaban Gilles dengan hati-hati. Pertimbangkan untuk menggunakan CPU dalam kotak yang sama dengan disk yang menyimpan data untuk melakukan kompresi. (Anda bahkan dapat memampatkan beberapa file Anda di satu kotak, yang lain di yang lain, dan mengarsipkan setelahnya, sehingga kedua CPU digunakan.)

— Peter Cordes

25

Langkah pertama adalah mencari tahu apa hambatannya: apakah itu disk I / O, jaringan I / O, atau CPU?

Jika hambatannya adalah disk I / O, tidak banyak yang bisa Anda lakukan. Pastikan disk tidak melayani banyak permintaan paralel karena hanya dapat menurunkan kinerja.

Jika bottleneck adalah jaringan I / O, jalankan proses kompresi pada mesin tempat file disimpan: menjalankannya pada mesin dengan CPU yang lebih gemuk hanya membantu jika CPU adalah bottleneck.

Jika bottleneck adalah CPU, maka hal pertama yang perlu dipertimbangkan adalah menggunakan algoritma kompresi yang lebih cepat. Bzip2 tidak selalu merupakan pilihan yang buruk - kelemahan utamanya adalah kecepatan dekompresi - tetapi Anda dapat menggunakan gzip dan mengorbankan beberapa ukuran untuk kecepatan kompresi, atau mencoba format lain seperti lzop atau lzma. Anda mungkin juga menyetel level kompresi: default bzip2 ke -9(ukuran blok maksimum, kompresi maksimum, tetapi juga waktu kompresi terlama); atur variabel lingkungan BZIP2ke nilai seperti -3mencoba level kompresi 3. Utas ini dan utas ini membahas algoritma kompresi umum; khususnya posting blog ini yang dikutip oleh derobert memberikan beberapa tolok ukur yang menunjukkan bahwa gzip -9ataubzip2dengan level rendah mungkin merupakan kompromi yang baik dibandingkan dengan bzip2 -9. Benchmark lain ini yang juga menyertakan lzma (algoritma 7zip, jadi Anda dapat menggunakannya 7zsebagai ganti tar --lzma) menyarankan bahwa lzmapada level rendah dapat mencapai rasio kompresi bzip2 lebih cepat. Hampir semua pilihan selain bzip2 akan meningkatkan waktu dekompresi. Perlu diingat bahwa rasio kompresi tergantung pada data, dan kecepatan kompresi tergantung pada versi program kompresi, pada bagaimana itu dikompilasi, dan pada CPU itu dijalankan.

Pilihan lain jika bottleneck adalah CPU dan Anda memiliki banyak core adalah memparalelkan kompresi. Ada dua cara untuk melakukannya. Salah satu yang bekerja dengan algoritma kompresi apa pun adalah untuk memampatkan file secara terpisah (baik secara individu atau dalam beberapa kelompok) dan digunakan paralleluntuk menjalankan perintah pengarsipan / kompresi secara paralel. Ini dapat mengurangi rasio kompresi tetapi meningkatkan kecepatan pengambilan file individu dan bekerja dengan alat apa pun. Pendekatan lain adalah dengan menggunakan implementasi paralel dari alat kompresi; utas ini mencantumkan beberapa.

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

4

"Jika hambatannya adalah disk I / O, tidak banyak yang bisa kamu lakukan." Itu mungkin benar di sini, karena rasio kompresi sudah baik, tetapi secara umum ketika I / O adalah bottleneck, layak untuk melihat menggunakan lebih banyak CPU untuk mendapatkan rasio kompresi yang lebih baik (menggunakan pengaturan kompresi yang berbeda atau algoritma yang berbeda). .. Anda tidak dapat benar-benar mengurangi "I" (karena Anda perlu membaca semua data) tetapi Anda kadang-kadang dapat secara signifikan mengurangi "O" :-)

— psmears

1

Jika Anda mengatakan 7zuntuk tidak membuat arsip "solid", atau membatasi ukuran blok "solid", itu akan menjalankan utas LZMA mutliple secara paralel, IIRC. data file log adalah kasus khusus untuk kompresi, karena cenderung sangat redundan (banyak kesamaan antar baris). Ini jelas layak untuk diuji gzip,, bzip2dan xzpada file log khusus OP, daripada hanya melihat tolok ukur kompresi umum untuk mengesampingkan opsi apa pun. Bahkan kompresor cepat yang layak dipertimbangkan ( lzop, lz4, snappy).

— Peter Cordes

Kompresor LZMA yang disukai akhir-akhir ini adalah xz. Gunakan tar -Jatau --xz, bukan --lzma. .lzmadianggap sebagai format file "lawas" . Iterasi berganda dari format file untuk kompresi LZMA sedikit memalukan, dan sesuatu yang semestinya mereka lakukan sejak awal. Tapi AFAIK pada dasarnya bagus sekarang, dan .xz tidak akan digantikan oleh format file lain untuk aliran kompresi yang sama.

— Peter Cordes

7z memang memiliki kompresi yang sangat baik & multi-threading, tetapi karena format arsip (perlu indeks, atau mungkin bug?) Saya tidak berpikir itu dapat digunakan di tengah-tengah pipa - tidak akan menggunakan stdin dan stdout pada saat yang sama

— Xen2050

Ini sangat membantu dan berwawasan luas. Tim saya menduga bahwa operasi melalui NFS adalah hambatan besar.

— anu

16

Anda dapat menginstal pigz, paralel gzip, dan menggunakan tar dengan kompresi multi-ulir. Suka:

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

Di mana -Iopsinya adalah:

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

Tentu saja, jika NAS Anda tidak memiliki banyak core / CPU yang kuat, Anda tetap dibatasi oleh kekuatan CPU.

Kecepatan hard-disk / array tempat VM dan kompresi dijalankan dapat menjadi hambatan juga.

— labirin
sumber

1

Dan jika Anda ingin menggunakan bzip2, Anda dapat menggunakan pbzip2atau lbzip2.

— Radovan Garabík

2

Ini jawaban terbaikmu. Tapi pertama-tama, pastikan bahwa langkah pertama Anda adalah ke lokasi yang berada di sistem file yang sama dengan file aslinya. Jika tidak, "gerakan" Anda benar-benar byte-copy-lalu-hapus. Pada sistem file yang sama, perpindahan adalah pengaturan ulang tautan sistem file. Itu perintah besarnya lebih cepat. Untuk file log saya yang berukuran ratusan Gigabytes, pigz membuat semua perbedaan. Anda dapat menentukan berapa banyak thread paralel yang harus dijalankan. Selama cpu Anda memiliki beberapa core, saya tidak akan menghabiskan banyak waktu untuk menyelidiki. Anda mungkin menginginkan pigz dalam acara apa pun; Anda bisa mendapatkan speedup Anda segera.

— Mike S

Setelah Anda melakukan pigz'ing, lihat output htop dan iostat Anda dan amati kinerja sistem Anda, jika Anda ingin menyelidiki sistem Anda lebih lanjut. Tetapi sekali lagi, saya tidak akan lagi mencoba dan kompres file besar tanpa pigz. Pada sistem multicore modern, konyol untuk tidak menggunakannya. Ini adalah kemenangan langsung - Anda akan melihat.

— Mike S

7

Sejauh ini, cara tercepat dan paling efektif untuk mengompresi data adalah dengan menghasilkan lebih sedikit.

Jenis log apa yang Anda hasilkan? 200GB setiap hari terdengar cukup banyak (kecuali Anda google atau ISP ...), pertimbangkan bahwa 1MB teks adalah sekitar 500 halaman, jadi Anda menghasilkan setara dengan 100 juta halaman teks per hari, Anda akan isi perpustakaan kongres dalam seminggu.

Lihat lebih dari data log Anda jika Anda bisa menguranginya dan masih mendapatkan apa yang Anda butuhkan dari log. Misalnya dengan mengecilkan level log atau menggunakan format log terser. Atau jika Anda menggunakan log untuk statistik, proses statistik sambil jalan dan buang file dengan ringkasan dan kemudian filter log sebelum kompresi untuk penyimpanan.

— Emily L.
sumber

1

Ini adalah solusi filosofis yang menarik. Solusi dari sebagian besar masalah kehidupan adalah menghindari masalah sama sekali bukan. Itu sampai seseorang meneliti dengan seksama saran dan menyadari bahwa ada 100-an orang dan 1000-an persetujuan yang harus dilalui seseorang untuk mencapai ini.

— anu

1

@ Anu Tidak ada konteks untuk pertanyaan yang diberikan jadi saya tidak berasumsi. Dan bisakah Anda memberi tahu saya dari mana Anda mendapat persetujuan nomor 1000? Bagi saya sepertinya Anda baru saja mengada-ada.

— Emily L.

Saya akan angkat suara ini. Ini adalah solusi yang sering diabaikan, tetapi sekali diperhatikan, menonjol untuk banyak masalah kehidupan.

— jrw32982 mendukung Monica

1

Baiklah .. sekarang saya tidak lagi bekerja di sana, saya setidaknya bisa mengungkapkan bahwa ini adalah masalah di Apple. Lebih khusus pada tumpukan layanan yang melayani toko aplikasi online ... jadi ya, 1000-an persetujuan cukup banyak kenyataan karena mereka memiliki 1000-an layanan mikro dan masing-masing dari mereka menghasilkan log yang perlu dikompresi dan harus menandatangani pada mengubah mereka level logging dll ... Bagaimanapun ... kami menemukan solusi untuk inhouse btw ini .. yang cukup banyak setara dengan gzip paralel yang diturunkan ke layanan microser lainnya.

— anu

3

Anda dapat mengurangi jumlah kompresi (dalam hal ruang yang dihemat) untuk membuatnya lebih cepat. Untuk mulai dengan, bzip2 JAUH lebih lambat daripada gzip, meskipun kompres lebih kecil. Anda juga dapat mengubah tingkat kompresi bzip2, gzip, atau sebagian besar program kompresi untuk memperdagangkan ukuran untuk kecepatan.

Jika Anda tidak ingin memperdagangkan ukuran kecepatan, Anda mungkin masih bisa mendapatkan ukuran yang sama atau lebih kecil sambil tetap mendapatkan peningkatan kecepatan menggunakan kompresor yang menggunakan LZMA (xz misalnya).

Anda akan menemukan tolok ukur jika Anda mencari, tetapi taruhan terbaik Anda adalah melakukan beberapa tes dengan file Anda sendiri pada perangkat keras target Anda.

— EricS
sumber

3

Jika satu-satunya persyaratan adalah kompresi cepat , saya akan merekomendasikan lz4 sangat tinggi.

Ini digunakan di banyak tempat di mana kecepatan kompresi lebih penting daripada rasio kompresi (misalnya sistem file dengan kompresi transparan seperti ZFS)

— pdo
sumber

Belum pernah mendengarnya sebelumnya, apakah ada program yang mungkin sudah diinstal secara praktis di mana-mana yang menggunakannya, seperti xz?

— Xen2050