압축된 텍스트 파일에서 모든 일치 항목을 찾고 싶다고 가정해 보겠습니다.
$ gzcat file.txt.gz | pv --rate -i 5 | grep some-pattern
pv --rate여기서는 파이프라인 처리량을 측정하는 데 사용됩니다. 내 컴퓨터에서는 약 420Mb/s(압축 해제 후)입니다.
이제 GNU를 사용하여 병렬 grep을 병렬로 실행하려고 합니다.
$ gzcat documents.json.gz | pv --rate -i 5 | parallel --pipe -j4 --round-robin grep some-pattern
처리량은 이제 약 260Mb/s로 떨어졌습니다. 더욱 흥미로운 점은 parallel프로세스 자체가 CPU를 많이 사용한다는 것입니다. 프로세스 보다 많음 grep(그러나 미만 gzcat).
편집 1--block: 다양한 청크 크기( ), -N/ 옵션 -L값을 다르게 시도해 보았습니다 . 현재로서는 나에게 도움이 될 수 있는 것이 아무것도 없습니다.
내가 뭘 잘못했나요?
답변1
나는 당신이 GNU Parallel을 사용하고 있다는 사실에 정말 놀랐습니다 --pipe. 내 테스트의 최대 속도는 일반적으로 약 100MB/s입니다.
GNU Parallel에서는 병목 현상이 발생할 가능성이 높습니다. --pipe그다지 효율적이지 않습니다. --pipepart그러나 여기서는 CPU 코어당 1GB/s 정도를 얻을 수 있습니다.
안타깝게도 사용에는 몇 가지 제한 사항이 있습니다 --pipepart.
- 파일은 검색 가능해야 합니다(즉, 파이프가 없음).
- --recstart/--recend를 사용하여 레코드의 시작 부분을 찾을 수 있어야 합니다(즉, 압축 파일 없음).
- 행 번호를 알 수 없습니다(따라서 4행의 레코드가 있을 수 없음).
예:
parallel --pipepart -a bigfile --block 100M grep somepattern
답변2
grep은 매우 효율적입니다. 병렬로 실행할 필요가 없습니다. 명령에서 압축 해제에만 더 많은 CPU가 필요하지만 병렬화할 수는 없습니다.
입력을 병렬로 분할하려면 grep을 통해 일치하는 라인을 가져오는 것보다 더 많은 CPU가 필요합니다.
grep보다 라인당 더 많은 CPU가 필요한 것을 사용하려는 경우 상황이 달라집니다. 그러면 병렬화가 더 의미가 있습니다.
속도를 높이려면 병목 현상이 있는 위치를 확인하십시오. 압축을 풀거나(다른 압축 해제 도구나 더 나은 CPU를 사용하는 데 도움이 됨) 디스크에서 읽는 것이 좋습니다(다른 압축 해제 도구나 더 나은 디스크 시스템을 사용하는 데 도움이 됩니다).
내 경험에 따르면 lzma(예: -2)를 사용하여 파일을 압축/압축 해제하는 것이 더 나을 때도 있습니다. gzip보다 압축 비율이 높기 때문에 디스크에서 읽는 데 필요한 데이터가 훨씬 적고 속도도 비슷합니다.
답변3
여기서는 감압이 병목 현상이 됩니다. 압축 해제 내에서 병렬화가 없으면 직접 수행할 수 없습니다. 그러한 작업이 두 개 이상인 경우 물론 병렬로 시작할 수 있지만 파이프라인 자체는 병렬화하기 어려울 것입니다. 스트림을 병렬 스트림으로 분할하는 것은 거의 가치가 없으며 동기화 및 병합은 어려울 수 있습니다. 때로는 여러 코어가 실행 중인 모든 작업에 도움이 되지 않는다는 사실을 받아들여야 합니다.
일반적으로 말하면, 셸의 병렬화는 주로 독립적인 프로세스 수준에서 이루어져야 합니다.