Risposte:
A partire da coreutils 8.6 (15-10-2010), GNU sort
ordina già in parallelo per utilizzare diversi processori ove disponibili. Quindi, non può essere ulteriormente migliorato in tal senso come pigz
o pbzip2
migliorare gzip
o bzip2
.
Se sort
non sei parallelo, puoi provare a installare GNU sort
dall'ultima versione di GNU coreutils .
Con l'ordinamento GNU, è possibile limitare il numero di thread con l' --parallel
opzione.
Se il tuo file è abbastanza grande, l'ordinamento causerà lo scambio del disco, sia perché la memoria virtuale allocata sta diventando troppo grande, sia perché il sort
programma stesso sta scambiando blocchi su disco e viceversa. Le sort
implementazioni precedenti hanno più probabilità di avere questo tipo di comportamento "ordinamento tramite buffer del disco", poiché era l'unico modo per ordinare file di grandi dimensioni ai vecchi tempi.
sort
ha -m
un'opzione che può aiutarti qui. Potrebbe essere più veloce dividere il file in blocchi - diciamo con split -l
- ordinarli in modo indipendente, quindi unirli di nuovo insieme.
Inoltre, può darsi che questo sia esattamente ciò che fa "ordina tramite buffer del disco". L'unico modo per scoprire se è di aiuto è confrontarlo sul proprio carico di prova specifico. Il parametro critico sarà il conteggio delle righe assegnato split -l
.
split
e merge
per vedere se aiuta.
merge(1)
abbia applicabilità qui. Usa sort -m
.
sort --merge
.
Ho avuto un guadagno molto significativo usando sort -n
, che richiede valori numerici (float o intero) in tutte le colonne selezionate, senza notazione scientifica.
Un'altra possibilità che potrebbe apportare un notevole miglioramento al processo è quella di utilizzare la cartella mappata in memoria /dev/shm
per gestire i file intermedi.
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
Solitamente l'ordinamento Linux fa alcune cose ingegnose per conformarsi alle regole di uguaglianza Unicode ... se si modifica la locale in C si passa solo al byte ...
Per un file da 1,4 GB la differenza sulla mia macchina è 20s contro 400s (!!!)
LC_ALL=C
sarebbe abbastanza?
LC_COLLATE
è già abbastanza. AFAIK sort
utilizza strcoll
per il confronto e la manpage dice che il comportamento dipende daLC_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
il file viene suddiviso e ordinato aumenterà la velocità di ordinamento