[리눅스 커널 이야기] top로 보는 프로세스 정보(1), virt, res, shr, memory commit, page fault, page table
프로세스 정보 확인
$ top #시스템 상태 확인
- 별도 명령어 없을 경우 디폴트 interval 3초
$ top -b -n 1 #batch 모드로 top 명령어를 1번 수행한다.
1. top - 15:07:14 up 45 days, 5:20, 1 user
- 현재 서버 시간 및 서버 구동 시간 (up days), 1명의 user 로그인 중
2. load average: 0.00, 0.01, 0.05
- Load Average : 현재 시스템이 얼마나 많은 일을 하고 있는지 보여주는 데이터, Load Average 높으면 서비스가 많은 일 하는 중
3. 현재 시스템에서 구동 중인 프로세스의 수 (뒤에서 좀 더 자세히 설명할거라 대략적으로만)
- total: 전체 구동중인 프로세스
- running : 실행중인 프로세스
- sleeping : 대기중인 프로세스, 요청하면 바로 수행 가능한 프로세스
- stopped : 구동 중지된 프로세스
- zombie : 부모 프로세스가 죽은 자식 프로세스
4. cpu, memory, swap 사용량
5. 프로세스의 상세 정보
- PID (Process ID): 프로세스를 구분하기 위한 고유 ID
- USER : 계정 정보
- PR(Priority) : 프로세스의 우선 실행 순위. 값이 낮을 수록 우선순위가 높음
- NI(Nice): PR값을 조절하기 위한 값. 실제 PR값 = PR + NI.
- VIRT(Virtual) : virtual memory value
- RES(resource) : Physical memory value
- SHR(Shared) : Shared memory value
- S(status) : 프로세스의 상태 정보 (D, R, S, T, Z 등등)
- VIRT, RES, SHR을 좀 더 자세히 보자
- RES : 실제 물리 메모리 영역. 해당 RES 값이 높은 메모리가 실제 물리 메모리 점유율이 높은 프로세스
- VIRT: 실제로 할당되지 않은 가상의 공간. 커널로부터 사용을 예약 받은 메모리
- SHR : 대표적으로 라이브러리가 포함됨. 대부분의 리눅스 프로세스들은 glibc 라이브러리를 참조, 모든 프로세스가 glibc 라이브러리를 메모리에 올리면 비효율적임. 커널은 이런 비효율을 해결하기 위해 공유 메모리 개념을 도입
- VIRT 할당 방식
Memory Commit : 프로세스가 커널에게 메모리를 요청하면, 커널은 가용 공간이 있는지 확인 후, 프로세스에게 사용할 수 있는 메모리 주소를 전달한다. 이 때, 실제 물리 메모리가 할당된 것이 아니라 가상 메모리 주소를 전달해 준 것이다. 해당 영역을 프로세스에 주었다고 해당 주소를 저장해 둔 과정.
Page Fault : 프로세스가 할당받은 메모리 영역에 실제로 write 작업을 수행하면 page fault가 발생한다. 이 때, 커널은 실제 물리 메모리에 프로세스의 가상 메모리 공간을 매핑한다. 매핑 정보는 Page Table 이라는 커널의 전역 변수로 관리되며, 물리 메모리에 바인딩 된 영역이 RES다.
그러면 VIRT는 물리 메모리 값에 상관 없이 무한대로 할당 받을 수 있을까?
-> 커널 파라미터 중 vm.overcommit_memory 파라미터에 의해 무한대로 할당받을 수도, 제약을 둘 수도 있다.
왜 커널은 메모리 요청 시 즉시 할당해주지 않고 memory commit을 사용할까?
-> 프로세스 생성 시, fork() 와 같은 시스템 콜을 사용.
fork() -> exec() 시스템 콜을 통해 완전히 새로운 프로세스로 변환. 이러면 확보한 메모리 영역이 쓸모 없어짐
그래서 COW(Copy-On-Write)를 통해 복사된 메모리 영역에 실제 쓰기 작업이 발생하면 그제서야 실제 메모리 할당 시작함
* fork() : 해당 시스템콜을 호출한 부모 프로세스 공간 데이터를 모두 복사(copy)
* exec() : 해당 시스템콜을 호출한 프로세스 공간을 새로 덮어 씌움
참조
강진우, DevOps와 SE를 위한 리눅스 커널 이야기, 인사이트, 2017, Chapter02