프로세스의 메모리 사용량 정보를 얻어야 합니다. 나는 그것이 거기에 있을 수 있다는 것을 알고 있지만 /proc/${pid}/statm그것을 얻을 수 있는 시스템 기능이 있습니까? 파일을 구문 분석하는 것은 비효율적인 것 같습니다.
답변1
당신은 파일을 컨텍스트에서 벗어나게 하기 때문에 파일을 구문 분석하는 것이 비효율적이라고 잘못 생각합니다. 아래 정보는 /proc귀하가 요청한 경우에만 "생성"된다는 사실을 이미 알고 계실 것이며,아니요변경사항이 있을 때마다 업데이트됩니다. 따라서 이를 구문 분석해야 할 뿐만 아니라 커널이 이를 텍스트로 생성해야 합니다.
몇 바이트를 직접 long으로 읽는 것이 atoi()문자열을 호출하는 것보다 확실히 더 효율적입니다. 하지만 이를 시스템 호출이 수행되어야 하는 컨텍스트의 일부로 고려해야 합니다. 일부 파일 내용을 읽기 위해(또는 커널이 제공할 수 있는 일부 바이너리 API를 호출하기 위해) 실행되는 모든 추가 코드는 문자열 변환에 필요한 시간을 단축시킵니다.
커널 프로세스에는 일반 프로그램보다 이러한 데이터가 더 자주 필요하므로 해당 데이터를 얻기 위해 시스템 호출을 수행해야 하는 오버헤드가 없으며 이러한 데이터에 직접 액세스할 수 있습니다.
답변2
어떤 종류의 정보를 얻고 싶은지 언급하지 않았지만 Linux는 pmap <pid>Solaris 명령을 다시 구현합니다. 정확히 동일한 정보를 인쇄하지는 않지만 출력은 비슷합니다. Linux가 Solaris의 다양한 p* 명령을 더 많이 다시 구현했는지 확인하고 싶을 수도 있습니다. 흥미롭게 psig도 Linux는 이를 지원하지 않습니다.
보안상의 이유로 UNIX에 대한 특정 정보는 프로세스 자체에서만 사용할 수 있으며, 그 이상의 정보는 제한되어 있으며 일반적으로 ps유사한 프로그램에서만 사용할 수 있습니다.
일반적인 UNIX 철학은 함수를 통해 특별한 정보를 제공하는 것이며 ioctl(), 이는 /proc1980년대 후반에 첫 번째 구현이 작동했던 방식이었습니다. 각 프로세스는 /proc에 있는 파일이며 ioctl만이 이 파일에서 작동합니다. /proc가 도입되기 전에는 UNIX 사용자가 특별한 정보를 얻기 위해 커널 메모리를 자유롭게 읽어야 했으며 잠금이 없었기 때문에 관련 프로세스가 종료되거나 교체될 때 가비지가 발생할 수 있었습니다.
1980년에 UNOS(최초의 UNIX 복제본)는 ps 명령에 대한 getpsinfo() 시스템 호출을 구현했습니다. /proc추상 뷰의 더 나은 구현으로 볼 수 있습니다.
1990년대 중반, procfs-2는 프로세스를 디렉토리와 그 안에 있는 파일로 정의하여 복잡한 이진 데이터(예: /proc/<pid>/as주소 공간 파일)를 읽을 수 있도록 허용했습니다. 이 디렉터리 내의 다른 파일에는 사용할 수 있는 구조화된 바이너리 데이터(정의된 C 구조)가 있습니다 read()(예: /proc/<pid>/usage리소스 사용).
Linux는 procfs 및 procfs2 파일과 호환되지 않습니다. 경로 이름이 다르고 파일 내용이 다릅니다. /proc/<pid>/fd/Linux에 대한 AT&T procfs2 문서와 명백한 충돌이 있습니다.