Odpowiedzi:
Począwszy od coreutils 8.6 (2010-10-15), GNU sort
sortuje już równolegle, aby korzystać z kilku procesorów, jeśli są dostępne. Tak więc nie można go dalej ulepszać pod tym względem, jak pigz
lub pbzip2
poprawić gzip
lub bzip2
.
Jeśli sort
nie jesteś równoległy, możesz spróbować zainstalować GNU sort
z najnowszej wersji jądra GNU .
Za pomocą opcji GNU sort można ograniczyć liczbę wątków za pomocą --parallel
opcji.
Jedyną rzeczą, która zawsze mi najbardziej pomaga w sortowaniu, jest zapewnienie jak największej ilości pamięci, aby ograniczyć zamianę, np .:
sort -S 20G
sort -S 50%
Jeśli plik jest wystarczająco duży, sortowanie spowoduje zamianę dysku, albo z powodu zbyt dużej ilości przydzielonej pamięci wirtualnej, albo dlatego, że sort
sam program zamienia fragmenty na dysk iz powrotem. Starsze sort
implementacje częściej zachowują się jak w przypadku „sortowania według bufora dysku”, ponieważ w przeszłości był to jedyny sposób sortowania dużych plików.
sort
ma -m
opcję, która może ci w tym pomóc. Szybsze może być podzielenie pliku na części - powiedzmy za pomocą split -l
- sortowanie ich niezależnie, a następnie scalenie ich z powrotem.
Z drugiej strony może się zdarzyć, że właśnie to robi „sortuj według bufora dysku”. Jedynym sposobem, aby dowiedzieć się, czy to pomaga, jest przetestowanie go pod kątem konkretnego obciążenia testowego. Najważniejszym parametrem będzie liczba linii, którą podasz split -l
.
split
i merge
i zobacz czy to pomaga.
merge(1)
miało to zastosowanie tutaj. Zastosowanie sort -m
.
sort --merge
.
Miałem bardzo znaczący zysk przy użyciu sort -n
, który wymaga wartości liczbowych (liczba zmiennoprzecinkowa lub liczba całkowita) we wszystkich wybranych kolumnach, bez notacji naukowej.
Inną możliwością, która może przynieść znaczną poprawę procesu, jest użycie folderu odwzorowanego w pamięci /dev/shm
do obsługi plików pośrednich.
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
Zwykle sortowanie w Linuksie robi kilka fajnych rzeczy, aby zachować zgodność z regułami równości Unicode ... jeśli zmienisz ustawienia regionalne na C, przełącza się tylko na bajty ...
W przypadku pliku 1,4 GB różnica na moim komputerze to 20s vs. 400s (!!!)
LC_ALL=C
wystarczy?
LC_COLLATE
już wystarczy. AFAIK sort
używa strcoll
do porównania, a strona mówi, że zachowanie zależy odLC_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
plik zostanie podzielony i posortowany, zwiększy to szybkość sortowania