Qual deve ser o tamanho do buffer para o comando sort?

7

Eu tenho uma máquina com 2 TB de RAM e estou executando um comando de classificação em um arquivo de tamanho 150G onde especifiquei o tamanho do buffer como 1000G, depois de fazer minha pesquisa no google, recebi este pedaço de informação "quanto mais é o tamanho do buffer, melhor é o desempenho". Este é o comando que eu corri

sort -rk2 --buffer-size=1000G master_matrix_unsorted.csv > master_matrix_sorted.csv

Mas isso está demorando muito e eu não tenho ideia do progresso da tarefa.

Alguma idéia sobre qual deve ser o melhor tamanho de buffer para esta operação? Estou planejando executar novamente essa tarefa com um novo tamanho de buffer.

    
por Sambit Tripathy 23.07.2014 / 00:55

2 respostas

3

Você não especifica o SO e a implementação de classificação; Eu suponho que você quer dizer tipo GNU. Você também não diz quanto tempo "muito tempo" é, ou quanto tempo você espera que ele leve. Mais importante, você não menciona a capacidade do subsistema de E / S, que será o fator governante.

Uma unidade SATA comum oferece ~ 150 MB / s. A essa taxa, seu arquivo de 150 GB levará apenas 1000 segundos para ler, cerca de 15 minutos. Experimente $ time cat filename >/dev/null para ver. Se ~ 15 minutos (ou seja o que for que time cat mostra) está OK, você pode conseguir que a ordenação (1) funcione em cerca de 3 vezes, porque a saída também deve ser escrita.

Sua melhor aposta para acelerar parece ser - paralela, porque seus dados se encaixam na memória e você tem processadores de reserva. De acordo com a página de informações, --buffer-size não importa, porque

... this option affects only the initial buffer size. The buffer grows beyond SIZE if 'sort' encounters input lines larger than SIZE.

Considerando que uma pesquisa rápida indica que o GNU usa merge sort , que é passível de paralelização.

Se você realmente quer saber como a classificação GNU determina os tamanhos de buffer e qual algoritmo usa para a classificação paralela, o código-fonte coreutils e a documentação que o acompanha estão prontamente disponíveis.

Mas se eu fosse você, não me incomodaria. O que quer que você esteja fazendo com master_matrix_unsorted.csv , sort (1) certamente não está à altura da tarefa.

Primeiro, um arquivo CSV o atrapalhará um dia, porque a sintaxe CSV está muito além do limite de classificação. Segundo, é a maneira mais lenta possível, porque sort (1) é forçado a ordenar linhas inteiras (de comprimento indeterminado), não apenas a segunda coluna. Terceiro, quando estiver pronto, o que você terá? Um arquivo CSV classificado . Isso é realmente melhor? Por que a ordem é tão importante?

A classificação soa como um passo no caminho em direção a uma meta que provavelmente inclui algum tipo de cálculo nos dados, cuja computação exigirá números em formato binário. Se for esse o caso, você também pode colocar o arquivo CSV em um formato mais binário mais fácil de ser computado, computável, digamos, em um SGBD. Você pode achar que a classificação acaba sendo desnecessária para o objetivo final.

    
por 27.07.2014 / 01:43
0

Como o tamanho do buffer de # sort é calculado é mencionado aqui. Isso pode lhe dar uma idéia. Não tenho certeza se isso resolverá seu problema. Mas vale a pena ler. Isto é mencionado tendo em mente o mysqldb, também pode ser aplicado o mesmo cenário que o seu.

Cálculo do tamanho do buffer SORT

    
por 26.07.2014 / 17:39

Tags