일치하는 항목을 찾을 때 grep후속 검색에 첫 번째 검색보다 훨씬 적은 시간이 걸리는 경우가 종종 있습니다. 예를 들어 25초 대 2초입니다. 분명히 이것은 마지막 실행의 데이터 구조를 재사용하여 수행되지 않습니다. 해당 데이터 구조는 해제되어야 합니다. time에서 명령을 실행하면서 grep흥미로운 현상을 발견했습니다.
real 24m36.561s
user 1m20.080s
sys 0m7.230s
나머지 시간은 어디로 갔나요? 매번 더 빠르게 실행할 수 있는 방법이 있나요? (예를 들어 grep파일을 검색하기 전에 다른 프로세스에서 파일을 읽도록 합니다.)
답변1
그것은 종종 와 연관되어 있다페이지 캐시.
처음에는 데이터를 디스크에서 (물리적으로) 읽어야 합니다.
두 번째로(크기가 작은 파일의 경우) 페이지 캐시에 있을 수 있습니다.
따라서 먼저 다음과 같은 명령을 내릴 수 있습니다.고양이(1)(너무 크지 않은) 파일을 페이지 캐시(예: RAM)에 넣은 다음 두 번째정규식(1)(또는 파일을 읽는 모든 프로그램)은 일반적으로 더 빠르게 실행됩니다.
(그러나 때로는 디스크에서 데이터를 읽어야 하는 경우도 있습니다)
참조(때때로 애플리케이션에 유용하지만 드물게)미리 읽기(2)&posix_fadvise(2)아마도미친 웨스(2)&동기화(2)&동기화(2)등....
또한 읽어보세요리눅스AteMyRAM.
그런데, 프로그램을 벤치마킹할 때 여러 번 실행하는 것을 권장하는 이유도 바로 여기에 있습니다. 또한 이것이 더 많은 RAM을 구입하는 것이 유용할 수 있는 이유입니다(데이터 저장에 RAM을 모두 사용하지 않는 프로그램을 실행하는 경우에도 마찬가지입니다).
더 알고 싶다면 다음과 같은 책을 읽어보세요.운영 체제: 세 가지 간단한 부분
답변2
네트워크 스토리지 환경에서는 서버와 별도의 파일 관리자에 있는 파일에 처음 액세스할 때 상대적으로 큰 지연이 발생할 수도 있습니다. 파일이 서버에서 액세스되면 로컬로 캐시되며 이후 데이터 액세스가 훨씬 빨라집니다.
이는 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