memory risk management modify6

OS/RISK/MEMORY/RESULT/README.md

@@ -37,7 +37,7 @@
 
 - **개발 운용 부서의 Linux 시스템 기반 서비스 에 대한 메모리 사용의 구조 파악에 일조**
    - **Page Cache** 영역의 사용은 `mmap 시스템콜에 따른 파일 매핑 영역` 메모리 증설이 일부 필요한 이유가 검증됨
-   - **Active(anon)** 메모리 영역은 줄어들지 않고, 상승만 되는 구조 (Memory Leak 의심되며, 개발부서 인지됨)
+   - **Active(anon)** 메모리 영역은 줄어들지 않고, 상승만 되는 구조 (`Memory Leak` 의심되며, 개발부서 인지됨)
    - Swap 영역 의 지속적 상승 이유는 메모리 증설필요와 연관되며, Memory Leak 해결 시 서비스 안정성 강화 기대
 - 기술 일반적 관점에서 이를 `객관화 사실화 하는 것이 얼마나 중요한지를 다시 한번 느끼는 계기가 됨`
 
@@ -48,39 +48,54 @@
 
 ![mem-shm](./images/03p_shm.png)
 
- - cached_memory : 
- - shm_memory : 
- - sap_shm_free :
- - mapped_memory : 
+ - cached_memory: Skip (아래 Memory Extension의 cached memory 같음)
+ - shm_memory: 커널이 공유메모리로 할당받은 용량이다. 여기에는 `SHM, IPC(Sysv), RamDisk`가 해당된다.
+ - sap_shm_free: Skip
+ - mapped_memory: `어플리케이션이 mmap 함수를 사용`하여 System Call로 사용한 용량이다. 이를 메모리 파일 맵핑이라고 한다.
 
 
 ## Memory Extension
 
-> 결과론 적인 사용률(량)이 맞을 수도 있지만, 운용자 입장에서는 Pagecache와 free(즉시 할당가능) 량을 관측할 필요가 있다. 또한 avail memory의 경우도 개발 부서에 설명이 필요할 수도 있다.
+> 수치 기준으로의 사용률(량) 파악이 맞을 수도 있겠지만, 운용자 입장에서는 Pagecache와 free(즉시 할당가능) 량을 주의깊게 관측할 필요가 있다. 또한 avail memory의 경우도 개발 부서에 설명이 필요할 수도 있다.
 
 ![mem-ext](./images/03p_mem_ext.png)
 
- - total memory :
- - cached memory :
- - buffers memory :
- - used memory(total - free) :
- - free memory(Allocable immediately) :
- - avail memory(free+buffers+cached) :
+ - total memory: 시스템에 설치된 전체용량이다. 참고적으로 증설/감설이력에 활용하면 좋을 것이다.
+ - cached memory: 커널이 메모리 가용량에 대해 PageCache로 활용된 용량이다. 다만 `공유메모리도 포함됨을 주의` 해야한다.
+ - buffers memory: Block Device(xfs, ext4 등)에 버퍼 캐시량이며, 참고적으로 inode의 인덱싱 정보도 여기에 캐싱된다.
+ - used memory(total - free): 수치 기준으로의 사용량
+ - free memory(Allocable immediately): 커널이 **아무런 간섭없이(아래 설명 참조)**, 즉시 메모리를 할당할 수 있는 용량
+ - avail memory(free+buffers+cached): 이 필드가 실질적으로 가용량이긴 하지만, 여기에 cached 필드가 있으므로, `100% 확신하면 안된다`.
+
+> 간섭 없이란, 일반적으로 리눅스 커널은 가용량에 대해 Pagecache로 활용하는데, 이때 메모리할당요청이 발생되면 cached된 영역에서 요청량만큼 소거하고, 할당한다.
 
 
 ## Active/Inactive Memory
 
->
+> 리눅스(커널)의 메모리는 Active/Inactive로 구분되는데 이는 기본 Page 교체 알고리즘이 LRU(오래된 페이지를 교체)이기 때문이다. 이는 반대로 Active 영역에 대해서는 프로세스를 강제로 중지하지 않는 이상 반환할 수 없음을 의미하기도 한다.
 
 ![mem-active](./images/03p_active_inactive.png)
 
+ - Active(anon) memory usage: **최근에 사용**되어 왔고, 비파일(일반적으로 어플리케이션 메모리) 메모리이기 때문에 `강제로 반환할 수 없다`. 그리고 Swap-out(메모리 -> 디스크)`되지 않는다`.
+ - Active(file) memory usage: **더 최근에 사용**되어 왔고, 파일기반의 메모리이지만, `강제로 반환할 수 없다`. 단, Swap-out(메모리 -> 디스크) `가능하다`.
+ - Inactive(anon) memory usage: **예전에 사용**되어 왔고, 강제로 반환이 가능하다. Swap-out(메모리 -> 디>스크) `가능하다`.
+ - Inactive(file) memory usage: **예전에 사용**되어 왔고, `아무런 영향없이` 강제(drop cache)로 반환이 가능하다.
+
+> 이번 이슈는 Active(anon) 영역이 지속적으로 증가하기 때문에 시간이 지날수록 시스템 메모리가 부족하게 된다. 따라서 결국 Swap도 지속적으로 늘어나면서 시스템/서비스의 부하/지연이 발생되는 이슈다.
+
 
 ## Swapping
 
->
+> Swap의 경우도 수치 기준으로의 사용률(량) 파악이 맞을 수도 있겠지만, 운용자 입장에서는 swap in/out 량을 주의깊게 관측할 필요가 있다.
 
 ![mem-swap](./images/03p_swap.png)
 
+ - swap total: 시스템에 설치된 전체용량이다. 참고적으로 증설/감설이력에 활용하면 좋을 것이다.
+ - swap free: 수치 기준으로의 가용량
+ - swap in: Page가 `디스크 -> 메모리로 이동`되는 용량이다.
+ - swap out: Page가 `메모리 -> 디스크로 이동`되는 용량이다.
+ - swap used: 수치 기준으로의 사용량
 
+> SWAP을 사용한다고 100% 문제가 있는 것은 아니다. 다만, swap in/out 구조가 메모리와 디스크라는 특성으로 문제가 되는 것이다. 즉, 메모리와 디스크의 속도차이는 대략 20배 이상인 것으로 알려져 있기 때문에 자주 Swapping되면, 지연(Latency)이 발생될 수 밖에 없다.