Risposte:
A partire da coreutils 8.6 (15-10-2010), GNU sortordina già in parallelo per utilizzare diversi processori ove disponibili. Quindi, non può essere ulteriormente migliorato in tal senso come pigzo pbzip2migliorare gzipo bzip2.
Se sortnon sei parallelo, puoi provare a installare GNU sortdall'ultima versione di GNU coreutils .
Con l'ordinamento GNU, è possibile limitare il numero di thread con l' --parallelopzione.
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 sortprogramma stesso sta scambiando blocchi su disco e viceversa. Le sortimplementazioni 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.
sortha -mun'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.
splite mergeper 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/shmper 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=Csarebbe abbastanza?
LC_COLLATEè già abbastanza. AFAIK sortutilizza strcollper 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