NetBSD grep이 후속 호출에서 거의 15배 느려지는 이유

NetBSD grep이 후속 호출에서 거의 15배 느려지는 이유

저는 APUE의 예제를 작업 중입니다. NetBSD 9.0 시스템에서 로드가 많지 않은 상태에서 호출 시간을 측정했는데 그다지 grep인상적이지 않은 결과를 얻었습니다.

apue$ cd /usr/include
apue$ time -p grep __POSIX_SOURCE */*.h > /dev/null
real         0.73
user         0.01
sys          0.63

그러나 실험을 여러 번 반복하면 시스템 시간이 극적으로 증가합니다(최대 15배).

apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         0.57
user         0.02
sys          0.54
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real        10.06
user         0.01
sys         10.04
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         3.57
user         0.01
sys          3.56
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         4.58
user         0.00
sys          4.58
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         5.56
user         0.02
sys          5.53
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         6.57
user         0.00
sys          6.56
apue$ time -p grep _POSIX_SOURCE */*.h > /dev/null
real         2.56
user         0.01
sys          2.54

이것이 예상되는 동작입니까? 이렇게 큰 차이가 발생하는 이유는 무엇입니까?

고쳐 쓰다 @Tim이 제공한 답변을 바탕으로 내 Buffercache를 살펴본 결과 grep이 검색에 어려움을 겪는 동안 100%로 완전히 할당되었음을 발견했습니다. 가상 머신을 다시 시작한 후 버퍼 사용량이 약 95%로 떨어졌습니다.

$ sysstat bufcache
                    /0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
     Load Average   |

      603 metadata buffers using                5565 kBytes of memory ( 0%).
    15512 pages for cached file data using     62048 kBytes of memory ( 3%).
     3034 pages for executables using          12136 kBytes of memory ( 1%).
     6460 pages for anon (non-file) data       25840 kBytes of memory ( 1%).
   468172 free pages                         1872688 kBytes of memory (93%).

File System          Bufs used   %   kB in use   %  Bufsize kB   %  Util %
/                          577  95        5378  97        5418  97      99

Total:                     577  95        5378  97        5418  97      99

답변1

읽기 캐시(파일 시스템 버퍼 캐시, buffercache(9) 참조)를 모두 소진하는 것이 가능합니까?

첫 번째 단계에서는 캐시가 대부분 비어 있으므로 페이지만 추가됩니다. 캐시가 가득 차면 캐시에서 제거해야 하는 페이지를 결정하기 위해 일종의 LRU(최근 사용) 알고리즘을 수행해야 합니다. 코드가 작업을 완료하려면 (추가) 시간이 필요합니다.

이러한 테스트를 수행하면서 메모리 상태를 모니터링하여 속도 저하가 여유 메모리가 0에 도달하는 것과 일치하는지 확인하세요.

관련 정보