강력한 사람들이 strace나를 실망시켰습니다. 어떻게 이럴 수있어?
time foo디스플레이를 foo실행하는 데("실제") 몇 초가 걸리지만 사용자 공간("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
답변1
이 문제가 발생하는 일반적인 이유는 페이지 오류로 인해 프로세스가 차단되었기 때문입니다. 이는 메모리 매핑(일명)을 통해 수행되는 파일 읽기 또는 쓰기입니다 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가 필요한 오류입니다. minor페이지 오류는 훨씬 덜 중요합니다(단지 "TLB 누락"일 수도 있음).
inputs읽은 총 페이지 수인 것 같습니다 . 현재 파일 매핑 페이지는 항상 같은 크기인 것 같습니다. 대부분의 경우 4096바이트이지만 getconf PAGESIZE.
이는 약 290MB를 의미하며 이는 초당 100MB가 넘는 읽기 속도이며 저와 같은 하드 드라이브의 표준 속도입니다. 수수께끼가 풀렸습니다!
또한 이 프로세스에 대해 전체 유휴 CPU가 있다고 가정합니다. 그렇지 않으면 프로세스가 차단되어 다른 프로세스가 CPU를 포기할 때까지 기다릴 수 있습니다.
strace시스템 호출로 인해 프로세스가 커널에 들어갔다가 나가는 경우에만 표시됩니다. 또는 Unix 신호를 전달할 때. 그러나 strace전혀 표시되지 않는 다른 유형의 인터럽트도 있습니다 . 그래서 여기에는 다음이 포함됩니다
- 페이지 오류입니다.
- 타이머 인터럽트. 이는 현재 프로세스가 CPU에 할당된 시간 조각을 모두 소진했을 때 다른 프로세스로 전환하는 데 사용됩니다.