이 명령을 실행 중입니다.
pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2
시간이 너무 오래 걸립니다. 로 프로세스를 top
봅니다. bzip2 프로세스는 한 코어의 약 95 %와 postgres 5 %를 사용합니다. wa
항목은 낮다. 이는 디스크에 병목 현상이 없음을 의미합니다.
성능을 높이려면 어떻게해야합니까?
bzip2가 더 많은 코어를 사용하도록 할 수도 있습니다. 서버에는 16 개의 코어가 있습니다.
아니면 bzip2의 대안을 사용 하시겠습니까?
성능을 높이려면 어떻게해야합니까?
답변
주변에는 많은 압축 알고리즘 bzip2
이 있으며 느린 알고리즘 중 하나입니다. 평범한 gzip
압축은 보통 훨씬 더 빠르지 않은 경향이 있습니다. 속도가 가장 중요 할 때가 가장 lzop
좋아합니다. 압축이 좋지 않지만 너무 빠릅니다.
나는 재미를 가지고 병렬 구현을 포함하여 몇 가지 알고리즘을 비교하기로 결정했습니다. 입력 파일은 pg_dumpall
내 워크 스테이션에서 1913MB SQL 파일 의 명령 출력입니다 . 하드웨어는 구형 쿼드 코어 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 답변 참조). brotli
I 세 설정되도록 첨가의 압축 품질 설정은, 압축률과 속도에 매우 큰 영향을 미친다 ( q0
, q1
및 q11
). 기본값은 q11
이지만 매우 느리고 여전히 xz
. q1
그래도 아주 좋아 보인다; 와 동일한 압축 비율 gzip
이지만 4-5 배 빠릅니다!
업데이트 : 추가 lbzip2
(gmathts 설명을 참조) zstd
테이블에 (조니의 코멘트) 및 압축 속도하여 분류. 큰 압축 비율 로 3 배 빠르게 압축 lbzip2
하여 bzip2
가족을 다시 달리게합니다 pbzip2
! zstd
또한 합리적인 것처럼 보이지만 brotli (q1)
비율과 속도가 모두 중요합니다.
평범한 gzip
것이 최선의 방법 이라고 내 원래 결론은 거의 바보처럼 보이기 시작했다. 유비쿼터스에도 불구하고 여전히 이길 수는 없습니다.)
답변
pbzip2를 사용하십시오.
매뉴얼은 말한다 :
pbzip2는 pthread를 사용하고 SMP 머신에서 거의 선형 속도 향상을 달성하는 bzip2 블록 정렬 파일 압축기의 병렬 구현입니다. 이 버전의 출력은 bzip2 v1.0.2 이상과 완전히 호환됩니다 (예 : pbzip2로 압축 된 항목은 bzip2로 압축 해제 할 수 있음).
보유한 프로세서 수를 자동으로 감지하고 그에 따라 스레드를 작성합니다.
답변
-
Google의 brotli는 최신 압축 형식으로 최근 브라우저 내에서 폭 넓은 지원을 받았으며, 압축, 압축 속도 및 두 기능의 조합이 가장 뛰어납니다.
일부 데이터 :
Brotli, Deflate, Zopfli, LZMA, LZHAM 및 Bzip2 압축 알고리즘의 비교
- 예를 들어, 이 차트는 Brotli가 Bzip2보다 약 6-14 빠르다는 수치를보고합니다.
CanIUse.com : 기능 : brotli 는 Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (Opera Mini 또는 Microsoft Internet Explorer 제외)의 지원을 보여줍니다.
비교 : Brotli vs 수축 vs Zopfli vs lzma vs lzham vs bzip2
- 압축 속도를 찾고 있다면 찾고있는 것은이 차트에서 어느 줄이 더 오른쪽에 있는지입니다. (이 차트의 맨 위에있는 항목은 압축 비율이 엄격함을 나타냅니다. 높을수록 더 빠릅니다. 그러나 압축 속도가 우선 순위 인 경우 차트에서 오른쪽에 도달하는 라인에 더주의를 기울이려고합니다.)
-
Facebook의 ZStandard는 비트를 줄이기 위해 노력하지만 누락 된 예측을 줄이는 방식으로 데이터를 저장하는 데 중점을 두어 더 빠른 속도를 허용하는 또 다른 옵션입니다. 홈페이지는 다음과 같습니다 :
ZStandard를 통한 더 작고 빠른 데이터 압축 - 도마뱀 은 Brotli 또는 ZStandard만큼 압축률이 높지는 않지만 압축 비율이 다소 비슷하고 약간 빠릅니다 (적어도 속도에 관한 이 차트 에 따르면 압축 해제를보고하지만)
운영 체제에 대해서는 언급하지 않았습니다. Windows의 경우 ZStandard가 포함 된 7-Zip (릴리스) 은 이러한 모든 알고리즘 사용을 지원하도록 수정 된 7-Zip 버전입니다.
답변
zstd를 사용하십시오 . Facebook에 충분하다면 아마 당신에게도 충분할 것입니다.
더 진지하게 말하면 실제로는 꽤 좋습니다 . 나는 그것이 작동하기 때문에 지금 모든 것을 위해 사용하며, 대규모로 비율에 대한 속도를 교환 할 수 있습니다 (대부분 스토리지는 저렴하지만 속도는 병목 현상이므로 속도는 크기보다 중요합니다).
bzip2와 비슷한 전체 압축을 달성하는 압축 수준에서는 훨씬 빠르며 CPU 시간을 추가로 지불하려는 경우 LZMA와 비슷한 결과를 거의 얻을 수 있습니다 (그러나 bzip2보다 느릴 수 있음). 엄밀히 더 나쁜 압축 비율에서는 bzip2 또는 다른 주류 대안보다 훨씬 빠릅니다.
이제 SQL 덤프를 압축하고 있습니다. SQL 덤프는 압축하기가 너무 끔찍합니다. 가장 열악한 컴프레서조차도 이런 종류의 데이터에서 점수가 높습니다.
따라서 zstd
더 낮은 압축 수준으로 실행할 수 있습니다. 이 수준은 수십 배 더 빠르게 실행 되며 해당 데이터에서 동일한 압축률을 95-99 % 달성합니다.
또한이 작업을 자주 수행하고 추가 시간을 투자하려는 경우 zstd
압축기를 미리 “트레이닝”하여 압축 비율과 속도를 모두 높일 수 있습니다. 교육이 제대로 작동하려면 전체가 아닌 개별 레코드를 제공해야합니다. 도구가 작동하는 방식은 하나의 거대한 얼룩이 아니라 훈련을 위해 작고 다소 유사한 많은 샘플이 필요합니다.
답변
블록 크기를 조정 (낮게)하면 압축 시간에 큰 영향을 줄 수 있습니다.
다음은 내 컴퓨터에서 수행 한 실험 결과입니다. 내가 사용하는 time
실행 시간을 측정하는 명령을 사용합니다. input.txt
임의의 json 레코드를 포함하는 ~ 250mb 텍스트 파일입니다.
기본 (가장 큰) 블록 크기 사용 ( --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
문서화가 다음과 같이 말한 것을 고려하면 이것은 약간 놀라운 발견이었습니다.
압축 및 압축 해제 속도는 블록 크기에 거의 영향을받지 않습니다.