2TB의 RAM이 있는 시스템이 있고 버퍼 크기를 1000G로 지정하는 150G 크기의 파일에 대해 정렬 명령을 실행하고 있습니다. Google에서 조사한 후에 "버퍼 영역 크기가 클수록, 성능이 좋을수록." 이것이 내가 실행한 명령이다
sort -rk2 --buffer-size=1000G master_matrix_unsorted.csv > master_matrix_sorted.csv
그런데 시간이 많이 걸리고 작업이 어떻게 진행되고 있는지 모르겠습니다.
이 작업에 대한 최적의 버퍼 크기가 얼마인지 알고 계십니까? 새로운 버퍼 크기로 이 작업을 다시 실행할 계획입니다.
답변1
운영 체제와 정렬 구현을 지정할 필요는 없습니다. GNU 정렬을 의미하는 것 같습니다. 또한 "많은 시간"이 얼마나 걸리는지, 얼마나 오래 걸릴 것으로 예상하는지 언급하지 않았습니다. 가장 중요한 것은 결정 요인이 될 I/O 하위 시스템 기능을 언급하지 않았다는 것입니다.
일반적인 SATA 드라이브의 전송 속도는 약 150MB/s입니다. 이 속도에서는 150GB 파일을 읽는 데 1000초(약 15분)가 걸립니다. 그것을 시도 $ time cat filename >/dev/null
하고 참조하십시오. 약 15분(또는 time cat
표시된 시간)이 괜찮다면 출력도 작성해야 하므로 해당 시간의 약 3배 안에 sort(1)이 작동하도록 할 수 있습니다.
데이터가 메모리에 적합하고 여분의 프로세서가 있으므로 속도 향상을 위한 최선의 옵션은 병렬 처리인 것 같습니다. 정보 페이지에 따르면 --buffer-size는 중요하지 않습니다.
...이 옵션은 초기 버퍼 크기에만 영향을 미칩니다. "정렬"에서 SIZE보다 큰 입력 행을 발견하면 버퍼가 SIZE를 초과합니다.
그리고 빠른 검색을 통해 GNU가 사용하는 것을 알 수 있습니다.병합 정렬, 이는 병렬화에 적합합니다.
GNU 정렬이 버퍼 크기를 결정하는 방법과 병렬 정렬에 사용하는 알고리즘을 정말로 알고 싶다면 언제든지 coreutils 소스 코드와 함께 제공되는 문서를 얻을 수 있습니다.
하지만 내가 당신이라면 귀찮게 하지 않을 거예요. 무엇을 사용하든 master_matrix_unsorted.csv
sort(1)은 확실히 작업에 적합하지 않습니다.
첫째, 언젠가는 CSV 구문이 정렬 이해를 훨씬 뛰어넘기 때문에 CSV 파일을 사용하면 실수를 하게 될 것입니다. 둘째, sort(1)은 두 번째 열뿐만 아니라 (길이가 불확실한) 전체 행을 정렬해야 하기 때문에 가장 느린 방법입니다. 셋째, 일을 마치면 무엇을 얻나요? ㅏ정렬됨CSV 파일. 이게 정말 더 좋은 걸까요? 왜주문하다그게 그렇게 중요한가요?
정렬은 해당 목표를 향한 한 단계처럼 들리며 필요한 데이터에 대한 일종의 계산이 포함될 수 있습니다.숫자바이너리 형식으로. 이 경우 CSV 파일을 보다 관리하기 쉽고 계산 가능한 형식으로 변환할 수 있습니다.바이너리먼저 DBMS에서 포맷을 수행합니다. 최종 목표의 우선순위를 정하는 것이 불필요하다는 것을 알 수 있습니다.