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

Question

Ao procurar correspondências com grep , muitas vezes observo que a pesquisa subsequente leva tempo significativamente menor que a primeira - por exemplo, 25s vs. 2s Obviamente, não é reutilizando as estruturas de dados de sua última execução - essas deveriam ter sido desalocadas. Executando um comando time em grep , notei um fenômeno interessante:

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

Para onde vai o resto do tempo? Existe alguma coisa que eu possa fazer para que tudo corra rápido todas as vezes? (por exemplo, ter outro processo lê os arquivos antes de grep pesquisá-los.)

    

Answer 1

É quase sempre relacionado ao cache de páginas .

Na primeira vez, os dados devem ser lidos (fisicamente) no disco.

A segunda vez (para arquivos não muito grandes) é provável que esteja no cache de páginas.

Assim, você pode emitir primeiro um comando como cat (1) para trazer o (não muito grande) arquivo no cache da página (ou seja, na RAM), então um segundo grep (1 ) (ou qualquer programa que leia o arquivo) geralmente seria 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 de aplicação, mas praticamente raramente) readahead (2) & posix_fadvise (2) e talvez madvise(2) & sync (2) & fsync (2) etc ....

Leia também LinuxAteMyRAM .

BTW, é por isso que é recomendado, quando comparamos 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 seus dados).

Se você quiser entender mais, leia um livro como, por exemplo, Sistemas operacionais: Três peças fáceis

    

Answer 2

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

Aqui está um experimento apenas calculando uma soma de verificação dos dados do arquivo - não o grep. A primeira invocação é lenta e as subsequentes 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