왜 strace는이 프로세스가 무언가를 기다리고 있다는 것을 보여주지 않습니까?

위력 strace이 나를 실망시켰다. 이것이 어떻게 가능한지?

time foofoo실행 하는 데 몇 초가 걸리지 만 ( "실제") 사용자 공간 ( "user")과 커널 ( "sys") 모두에서 무시할 수있는 CPU 시간을 사용합니다. 궁금한 점 foo은 아래에 정의되어 있습니다.

따라서 CPU 명령을 실행하지 않고 다른 것을 기다리는 데 대부분의 시간을 소비합니다. 일반적으로 대기 상태, strace즉 어떤 시스템 호출이 오랫동안 차단 되는지 확인할 수 있습니다 . 불행히도이 방법은 효과가 없었습니다.

strace -ttt -T -C -w foo시스템 호출, 타임 스탬프 및 시스템 호출에 소요 된 (실시간) 시간 요약을 보여줍니다. 그러나이 특정 프로세스는 시스템 호출 내부에서 무시할 수있는 전체 (실시간) 시간을 소비하는 것으로 나타났습니다.

foo실제로 journalctl -b -u dev-hugepages.mount입니다. 이것을 재현하기 위해 매번 마지막 인수를 다른 시스템 단위로 변경해야한다는 것을 제외하고. 다시 말해, 내가 조사하고있는 지연은 시스템 단위의 로그 하나를 처음으로 얻으려고 할 때 발생했습니다. 편집 : 주요 질문에 대답 한 후, 나는 이 문제가 지연을 재현하는 이유를 깨달았습니다 .

이 프로세스에 소요되는 시간은 특정 문제이며 모든 시스템에서 발생하는 것은 아닙니다. https://github.com/systemd/systemd/issues/7963

이 문제가 발생하는 일반적인 이유는 프로세스가 페이지 결함을 차단하고 있기 때문입니다. 이것들은 일명 메모리 매핑을 통해 수행되는 파일에 대한 읽기 또는 쓰기 mmap()입니다. mmap()시스템 호출 추적에서 일부 를 발견했을 수 있습니다 .

쉘 내장 /usr/bin/time대신에 프로그램 을 사용했다면 다음 과 같은 time사실을 알 수있을 것입니다.

0.04user 0.10system 0:02.29elapsed 6%CPU (0avgtext+0avgdata 40464maxresident)k
73632inputs+0outputs (376major+1081minor)pagefaults 0swaps

major페이지 오류는 파일 시스템 IO가 필요한 페이지 오류입니다. minorpagefaults는 훨씬 덜 중요합니다 (아마도 "TLB miss").

inputs읽은 총 페이지 수가 의심 됩니다. 현재 파일 매핑 페이지는 항상 같은 크기라고 생각합니다. 대부분의 경우 4096 바이트이지만 확인할 수 있습니다 getconf PAGESIZE.

따라서 이것은 ~ 290MB를 나타냅니다. 초당 100MB 이상으로 읽습니다. 이는 내 하드 디스크의 표준 속도입니다. 미스터리 해결!

또한이 프로세스에 사용 가능한 전체 CPU가 있다고 가정합니다. 그렇지 않으면 다른 프로세스가 CPU를 생성하기를 기다리는 동안 프로세스가 단순히 차단 될 수 있습니다.

strace시스템 호출로 인해 프로세스가 커널에 들어갔다가 떠날 때만 표시됩니다. 또는 유닉스 신호가 전달 될 때. 그러나 strace전혀 표시되지 않는 다른 유형의 인터럽트가 있습니다. 그래서 이들은 포함

• 페이지 결함.
• 타이머 인터럽트. 현재 프로세스가 할당 된 타임 슬라이스를 CPU에서 소진 한 경우 다른 프로세스로 전환하는 데 사용됩니다.