답변:
coreutils 8.6 (2010-10-15)부터 GNU sort
는 사용 가능한 경우 여러 프로세서를 사용하기 위해 이미 병렬로 정렬합니다. 따라서, 이와 관련하여 pigz
또는 pbzip2
개선 gzip
되거나 개선 될 수 없다 bzip2
.
sort
병렬이 아닌 경우 sort
최신 버전의 GNU coreutils 에서 GNU 를 시도하여 설치할 수 있습니다 .
GNU 정렬을 사용하면 --parallel
옵션 으로 스레드 수를 제한 할 수 있습니다 .
파일이 충분히 큰 경우 할당 된 가상 메모리가 너무 커지거나 sort
프로그램 자체가 청크를 디스크로 스왑 합니다. 오래된 sort
구현에서는 예전 에는 큰 파일을 정렬하는 유일한 방법 이었기 때문에 이러한 "디스크 버퍼를 통한 정렬"동작이있을 가능성이 높습니다.
sort
-m
여기에 도움이 될 수 있는 옵션이 있습니다. 파일을 덩어리로 나누는 것이 더 빠를 수 있습니다.split -l
-개별적으로 분류 한 다음 다시 병합하십시오.
다시, 이것이 "디스크 버퍼를 통한 정렬"이하는 것과 정확히 일치 할 수 있습니다. 도움이되는지 확인하는 유일한 방법은 특정 테스트로드에서 벤치마킹하는 것입니다. 중요한 매개 변수는 줄 수 split -l
입니다.
split
하고 merge
있으며 도움이되는지 확인합니다.
merge(1)
여기에 적용 가능한 것이 보이지 않습니다 . 사용하십시오 sort -m
.
sort --merge
.
sort -n
과학 표기법없이 선택된 모든 열에 숫자 값 (부동 또는 정수)이 필요한을 사용하여 매우 큰 이득을 얻었습니다 .
프로세스를 크게 향상시킬 수있는 또 다른 가능성은 메모리 매핑 폴더 /dev/shm
를 사용하여 중간 파일을 처리하는 것입니다.
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
일반적으로 Linux 정렬은 유니 코드 동등 규칙을 준수하기 위해 멋진 것들을 수행합니다 ... 로케일을 C로 변경하면 바이트로만 전환됩니다 ...
1.4GB 파일의 경우 내 컴퓨터의 차이는 20 대 400입니다 (!!!)
LC_ALL=C
충분하지 않습니까?
LC_COLLATE
이미 충분할 것 같습니다. AFAIK sort
는 strcoll
비교를 위해 사용 하고 맨 페이지는 동작이 다음에 의존한다고 말합니다LC_COLLATE
#! /bin/sh
#config MAX_LINES_PER_CHUNK based on file length
MAX_LINES_PER_CHUNK=1000
ORIGINAL_FILE=inputfile.txt
SORTED_FILE=outputfile.txt
CHUNK_FILE_PREFIX=$ORIGINAL_FILE.split.
SORTED_CHUNK_FILES=$CHUNK_FILE_PREFIX*.sorted
#Cleanup any lefover files
rm -f $SORTED_CHUNK_FILES > /dev/null
rm -f $CHUNK_FILE_PREFIX* > /dev/null
rm -f $SORTED_FILE
#Splitting $ORIGINAL_FILE into chunks ...
split -l $MAX_LINES_PER_CHUNK $ORIGINAL_FILE $CHUNK_FILE_PREFIX
for file in $CHUNK_FILE_PREFIX*
do
sort -n -t , -k 1,1 $file > $file.sorted &
done
wait
#echo "**********SORTED CHUNK FILES*********"
#echo $SORTED_CHUNK_FILES
#Merging chunks to $SORTED_FILE ...
sort -mn $SORTED_CHUNK_FILES > $SORTED_FILE
#Cleanup any lefover files
rm -f $SORTED_CHUNK_FILES > /dev/null
rm -f $CHUNK_FILE_PREFIX* > /dev/null
파일이 분할되어 정렬 속도가 빨라집니다.