bzip2가 너무 느립니다. 여러 코어를 사용할 수 있습니다

31

이 명령을 실행 중입니다.

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

시간이 너무 오래 걸립니다. 로 프로세스를 top봅니다. bzip2 프로세스는 한 코어의 약 95 %와 postgres 5 %를 사용합니다. wa항목은 낮다. 이는 디스크에 병목 현상이 없음을 의미합니다.

성능을 높이려면 어떻게해야합니까?

bzip2가 더 많은 코어를 사용하도록 할 수도 있습니다. 서버에는 16 개의 코어가 있습니다.

아니면 bzip2의 대안을 사용 하시겠습니까?

성능을 높이려면 어떻게해야합니까?

performance postgresql gzip

— 게 틀리
소스

8

레거시 이유로 인해 bzip2가 필요하지 않은 한, xz가 bzip2보다 더 나은 압축 / 시간을 제공하는 것은 제 개인적인 경험이었습니다. 또한 충분한 새로운 프로그램을 얻는다면 스레드되며 원하는 시간에 따라 시간과 메모리 사용량을 gzipish에서 대규모로 확장 할 수 있습니다.

— 퍼킨스

6

"pigz"는 또 다른 옵션입니다. bzip2 출력이 아닌 gzip 출력을 생성합니다. 그리고 기본적으로 모든 것은 gzip을 이해합니다.

— Criggie

bzip2 압축을 사용하는 GnuPG로 대칭 암호화를 시도 할 수 있습니다. 압축 수준이 가장 높더라도 알려지지 않은 이유로 압축하는 것보다 놀라 울 정도로 빠른 것 같습니다. GUI 기반의 정규 압축 프로그램의 효율성보다 알고리즘이 더 빠를 수 있습니다.

— Shule

2

대체 알고리즘의 요구 사항을 명시하지 않았습니다. Bzip2는 분할 가능합니다. 그게 당신에게 중요합니까?

— Martin Smith

7

" 성능을 높이려면 어떻게해야합니까? "-압축하지 않습니까? 실제로 압축이 필요하다고 말하지는 않으며,하지 말아야 할 일은 항상 일하는 것보다 빠릅니다. 디스크 병목 현상을 만듭니다.

— TessellatingHeckler

49

주변에는 많은 압축 알고리즘 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 답변 참조). brotliI 세 설정되도록 첨가의 압축 품질 설정은, 압축률과 속도에 매우 큰 영향을 미친다 ( q0, q1및 q11). 기본값은 q11이지만 매우 느리고 여전히 xz. q1그래도 아주 좋아 보인다; 와 동일한 압축 비율 gzip이지만 4-5 배 빠릅니다!

업데이트 : 추가 lbzip2(gmathts 설명을 참조) zstd테이블에 (조니의 코멘트) 및 압축 속도하여 분류. 큰 압축 비율 로 3 배 빠르게 압축 lbzip2하여 bzip2가족을 다시 달리게합니다 pbzip2! zstd또한 합리적인 것처럼 보이지만 brotli (q1)비율과 속도가 모두 중요합니다.

평범한 gzip것이 최선의 방법 이라고 내 원래 결론은 거의 바보처럼 보이기 시작했다. 유비쿼터스에도 불구하고 여전히 이길 수는 없습니다.)

— Marcelm
소스

1

훨씬 더 많은 알고리즘을 가진 비슷한 표를 보려면 mattmahoney.net/dc/text.html을 참조하십시오 .

— Dougal

1

@Dougal Fair 충분히. 내 테스트는 OP ( pg_dumpall출력) 와 유사한 데이터를 사용 하므로 아마도 좀 더 대표적 일 것입니다 :)

— marcelm

1

zstd는 로그 파일을 압축하기 위해 표에서 누락 된 또 다른 것입니다. 단일 코어 zstd 프로세스가 비슷한 압축 비율로 pbzip2의 16 개 코어를 능가한다는 것을 알았습니다.

— Johnny

1

lz4그건 lzop그렇고, 보다 약간 더 빠르고 효율적 입니다. 그러나 임베디드 시스템과 관련된 더 많은 RAM을 사용합니다.

— Daniel B

1

멀티 스레드 버전을 기꺼이 테스트하려는 경우 시도해 볼 수도 zstd -T4있습니다. 매우 빠른 설정의 경우 기본값 zstd -T4 -1인으로 시도해 볼 수 있습니다 . 테스트 한 설정일 수 있습니다. zstd-3

— Cyan

37

pbzip2를 사용하십시오.

매뉴얼은 말한다 :

pbzip2는 pthread를 사용하고 SMP 머신에서 거의 선형 속도 향상을 달성하는 bzip2 블록 정렬 파일 압축기의 병렬 구현입니다. 이 버전의 출력은 bzip2 v1.0.2 이상과 완전히 호환됩니다 (예 : pbzip2로 압축 된 항목은 bzip2로 압축 해제 할 수 있음).

보유한 프로세서 수를 자동으로 감지하고 그에 따라 스레드를 작성합니다.

— 토륨 BR
소스

파일을 압축하면 괜찮습니다. 파이프를 통해 끔찍하게 작동합니다.

— camelccc

@camelccc 왜 그렇게 말합니까? 나는 그것이 사실이 아니라고 생각합니다. 당신은 빠른 생산자 또는 최적의 성능을 위해 그것의 앞에 파이프에 큰 버퍼가 필요하지만의 동등하게 사실 pixz과 pigz파이프에뿐만 아니라.

— Michael-sqlbot

그가 압축하는 것이 얼마나 큰지에 달려 있습니다. 당신이 말한대로 큰 버퍼가 있다면 괜찮습니다. 물리적 램보다 훨씬 큰 것을 파이핑하는 경우 상황이 더 흥미로울 수 있습니다. 당신이 말한 것처럼 압축 알고리즘에 대해서는 아마 사실입니다.

— camelccc

4

bzip2는 상당한 양의 램을 사용할 수 있으므로 한 번에 16 개의 bzip 작업자를 실행하면 사소한 램을 1GB 이상 사용할 수 있습니다. BTW lbzip2는보다 나은 속도, 메모리 사용 및 약간 더 나은 압축을 제공하는 것 같습니다 pbzip2. 벤치 마크는 여기에 있습니다 : vbtechsupport.com/1614

— gmatht

@gmatht lbzip2는 좋아 보인다! 나는 내 대답에 그것을 추가했다 :)

— marcelm

8

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
- 압축 속도를 찾고 있다면 찾고있는 것은이 차트에서 어느 줄이 더 오른쪽에 있는지입니다. (이 차트의 맨 위에있는 항목은 압축 비율이 엄격함을 나타냅니다. 높을수록 더 빠릅니다. 그러나 압축 속도가 우선 순위 인 경우 차트에서 오른쪽에 도달하는 라인에 더주의를 기울이려고합니다.)
비교 : 7-Zip Z 표준 방법의 압축 비율과 압축 속도
Facebook의 ZStandard는 비트를 줄이기 위해 노력하지만 누락 된 예측을 줄이는 방식으로 데이터를 저장하는 데 중점을 두어 더 빠른 속도를 허용하는 또 다른 옵션입니다. 홈페이지는 다음과 같습니다 : ZStandard를 통한 더 작고 빠른 데이터 압축
도마뱀 은 Brotli 또는 ZStandard만큼 압축률이 높지는 않지만 압축 비율이 다소 비슷하고 약간 빠릅니다 (적어도 속도에 관한 이 차트 에 따르면 압축 해제를보고하지만)

운영 체제에 대해서는 언급하지 않았습니다. Windows의 경우 ZStandard가 포함 된 7-Zip (릴리스) 은 이러한 모든 알고리즘 사용을 지원하도록 수정 된 7-Zip 버전입니다.

— 투암
소스

흥미 롭습니다. brotli전에는 들어 봤지만 잊어 버렸습니다. 나는 그것을 대답의 벤치 마크 테이블에 추가했습니다! 나는 품질 설정 1을 제외하고는 성능에 약간 실망했습니다. 여기서 gzip훨씬 빠른 속도 와 동일한 압축 비율을 제공했습니다 .

— marcelm

2

zstd를 사용하십시오 . Facebook에 충분하다면 아마 당신에게도 충분할 것입니다.

더 진지하게 말하면 실제로는 꽤 좋습니다 . 나는 그것이 작동하기 때문에 지금 모든 것을 위해 사용하며, 대규모로 비율에 대한 속도를 교환 할 수 있습니다 (대부분 스토리지는 저렴하지만 속도는 병목 현상이므로 속도는 크기보다 중요합니다).
bzip2와 비슷한 전체 압축을 달성하는 압축 수준에서는 훨씬 빠르며 CPU 시간을 추가로 지불하려는 경우 LZMA와 비슷한 결과를 거의 얻을 수 있습니다 (그러나 bzip2보다 느릴 수 있음). 엄밀히 더 나쁜 압축 비율에서는 bzip2 또는 다른 주류 대안보다 훨씬 빠릅니다.

이제 SQL 덤프를 압축하고 있습니다. SQL 덤프는 압축하기가 너무 끔찍합니다. 가장 열악한 컴프레서조차도 이런 종류의 데이터에서 점수가 높습니다.
따라서 zstd더 낮은 압축 수준으로 실행할 수 있습니다. 이 수준은 수십 배 더 빠르게 실행 되며 해당 데이터에서 동일한 압축률을 95-99 % 달성합니다.

또한이 작업을 자주 수행하고 추가 시간을 투자하려는 경우 zstd압축기를 미리 "트레이닝"하여 압축 비율과 속도를 모두 높일 수 있습니다. 교육이 제대로 작동하려면 전체가 아닌 개별 레코드를 제공해야합니다. 도구가 작동하는 방식은 하나의 거대한 얼룩이 아니라 훈련을 위해 작고 다소 유사한 많은 샘플이 필요합니다.

— 데이먼
소스

더 나은 방법은 멀티 코어 머신에서 pzstd (병렬 버전)를 사용하는 것입니다.

— borowis

1

블록 크기를 조정 (낮게)하면 압축 시간에 큰 영향을 줄 수 있습니다.

다음은 내 컴퓨터에서 수행 한 실험 결과입니다. 내가 사용하는 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

문서화가 다음과 같이 말한 것을 고려하면 이것은 약간 놀라운 발견이었습니다.

압축 및 압축 해제 속도는 블록 크기에 거의 영향을받지 않습니다.

— 야 쿠브 쿠쿨
소스

내가 가장 좋아하는 것은 pbzip2입니다. 이것도 시도 했습니까? 이 질문은 16 개의 코어를 사용할 수있는 환경에 관한 것입니다.

— guettli

@guettli 불행히도 bzip을 고수해야합니다. 하둡 작업에 사용하고 있으며 bzip은 기본 제공 압축 중 하나입니다. 그래서 그것은 이미 병렬화되어 있습니다.

— Jakub Kukul