파일 분할 속도를 높이기 위해 splitGNU를 사용하여 Linux 명령을 실행할 수 있습니까 ?parallel
압축된 파일을 읽고 라인 수 또는 파일 크기에 따라 동일한 부분으로 분할합니다.
나는 다음과 같이 노력하고 있습니다 :
zcat file.gz | parallel --pipe --block 2000M 'gzip > {#}.gz'
답변1
습관. 첫째, 파일 분할은 CPU 바인딩이 아닌 IO 바인딩일 가능성이 높으므로 문제를 해결하기 위해 더 많은 CPU를 추가해도 도움이 되지 않습니다.
gzip 압축 풀기 자체는 병렬화될 수 있습니다 . unpigz --stdout대신 gzip을 사용하십시오 zcat. 그러나 병목 현상으로 인해 데이터가 파일에 기록되기 때문에 이것이 속도를 크게 높일 수 있을지 의문입니다.
분할 파이프라인의 출력 자체는 본질적으로 순차적 프로세스이므로 병렬화는 의미가 없거나 이론적으로도 가능합니다.
그러니 당신이 할 수 있는 가장 빠른 일은
SIZE=10G # 10 GB output splits
unpigz --stdout | split -b ${SIZE} - outputfile_suffix_
1. 사실 스트레스를 줄여라할 수 없다실제로 병렬화됨 - 본질적으로 순차적이기도 하지만 체크섬 계산 및 IO 처리가 압축 해제 스레드 외에 별도의 스레드에서 수행되므로 unpigz일반적으로 처리량이 약간 증가합니다.
답변2
지금 내 업데이트된 질문을 볼 수 있습니까? 이 접근 방식을 시도했는데 작동합니다.좀 빠른 것 같아
당신은 관찰하고있을 수 있습니다디스크 캐시Linux 운영 체제 에서 file.gz정보를 읽었습니다.디스크이는 시간이 걸리는 일입니다. 파일은 이미 RAM에 저장되어 있으므로 훨씬 빠릅니다. 콜드에서 부팅하기 로그인 후 가장 먼저 하는 일이 파일 분할을 시도하는 것이라면, 어떻게 하든 가장 오랜 시간이 걸리는 것 같습니다. 콜드에서 부팅하는 것은 아직 file디스크에서 읽혀지지 않았기 때문입니다. 이 작업이나 디스크에서 RAM으로 로드되는 다른 작업을 수행하면 file해당 작업이 훨씬 빨라집니다.
이는 시스템 속도, RAM 용량(16GB, 32GB, 768GB), 파일 크기 및 디스크 유형에 따라 혼란스러울 수 있습니다.
SSD 대신 구형 7200rpm HDD를 사용하는 서버(10GB 크기) 경험에 따르면 file.tar지연이 발생할 수 있습니다.분파일에 처음 액세스할 때 디스크 I/O로 인해 발생합니다.
아니요, 분할 coreutils 명령을 병렬화할 수 없다고 생각합니다.
만약 당신의표적일부 파일을 처리하고 가능한 한 빨리 실행되도록 하세요.만들다메모리 디스크.
mkdir /scratch
mount -t tmpfs -o size=100g tmpfs /scratch
cp /from_wherever/file.gz /scratch
# this copy from disk to /scratch will be the initial time penalty.
# adjust size=?g accordingly, needs to be less than system ram
일단 거기메모리 디스크후속 작업은 항상빠르게. cp /scratch/your_output /back_to_wherever_on_disk완료되면 이것이 RAM이고 재부팅 시 손실된다는 점을 인식하십시오.
답변3
파일이 아직 압축되지 않은 경우: 예.
parallel --pipepart -a bigfile --block 2G gzip '>{#}'
나중에 모든 부분을 병렬로 처리하고 싶을 것 같습니다. 이 경우 bigfile임시 파일로 분할하지 말고 GNU Parallel을 직접 사용하는 것이 좋습니다.
parallel --pipepart -a bigfile --block -1 myprocess data from stdin
각 CPU 코어를 1개의 부분으로 나누어 bigfile병렬로 처리합니다.