Linux 시스템에는 100GB 이상의 파일이 있으며 다음 명령을 사용하여 gzip을 시도할 때 gzip을 완료하는 데 최소 1-2시간이 걸립니다.
gzip file.txt
gzip을 사용할 때와 동일한 압축 수준으로 gzip을 빠르게 실행하는 방법이 있습니까?
CPU: Intel(R) Core(TM) i3-2350M CPU @2.30GHz
답변1
gzip을 사용하는 경우 주로 하나의 프로세서 코어를 사용하게 됩니다. 데이터 읽기 및 쓰기와 같은 일부 작업은 커널 작업이고 커널은 다른 코어를 사용합니다. MiGz(https://github.com/linkedin/migz) 또는 돼지 (https://zlib.net/pigz/, 더 자세한 설명은 다음을 참조하세요.https://medium.com/ngs-sh/pigz-a-faster-alternative-to-gzip-for-big-files-d5909e46d659).
답변2
100GB 이상의 파일이 있고 다음 명령을 사용하여 gzip을 시도하면 gzip을 완료하는 데 최소 1-2시간이 걸립니다.
CPU 사용(댓글에서 가져옴):인텔® 코어™ i3-2350M @ 2.30GHz, 포함:
코어 수: 2;스레드 수: 4
다음 데이터에 따르면 CPU에 병목 현상이 있는 것 같습니다.점수가 너무 낮네요(벤치마크) 또한 이것은 꽤 오래된 노트북 CPU라는 점에 유의하세요. 이 설정에서는 최신 SSD가 아닌 클래식 HDD와 RAM이 더 낮은 등을 기대합니다.
gzip결론은 아마도 '아니요'일 것입니다. 물론 압축률을 낮추지 않고 컴퓨터에서 더 높은 성능을 얻기 위해 소프트웨어에서 할 수 있는 일은 없습니다.
-6내가 정확하게 기억한다면 기본 압축 설정은 다음과 같습니다.예를 들어 다음을 입력할 수 있습니다.-2:
gzip -2 file.txt
그리고 그 결과를 직접 비교해 보세요. 보다매뉴얼 페이지설정에 대해 자세히 알아보세요.
업데이트 날짜pigz
2021년 6월 3일 오늘, 저는 256GB 크기의 다소 큰 파일을 압축해야 했습니다.239 깁스), 몇 가지 테스트를 실행했는데 gzip, 모두 내 CPU를 완전히 활용하지 못하는 것으로 나타났습니다(bzip2xzi7-7700HQ) 빠르고 이것이 이 Q&A의 목표입니다.
마지막으로 다운로드했습니다 pigz(매뉴얼 페이지) 어떤에서홈페이지를 실행하고 간단히 컴파일한 make다음 내 파일에 직접 넣는 것을 좋아하지 않았기 때문에 PATH바이너리에 대한 Bash 별칭을 만들었습니다.
(잠재적으로 긴) 진행 상황을 관찰하는 방법을 기록해 두는 것이 유용할 수 있습니다.
예제 #1(준비된 디스크 이미지를 읽고 gzip동일한 디렉터리에 'ed 파일 쓰기):
file=disk.img; pv < "$file" | pigz -2 > "$file".gz
예제 #2(디스크에서 직접 읽고 gzip현재 디렉터리에 'ed 파일 쓰기):
dev=/dev/nvme0n1; file=disk.img.gz; pv < "$dev" | pigz -9 > "$file"
결론적으로
이제 다음을 pigz사용하는 것이 좋습니다.피알라렐나구현광저우ip, 매우 큰 파일의 경우.
답변3
특별히 gzip이 필요합니까, 아니면 선택할 수 있는 다른 압축 알고리즘이 있습니까? zstandard와 lzop은 모두 gzip보다 훨씬 빠릅니다.
답변4
병목 현상은 파일을 읽는 속도, 파일을 압축하는 속도, 파일을 쓰거나 대상 매체(아마도 네트워크를 통해)로 전송할 수 있는 속도입니다.
가장 먼저 해야 할 일은 gzip 명령을 실행하고 출력을 모니터링하는 것입니다.
vmstat 1
다른 터미널에서. CPU가 최대치에 도달했는지, 사용 중인 코어 수, 읽고 쓰는 초당 MB 수를 확인할 수 있습니다. 또한 대용량 파일을 복사할 때 vmstat를 모니터링하여 하드 드라이브의 최대 읽기/쓰기 속도를 알아보세요. 그러면 작업이 CPU 바인딩인지 io 바인딩인지 알 수 있습니다.
당신은 또한 사용할 수 있습니다
time gzip ...
총 시간 대비 사용 중인 CPU 시간을 알려주며, CPU 바인딩인지 IO 대기인지에 대한 유용한 힌트를 제공합니다.
압축된 파일을 다른 하드 드라이브나 네트워크를 통해 전송하려는 경우 별도의 복사 작업을 사용하는 것보다 파일을 압축하는 동안 수행하는 것이 좋습니다. 대상 드라이브가 로컬인 경우 적절한 gzip 구문을 사용하고, 원격인 경우 네트워크 공유를 사용하거나 다음을 수행할 수 있습니다.
gzip -c file.txt | ssh user@ip "cat > destfile.gz"
이는 파일을 gzip으로 압축하고 단일 파이프 작업을 통해 전송하며, 이는 별도의 두 단계보다 빠릅니다.
이제 vmstat를 관찰하여 작업이 io 바인딩, 네트워크 바인딩 또는 CPU 바인딩인지 확인하세요. "pv" 유틸리티를 설치하고 다음과 같이 사용하는 것이 좋습니다.
gzip -c file.txt | pv | ssh user@ip "cat > destfile.gz"
pv는 네트워크를 통해 전송된 압축 데이터의 MB/s 수를 표시합니다. 다음 명령을 사용하여 HDD 읽기, 네트워크 및 상대방 쓰기를 테스트할 수 있습니다.
cat file.txt | pv | ssh user@ip "cat > destfile.gz"
하드 드라이브 네트워크를 테스트하고 다른 쪽 끝에 쓸 수 있습니다.
cat /dev/zero | pv | ssh user@ip "cat > destfile.gz"
...다음을 사용하여 네트워크를 테스트할 수 있습니다.
cat /dev/zero | pv | ssh user@ip "cat > /dev/null"
이제 무엇이 당신의 속도를 늦추는지 더 잘 알게 될 것입니다. Samba 네트워크 공유를 사용하는 경우 처리량도 테스트해야 합니다.
cat /dev/zero | pv > /mnt/share/filename
...잘못된 구성으로 인해 네트워크 공유 성능이 저하될 경우를 대비해 알아두는 것이 좋습니다.
문제가 실제로 gzip의 속도라고 판단되면 해결책은 zstandard와 같은 더 빠른 멀티스레드 압축기를 사용하는 것입니다. 몇 시간을 절약하는 것보다 몇 기가바이트의 하드 드라이브 공간을 절약하는 것이 더 중요할 수 있으므로 더 빠른 압축 설정을 사용할 수도 있습니다.
압축 파일의 크기가 압축에 필요한 시간보다 덜 중요한 경우 가장 좋은 솔루션은 디스크 또는 네트워크 병목 현상을 포화시킬 만큼 빠른 속도로 압축하는 것입니다.
예를 들어, 네트워크가 느리고 디스크가 빠르며 여유 CPU가 있는 경우 높은 압축 설정을 사용하면 더 적은 양의 압축된 데이터를 전송하여 속도가 빨라집니다. 그러나 네트워크가 빠르고 CPU가 느린 경우 압축 설정을 낮추면 CPU를 덜 사용하므로 속도가 빨라집니다.
그렇다면 이 100GB 파일은 어디서 오는 걸까요? 이는 일반적인 파일 크기가 아닙니다. 이는 실제로 증분 모드에서 rsync를 사용해야 함을 의미합니다.