Respuestas:
A partir de coreutils 8.6 (2010-10-15), GNU sort
ya se ordena en paralelo para hacer uso de varios procesadores donde estén disponibles. Por lo tanto, no se puede mejorar aún más en ese sentido como pigz
o pbzip2
mejorar gzip
o bzip2
.
Si sort
no es paralelo, puede intentar instalar GNU sort
desde la última versión de GNU coreutils .
Con GNU sort, puede limitar el número de subprocesos con la --parallel
opción.
Si su archivo es lo suficientemente grande, la ordenación provocará el intercambio de discos, ya sea porque la memoria virtual asignada está creciendo demasiado o porque el sort
programa en sí está intercambiando fragmentos en el disco y viceversa. sort
Es más probable que las implementaciones anteriores tengan este tipo de comportamiento de "ordenar a través del búfer de disco", ya que era la única forma de ordenar archivos grandes en los viejos tiempos.
sort
tiene una -m
opción que puede ayudarte aquí. Puede ser más rápido dividir el archivo en trozos, digamos con split -l
, ordenarlos de forma independiente, luego fusionarlos nuevamente.
Por otra parte, puede ser que esto es exactamente lo que hace "ordenar a través del búfer de disco". La única forma de averiguar si ayuda es compararlo con su carga de prueba particular. El parámetro crítico será el recuento de líneas que le dé split -l
.
split
y merge
y veré si ayuda.
merge(1)
tenga aplicabilidad aquí. Uso sort -m
.
sort --merge
.
Tuve una ganancia muy significativa usando sort -n
, que requiere valores numéricos (flotante o entero) en todas las columnas seleccionadas, sin notación científica.
Otra posibilidad que puede aportar una gran mejora en su proceso es utilizar la carpeta asignada de memoria /dev/shm
para tratar con archivos intermedios.
export LC_COLLATE=C
export LANG=C
cat big_file | sort > /dev/null
Usualmente, la ordenación de Linux hace algunas cosas ingeniosas para cumplir con las reglas de igualdad de Unicode ... si cambia la configuración regional a C, solo cambia a byte ...
Para un archivo de 1.4GB, la diferencia en mi máquina es 20s vs. 400s (!!!)
LC_ALL=C
sería suficiente?
LC_COLLATE
ya sea suficiente. AFAIK sort
utiliza strcoll
para comparar y la página de manual dice que el comportamiento depende deLC_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
el archivo se divide y ordena aumentará la velocidad de la clasificación