bzip2 ช้าเกินไป มีหลายแกนให้เลือก

ฉันใช้คำสั่งนี้:

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

ใช้เวลานานเกินไป topฉันมองไปที่กระบวนการที่มี กระบวนการ bzip2 ใช้เวลาประมาณ 95% และ postgres 5% ของหนึ่งคอร์ waรายการอยู่ในระดับต่ำ ซึ่งหมายความว่าดิสก์ไม่ใช่คอขวด

ฉันจะทำอย่างไรเพื่อเพิ่มประสิทธิภาพ

อาจปล่อยให้ bzip2 ใช้แกนเพิ่มเติม เซิร์ฟเวอร์มี 16 คอร์

หรือใช้ทางเลือกแทน bzip2?

ฉันจะทำอย่างไรเพื่อเพิ่มประสิทธิภาพ

มีอัลกอริธึมการบีบอัดหลายรอบและbzip2เป็นหนึ่งในขั้นตอนที่ช้ากว่า ธรรมดาgzipมีแนวโน้มที่จะเร็วขึ้นอย่างมีนัยสำคัญที่มักจะบีบอัดไม่เลว เมื่อความเร็วเป็นสิ่งที่สำคัญที่สุดlzopเป็นที่ชื่นชอบ การบีบอัดไม่ดี แต่เร็วมาก

ฉันตัดสินใจที่จะมีความสนุกสนานและเปรียบเทียบอัลกอริทึมบางอย่างรวมถึงการใช้งานแบบขนาน ไฟล์อินพุตคือเอาต์พุตของpg_dumpallคำสั่งบนเวิร์กสเตชันของฉันซึ่งเป็นไฟล์ SQL ขนาด 1913 MB ฮาร์ดแวร์คือ quad-core i5 ที่เก่ากว่า เวลาเป็นเวลานาฬิกาแขวนของการบีบอัด การใช้งานแบบขนานถูกตั้งค่าให้ใช้คอร์ทั้ง 4 คอร์ ตารางเรียงตามความเร็วในการบีบอัด

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

หาก 16 คอร์ของเซิร์ฟเวอร์ของคุณไม่มีการใช้งานเพียงพอที่ทุกอย่างจะถูกนำมาใช้ในการบีบอัดpbzip2อาจจะทำให้คุณมีความเร็วมากขึ้น แต่คุณต้องการความเร็วเพิ่มขึ้นและคุณสามารถทนไฟล์ที่มีขนาดใหญ่กว่า ~ 20% gzipน่าจะเป็นทางออกที่ดีที่สุดของคุณ

อัปเดต:ฉันเพิ่มbrotliผลลัพธ์ (ดูคำตอบของ TOOGAM) ลงในตาราง brotlis การตั้งค่าคุณภาพการบีบอัดที่มีผลกระทบขนาดใหญ่มากในอัตราการบีบอัดและความเร็วดังนั้นฉันเพิ่มสามการตั้งค่า ( q0, q1และq11) เริ่มต้นเป็นแต่มันช้ามากและยังคงเลวร้ายยิ่งกว่าq11 ดูดีมากแม้ว่า; อัตราส่วนการบีบอัดเท่ากัน แต่เร็วกว่า 4-5 เท่า!xzq1gzip

อัปเดต:เพิ่มlbzip2(ดูความคิดเห็น gmathts) และzstd(ความคิดเห็นของ Johnny) ลงในตารางและจัดเรียงตามความเร็วในการบีบอัด lbzip2ทำให้bzip2ครอบครัวกลับมาทำงานอีกครั้งด้วยการบีบอัดอย่างรวดเร็วสามเท่าpbzip2ด้วยอัตราการบีบอัดที่ยอดเยี่ยม! zstdก็ดูสมเหตุสมผล แต่ก็เอาชนะbrotli (q1)ทั้งในอัตราส่วนและความเร็ว

ข้อสรุปดั้งเดิมของฉันที่ว่าธรรมดาgzipคือทางออกที่ดีที่สุดที่เริ่มจะดูไร้สาระ แม้ว่าจะแพร่หลายทั่วไป แต่ก็ยังไม่สามารถเอาชนะได้)

ใช้ pbzip2

คู่มือบอกว่า:

pbzip2 เป็นการใช้งานแบบขนานของคอมเพรสเซอร์ไฟล์การเรียงลำดับบล็อก bzip2 ที่ใช้ pthreads และรับการเร่งความเร็วใกล้เชิงเส้นบนเครื่อง SMP ผลลัพธ์ของรุ่นนี้เข้ากันได้กับ bzip2 v1.0.2 หรือใหม่กว่า (เช่น: อะไรก็ตามที่บีบอัดด้วย pbzip2 สามารถแตกได้ด้วย bzip2)

ตรวจจับจำนวนโปรเซสเซอร์ที่คุณมีและสร้างเธรดโดยอัตโนมัติ

• brotli ของ Google เป็นรูปแบบที่ใหม่กว่าซึ่งได้รับการสนับสนุนอย่างกว้างขวางในเบราว์เซอร์เมื่อเร็ว ๆ นี้เนื่องจากมีการบีบอัดที่น่าประทับใจความเร็วที่น่าประทับใจและบางทีอาจเป็นการผสมผสาน / ความสมดุลที่น่าประทับใจที่สุดของฟีเจอร์ทั้งสอง

  ข้อมูลบางส่วน:

  เปรียบเทียบ Brotli, Deflate, Zopfli, LZMA, LZHAM และ Bzip2 อัลกอริทึมการบีบอัด

  • เช่นแผนภูมินี้รายงานตัวเลขที่แสดงว่า Brotli เร็วกว่า Bzip2 ประมาณ 6-14

  CanIUse.com: feature: brotliแสดงการสนับสนุนโดย Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (แต่ไม่ใช่ Opera Mini หรือ Microsoft Internet Explorer)

  การเปรียบเทียบ: Brotli กับ deflate เทียบกับ zopfli เทียบกับ lzma เทียบกับ lzham เทียบกับ bzip2

  • หากคุณกำลังมองหาความเร็วในการบีบอัดสิ่งที่คุณกำลังมองหาคือเส้นตรงใดที่อยู่ในแผนภูมินี้ (รายการที่ด้านบนของแผนภูมินี้แสดงอัตราส่วนการบีบอัดที่สูงกว่า = tighter แต่ถ้าความเร็วในการบีบอัดเป็นสิ่งที่คุณให้ความสำคัญ
  การเปรียบเทียบ: อัตราส่วนการบีบอัดเทียบกับความเร็วในการบีบอัดสำหรับวิธี ZStandard 7-Zip

• ZStandard ของ Facebook เป็นอีกทางเลือกหนึ่งที่พยายามลดบิต แต่ยังมุ่งเน้นที่การจัดเก็บข้อมูลในลักษณะที่ช่วยลดการคาดการณ์ที่ไม่ได้รับดังนั้นจึงช่วยให้ความเร็วสูงขึ้น หน้าแรกอยู่ที่: บีบอัดข้อมูลขนาดเล็กและเร็วขึ้นด้วย ZStandard
• จิ้งจกไม่ได้รับการบีบอัดที่ค่อนข้างสูงเท่ากับ Brotli หรือ ZStandard แต่อาจจะค่อนข้างใกล้เคียงกับอัตราส่วนการบีบอัดและค่อนข้างเร็วขึ้นเล็กน้อย (อย่างน้อยตามแผนภูมินี้ซึ่งเกี่ยวกับความเร็วแม้ว่าจะมีการรายงานการบีบอัด)

คุณไม่ได้พูดถึงระบบปฏิบัติการ หาก Windows, 7-Zip พร้อม ZStandard (Release)เป็นรุ่นของ 7-Zip ที่ได้รับการแก้ไขเพื่อรองรับการใช้อัลกอริทึมเหล่านี้ทั้งหมด

ใช้zstd ถ้ามันดีพอสำหรับ Facebook ก็คงดีพอสำหรับคุณเช่นกัน

จริงๆแล้วมันค่อนข้างดีทีเดียว ฉันใช้มันทุกอย่างตอนนี้เพราะมันใช้งานได้แล้วและมันช่วยให้คุณแลกเปลี่ยนความเร็วในอัตราส่วนที่มาก (ส่วนใหญ่ความเร็วนั้นสำคัญกว่าขนาดอยู่ดีเนื่องจากพื้นที่เก็บข้อมูลราคาถูก แต่ความเร็วเป็นคอขวด)
ในระดับการบีบอัดที่เกิดการบีบอัดโดยรวมเทียบเคียงเป็น bzip2 ก็เร็วขึ้นอย่างมีนัยสำคัญและถ้าคุณยินดีที่จะจ่ายเงินเพิ่มพิเศษบางอย่างในเวลา CPU คุณสามารถเกือบจะบรรลุผลคล้ายกับ LZMA (แม้ว่าก็จะช้ากว่า bzip2) ในอัตราส่วนการอัด sligthly เลวก็เป็นมากเร็วกว่า bzip2 หรือทางเลือกที่สำคัญอื่น ๆ

ตอนนี้คุณกำลังบีบอัดดัมพ์ของ SQL ซึ่งเป็นเรื่องที่น่าอายที่จะบีบอัดข้อมูลให้น้อยที่สุดเท่าที่จะทำได้ แม้แต่คอมเพรสเซอร์ที่ยากจนที่สุดก็ให้คะแนนกับข้อมูลประเภทนั้นได้ดี
ดังนั้นคุณสามารถรันzstdด้วยระดับการบีบอัดที่ต่ำกว่าซึ่งจะทำงานได้เร็วขึ้นหลายสิบเท่าและยังคงสามารถบีบอัดข้อมูลเดิมได้ถึง 95-99%

เป็นโบนัสหากคุณจะทำเช่นนี้บ่อยครั้งและต้องการลงทุนเวลาพิเศษคุณสามารถ "ฝึกอบรม" zstdคอมเพรสเซอร์ล่วงหน้าก่อนซึ่งจะเพิ่มทั้งอัตราการบีบอัดและความเร็ว โปรดทราบว่าสำหรับการฝึกอบรมเพื่อให้ทำงานได้ดีคุณจะต้องป้อนบันทึกแต่ละรายการไม่ใช่ทั้งหมด วิธีการทำงานของเครื่องมือนี้คาดว่าจะมีตัวอย่างขนาดเล็กและค่อนข้างคล้ายกันสำหรับการฝึกอบรมไม่ใช่หยดขนาดใหญ่เพียงก้อนเดียว

ดูเหมือนว่าการปรับ (ลดขนาด) ขนาดบล็อกอาจมีผลกระทบอย่างมากต่อเวลาบีบอัด

นี่คือผลการทดลองที่ฉันทำในเครื่องของฉัน ฉันใช้timeคำสั่งเพื่อวัดเวลาดำเนินการ input.txtเป็นไฟล์ข้อความ ~ 250mb ที่มีเร็กคอร์ด json โดยพลการ

การใช้ขนาดบล็อกเริ่มต้น (ใหญ่ที่สุด) ( --bestเพียงเลือกพฤติกรรมเริ่มต้น):

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

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

การใช้ขนาดบล็อกที่เล็กที่สุด ( --fastอาร์กิวเมนต์):

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

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

นี่เป็นการค้นพบที่น่าแปลกใจเล็กน้อยเนื่องจาก documntation พูดว่า:

ความเร็วในการบีบอัดและการคลายบีบอัดนั้นไม่ได้รับผลกระทบใด ๆ จากขนาดบล็อก