Ответы:
Начиная с coreutils 8.6 (2010-10-15), GNU sort
уже сортирует параллельно, чтобы использовать несколько процессоров, где они доступны. Таким образом, он не может быть улучшен в этом отношении, как pigz
или pbzip2
улучшить gzip
или bzip2
.
Если у вас sort
нет параллели, вы можете попробовать установить GNU sort
из последней версии GNU coreutils .
С помощью сортировки GNU вы можете ограничить количество потоков с помощью --parallel
опции.
Одна вещь, которая всегда помогает мне больше всего в сортировке, - это выделение для нее как можно большего объема памяти, чтобы уменьшить обмен, например:
sort -S 20G
sort -S 50%
Если ваш файл достаточно велик, сортировка приведет к подкачке диска, либо из-за того, что выделенная виртуальная память становится слишком большой, либо из-за того, что 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 делает некоторые полезные вещи, чтобы соответствовать правилам равенства Unicode ... если вы измените локаль на C, она переключится только на байт ...
Для файла объемом 1,4 ГБ разница на моей машине составляет 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
Файл разбит и сортирует, это увеличит скорость сортировки