O que o grep faz quando não está executando a CPU?

Ao procurar correspondências com grep, geralmente percebo que a pesquisa subsequente leva muito menos tempo que a primeira - por exemplo, 25s vs. 2s. Obviamente, não é reutilizando as estruturas de dados de sua última execução - elas deveriam ter sido desalocadas. Ao executar um timecomando grep, notei um fenômeno interessante:

real    24m36.561s
user    1m20.080s
sys     0m7.230s

Para onde vai o resto do tempo? Existe algo que eu possa fazer para que ele corra sempre rápido? (por exemplo, ter outro processo lendo os arquivos antes de greppesquisá-los.)

grep performance

— Alex
fonte

Respostas:

É frequentemente relacionado ao cache da página .

Na primeira vez, os dados precisam ser lidos (fisicamente) do disco.

Na segunda vez (para arquivos não muito grandes), é provável que ele esteja no cache da página.

Portanto, você pode emitir primeiro um comando como cat (1) para trazer o arquivo (não muito grande) para o cache da página (ou seja, na RAM) e, em seguida, um segundo grep (1) (ou qualquer programa que esteja lendo o arquivo) geralmente será executado mais rapidamente .

^{(no entanto, os dados ainda precisam ser lidos do disco em algum momento)}

Veja também (às vezes útil em seus programas aplicativos, mas praticamente raramente) readahead (2) e posix_fadvise (2) e talvez madvise (2) e sync (2) e fsync (2) etc ....

Leia também LinuxAteMyRAM .

BTW, é por isso que é recomendável, ao comparar um programa, executá-lo várias vezes. Além disso, é por isso que pode ser útil comprar mais RAM (mesmo que você não execute programas usando tudo isso para os dados).

Se você quiser entender mais, leia alguns livros como, por exemplo, Sistemas operacionais: três peças fáceis

— Basile Starynkevitch
fonte

Portanto, a TL;DRresposta é "[bloco aguardando] E / S".

— mgarciaisaia

@PaulDraper Não é realmente :) cat+ grepainda vai demorar mais do que grepsozinho.

— chepner

@chepner A menos que você possa multithread e usar catcomo uma pré-busca barata enquanto estiver fazendo outra coisa, na preparação para o grepinteresse.

— Hby2Py 12/07

@MarkKCowan: Gatos adoráveis! :-) ⁠

— G-Man diz 'Reinstate Monica'

@ G-Man: Você também pode substituir dois dos cats com tacpara o mesmo efeito e uso de RAM superior: D Ou todos os gatos com tac

— Mark K Cowan

-1

Em um ambiente de armazenamento em rede, também pode haver atrasos relativamente significativos quando você acessa pela primeira vez um arquivo que reside em um "arquivador" separado do servidor. Depois que o arquivo for acessado no servidor, ele será armazenado em cache localmente e o acesso subsequente aos dados será muito mais rápido.

Aqui está um experimento apenas computando uma soma de verificação dos dados do arquivo - não grep. A primeira invocação é lenta e as subseqüentes são rápidas.

> du -Dh file_348m
348M    file_348m

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

— Winston Smith
fonte

Eu gostaria de receber comentários por votos negativos, pois não sei como interpretá-los. Acredito que minha descrição da resposta esteja correta. Talvez o exemplo de comando não esteja claro? Ou você não gosta que eu não tenha comparado o comando grep? (Eu usei intencionalmente um simples comando, md5sum, para tentar ilustrar o meu ponto.)

— Winston Smith

Acho que o motivo é que sua postagem não adicionou nenhuma informação relevante ao que eu estava perguntando. Eu já sabia que havia um atraso, e a primeira resposta já dava uma explicação de por que está acontecendo. Mas sim, também recebo votos negativos sem explicação. Mesmo em perguntas com boas respostas.

— 18717 Alex

Obrigado @Alex por sugerir um motivo. Eu estava tentando distinguir entre o tempo de sobrecarga para mover dados do armazenamento local para a memória, descrito pela primeira resposta, e o tempo de sobrecarga para mover dados do armazenamento de rede para o servidor local. Pensarei se pudesse descrever isso mais claramente ou fornecer melhores exemplos de comando.

— Winston Smith

Acho que depois de ler sua postagem, penso que ainda é a sobrecarga de mover dados de onde quer que estejam armazenados para a memória. Seja do armazenamento em rede ou do armazenamento local, não importa - o Unix ainda o vê movendo-se de um diretório para a memória. ps-- parece que minha explicação está correta-- meu comentário com o motivo recebeu um voto positivo.

— 18717 Alex

Entendo, eu estava adicionando uma distinção que não é importante para o que você estava procurando. ESTÁ BEM. A propósito, votei seu comentário de modo que não resolva a questão do motivo da votação negativa. :-)

— Winston Smith