Merge pull request #542 from sandartchip/master

 [#533] top을 통해 살펴보는 프로세스 정보

Lina Yi/2021_02_18_top명령어를 통해 살펴보는 프로세스 정보들.md

@@ -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