回答:
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
。
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
通常、Linuxの並べ替えは、Unicodeの等式規則に準拠するためにいくつかの気の利いたことを行います...ロケールを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
ファイルが分割されて並べ替えられると、並べ替えの速度が上がります