GNU/Linux에서 사용할 수 있는 프로세스 정보에 대해 몇 가지 질문이 있습니다.프로세스 파일 시스템. 이는 처음에는 애플리케이션에서 vmPeak, vmSize, vmRSS 및 vmHWM을 추출하려는 욕구 때문이었습니다.
/proc/<pid>/status사람이 읽을 수 있는 버전은 /proc/<pid>/stat기계가 읽을 수 있다는 가정으로 시작합니다.
kernel.org 댓글:
stat - 프로세스 상태
status - 사람이 읽을 수 있는 형식의 프로세스 상태
나는 깨달았을 때 이것이 옳지 않다는 것을 깨달았습니다.가상 피크에서만 구매하실 수 있습니다 /proc/pid/status.
/proc/pid/status실제로 여러 곳의 가치를 결합하고 그 자체의 가치를 일부 추가하는 것처럼 보입니다 .
우리가 /proc/pid/status사용할 이유가 있다면 /proc/pid/stat? 그것이 필요한 이유는 무엇입니까?
API가 두 개 있는 이유는 무엇입니까? 더 이상 /proc/pid/stat사용되지 않거나 유용할 수 있습니까?
stat동등하지 않습니다. 더 적은 수의 필드를 제공합니다. 구문 분석하기가 약간 더 쉽습니다(사용순진하게 하면 미묘한 오류가 발견될 수 있습니다.). stat를 사용하는 모든 프로그램은 상태를 사용하도록 쉽게 전환할 수 있습니다. 실제로 몇 개나 깨질 수 있습니까?
방금 두 가지 모두에 대해 파서를 작성했습니다(비록 API가 별로 유용하지 않았기 때문에 통계용으로 파서를 사용하게 되었지만). 기계가 읽을 수 있는 콘텐츠는 많지 않습니다. 실제로 "상태"에 대한 파서는 원하는 모든 종류의 키-값 저장소로 직접 읽을 수 있기 때문에 더 우아해집니다. 상태는 모든 언어에서 구문 분석하기가 더 쉽고 확장 가능합니다.
실제로 "상태" 대신 "상태"에 의존하는 프로그램은 몇 개입니까? 그들 중 실제로 이것이 제공할 수 있는 미미한 구문 분석 속도가 필요한 것이 있습니까?
이제 나는 이전 버전과의 호환성으로 인해 통계를 수년 동안 제거할 수 없다는 것을 이해하지만, 유지해야 할 합당한 이유가 없으면 "이제 더 이상 사용되지 않습니다"라고 말할 수 있습니다(이것이 내 질문에 대한 가능한 답변이 될 것입니다).
성능이 문제인 경우 가상 파일 시스템을 통해 이 커널 정보를 텍스트로 변환하고 다시 역으로 변환하는 성능은 라이브러리 호출 성능보다 확실히 낮습니다.
지속적으로 새로운 API를 추가하는 것은 짜증날 수 있습니다.이 답변제안이지만 대부분이 안정적이라는 점을 감안할 때 C 라이브러리 API가 없는 이유는 무엇입니까?시스템 메시지?
답변1
커널이 이전 버전과 의 호환성을 제공하는 이유는 /proc/…/stat단순히 이전 버전의 프로그램과 호환되는 것이 아니라 이전 버전과 호환되기 때문입니다. 지금 유틸리티를 빌드하면 다음 프로그램( , 등) procps이 생성됩니다.pspgreppidof아직 읽는 중/proc/…/stat.
하나할 수 있다procps대신 사용하는 것도 가능합니다 /proc/…/status. 이전 성능 매개변수는 더 이상 관련이 없으며 status커널에서 검색하는 데 검색과 같은 시간이 걸립니다 stat. 그러나 이는 사용자 공간 도구를 변경하지 않고 커널을 업데이트하려는 기존 시스템에는 도움이 되지 않습니다.
커널에 관한 한 이것은 예약되어 있습니다 stat.Linux 커널에는 사용자 공간을 절대 파괴하지 않는다는 정책이 있는 이유는 무엇입니까?
물론 당신은 단지 사용하거나 완전히 피하는 것을 자유롭게 선택할 수 /proc/…/status있습니다 /proc/…/stat. 나는 후자가 더 이상 사용되지 않는 것으로 간주되어야 한다는 일반적인 합의를 알지 못합니다. 논의된 적이 없으며(논의되지 않았다는 의미는 아닙니다) 더 이상 사용되지 않는 것으로 표시되지 않았습니다.매뉴얼 procfs페이지또는커널의 오래된 ABI 기호( /proc항목이 포함되어 있습니다). 어쩌면 그것은 단지 관성일지도 모릅니다. 더 많은 커널 개발자가 알아차릴 수 있는 서클에 이 문제를 제기한다면 분명히 거기에 있습니다.예의견 일치.
(내가 아는 한 의 일부 필드는 stat에서 사용할 수 없습니다. 적어도 프로세스 그룹 및 세션 ID는.)status
sysinfo인터페이스 스타일 에 관해 언제든지 제안할 수 있습니다. 텍스트 기반 인터페이스는 이전 버전과의 호환성을 유지하기 위해서만 사라지는 것이 아닙니다. Unix 스타일 시스템의 많은 텍스트 처리 도구에서 사용할 수 있는 형식으로 이 정보를 저장하는 것은 제거하기에는 너무 편리합니다.
답변2
https://lkml.org/lkml/2012/12/23/75
WE DO NOT BREAK USERSPACE!
이에 의존하는 stat오래된 유틸리티/응용 프로그램이 제거되지 않는 한 제거되지 않을 가능성이 높습니다.
그 중 하나를 사용하고 싶다면 그것은 당신의 선택입니다.
답변3
개인적인 의견이지만 /proc/pid/stat고려해 볼만하다고 생각합니다더 이상 사용되지 않음/proc/pid/status모든 상황에서 사용해야 합니다 .
stat구문 분석이 더 효율적이지 않으며 버그 및 심지어 보안 위험까지 초래할 수 있는 미묘한 위험이 있습니다(참조예를 들어 이). 또한 .보다 적은 수의 필드를 포함합니다 status.
바라보다: