grep이 CPU를 실행하지 않을 때 무엇을합니까?

와 일치하는 항목을 찾을 때 grep종종 후속 검색이 첫 번째보다 훨씬 적은 시간 (예 : 25 초 대 2 초)을 발견합니다. 분명히, 그것은 마지막 실행에서 데이터 구조를 재사용하는 것이 아니라 할당이 취소 된 것이어야합니다. 에 time명령을 실행 grep하면 흥미로운 현상이 나타났습니다.

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

나머지 시간은 어디로 갑니까? 매번 빠르게 실행되도록 할 수있는 방법이 있습니까? (예 : 다른 프로세스가 파일을 grep검색 하기 전에 파일을 읽도록 합니다.)

그것은 종종 페이지 캐시 .

처음으로 디스크에서 데이터를 (물리적으로) 읽어야합니다.

두 번째로 (큰 파일은 아님) 페이지 캐시에있을 가능성이 높습니다.

따라서 먼저 cat (1) 과 같은 명령을 실행 하여 (너무 크지 않은) 파일을 페이지 캐시 (예 : RAM)로 가져온 다음 두 번째 grep (1) 을 가져올 수 있습니다. (또는 파일을 읽는 모든 프로그램)을 일반적으로 더 빠르게 실행할 수 있습니다. .

^{(그러나 여전히 디스크에서 데이터를 읽어야하는 경우가 있음)}

readahead (2) & posix_fadvise (2) 및 아마도 madvise (2) & sync (2) & fsync (2) 등을 참조하십시오 (때로는 응용 프로그램에는 유용하지만 실제로는 거의 발생하지 않습니다) .

LinuxAteMyRAM 도 읽으십시오 .

BTW, 프로그램을 벤치마킹 할 때 여러 번 실행하는 것이 좋습니다. 또한, 더 많은 RAM을 구입하는 것이 유용 할 수 있습니다 (데이터를 위해 모든 프로그램을 사용하는 프로그램을 실행하지 않더라도).

더 이해하려면 운영 체제 : Three Easy Pieces 와 같은 책을 읽으십시오 .

네트워크 스토리지 환경에서는 서버와 별도로 "파일러"에있는 파일에 처음 액세스 할 때 상대적으로 상당한 지연이있을 수 있습니다. 해당 파일이 서버에서 액세스되면 해당 파일은 로컬로 캐시되며 데이터에 대한 후속 액세스가 훨씬 빨라집니다.

다음은 grep이 아닌 파일 데이터의 체크섬을 계산하는 실험입니다. 첫 번째 호출은 느리고 후속 호출은 빠릅니다.

> 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