Skip to content

Commit

Permalink
[Meet-Coder-Study#533] top 명령어를 통한 프로세스 정보 확인
Browse files Browse the repository at this point in the history
  • Loading branch information
sandartchip authored Feb 18, 2021
1 parent fe2bd72 commit 5a993d4
Showing 1 changed file with 65 additions and 0 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
리눅스에는 시스템의 상태를 살펴볼 수 있는 다양한 명령이 있다.
top 명령은 시스템의 상태를 전반적으로 가장 빠르게 파악할 수 있는 명령 중 하나이다.

## 2-1 시스템의 상태 살피기

top명령은 옵션없이 입력하면 주어진 Interval(기본 3초)으로 화면을 갱신하면서 정보를 보여준다.

![](https://images.velog.io/images/sandartchip/post/326e5119-7902-48ec-b543-9bd0ec1d206b/image.png)


### cf) top 명령어를 통한 프로세스 정보

![](https://images.velog.io/images/sandartchip/post/78d7a382-65e5-495d-9ef2-989a66dbb78a/image.png)

### cf) 프로세스 상태 코드

![](https://images.velog.io/images/sandartchip/post/abae3b5d-99d8-484e-aa24-d4fbe10176be/image.png)
## 2-2. VIRT, RES, SHR


SHR의 구체적인 예에는 라이브러리가 있다.
대부분의 리눅스 프로세스들은 glibc라는 라이브러리를 참조하기 때문에 사용하는 프로세스마다 glibc의 내용을 메모리에 올려서 사용하는 것은 공간 낭비다.

커널은 이런 경우를 대비해서 공유 메모리라는 개념을 도입했고, 다수의 프로세스가 함께 사용하는 라이브러리는 공유 메모리 영역에 올려서 함께 사용하도록 구현했다.

VIRT는 실제로는 할당되지 않은 가상의 공간이기 때문에 해당 값이 크다고 해도 문제가 되지 않는다.

실제 사용하고 있는 메모리는 RES 영역이기 때문에 메모리 점유율이 높은 프로세스를 찾기 위해서는 RES 영역이 높은 프로세스를 찾아야 한다.

### cf) 프로세스 상태 변화

![](https://images.velog.io/images/sandartchip/post/7439ed50-bef9-4a59-90ba-0a51de40dfbd/image.png)
(이미지 출처:https://jihooyim1.gitbooks.io/linuxbasic/content/contents/02.html)

- 먼저, Uninterruptible sleep 상태 (D 상태)에 대해 알아보자.
프로세스가 디스크 혹은 네트워크 작업을 하게 되면 디스크 디바이스 혹은 네트워크 디바이스에 요청을 보낸다.
디스크를 예로 든다면 어느 블록에 있는 어느 데이터를 읽어달라고 요청하는 것이다.
프로세스의 입장에서 보면 보낸 요청이 도착할 때까지 아무것도 할 수 없기 때문에, CPU에 대한 사용권을 다른 프로세스에 넘기고 자신을 UNINTERRUPTIBLE 상태로 마킹한 후 대기 상태로 빠진다. 이렇게 요청 후에 그에 대한 응답을 기다려야하는 상태를 Uniterruptible sleep 상태, 즉 D 상태라고 말할 수 있다.

- 반면에 sleep() 시스템 콜 등을 호출해서 타이머를 작동시키거나, 콘솔 입력을 기다리는 프로세스들은 Interruptible sleep 상태가 된다.
이 상태는 특정 요청에 대한 응답을 기다리는 상태가 아니며, 언제 어떻게 시그널이 들어올지 모르기 때문에 언제든 시그널을 받아서 처리할 수 있도록 Interruptible 상태로 마킹하고 대기상태에 빠진다. 이때의 상태를 S상태라고 한다.

- 사실 S상태의 프로세스가 많은 것은 시스템에 큰 영향을 끼치지 않는다.
하지만 D상태의 프로세스가 많으면 특정 요청이 끝나기를 기다리고 있는 프로세스가 많다는 뜻이고, 이 프로세스들은 요청이 끝나면 R상태로 다시 돌아가야 하기 때문에 시스템의 부하를 계산하는데 포함된다.

- 그렇다면 Z 상태는 어떤 경우에 발생할까?
모든 프로세스는 fork()를 통해서 만들어지기 때문에 부모와 자식 관계가 되고, 보통 부모 프로세스는 자식이 완료될 때까지 기다리게 된다.

#### 프로세스의 생성과 종료
![](https://images.velog.io/images/sandartchip/post/fec14a68-7445-43ad-9376-09b6157a129f/image.png)
(이미지 출처:https://jihooyim1.gitbooks.io/linuxbasic/content/contents/02.html)


#### 좀비 프로세스가 되는 경우
![](https://images.velog.io/images/sandartchip/post/e36cd50f-8c99-480e-b48d-cbdc46a0d59d/image.png)
(이미지 출처:https://jihooyim1.gitbooks.io/linuxbasic/content/contents/02.html)

사실 좀비 프로세스는 시스템의 리소스를 차지하지 않기 때문에 그 존재 자체는 큰 문제가 되지 않는다.
스케줄러에 의해 선택되지 않기 때문에 당연히 CPU를 사용하지 않고, 좀비 프로세스 자체는 이미 사용이 중지된 프로세스이기 때문에 메모리를 사용하지도 않는다.

그런데 왜 문제가 될까? 바로 좀비 프로세스가 점유하고 있는 PID 때문이다.
좀비 프로세스가 사용한 PID가 정리되지 않고 쌓이면 새로운 프로세스에 할당할 PID가 모자라게 되고, 이는 결국 더이상 PID를 할당하지 못하는 고갈상태를 일으킬 수 있다.


참고자료: https://jihooyim1.gitbooks.io/linuxbasic/content/contents/02.html

0 comments on commit 5a993d4

Please sign in to comment.