Відповіді:
Щодо 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, що вимагає числових значень (float або integer) у всіх вибраних стовпцях, без наукових позначень.
Ще однією можливістю, яка може принести значні покращення у вашому процесі, є використання папки, нанесеної на пам'ять, /dev/shmдля обробки файлів-посередників.
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
Як правило, Linux сортування робить деякі чудові речі, щоб відповідати правилам рівності Unicode ... якщо ви зміните локаль на C, він переходить лише на байт ...
Для файлу 1,4 ГБ різниця на моїй машині становить 20s проти 400s (!!!)
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
файл розділений і сортувати, це збільшить швидкість сортування