free 대신 available 확인
Linux는 사용하지 않는 메모리를 디스크 캐시로 활용하므로, 정상적인 서버에서도 여유 메모리가 적은 것은 자연스럽습니다. available 열은 swap을 사용하지 않고 새 작업에 제공할 수 있는 메모리 양에 대한 커널의 추정치입니다. 이 수치를 살펴보세요. used의 정확한 계산 방식은 도구 버전에 따라 달라지므로 서로 다른 시스템 간에 비교하지 마세요.
free -h
grep -E 'MemAvailable|Shmem:|SReclaimable' /proc/meminfo캐시에서 반환할 수 있는 것과 없는 것
애플리케이션에 메모리가 필요하면 보통 페이지 캐시를 반환할 수 있습니다. 공유 메모리와 tmpfs(Shmem)도 cache에 포함되지만, 디스크에 사본이 없는 데이터를 담고 있으므로 단순히 버릴 수 없습니다. 따라서 캐시가 큰데 사용 가능한 메모리는 적다면 tmpfs나 공유 메모리 세그먼트가 큰 경우가 많습니다.
df -h -t tmpfs
sudo slabtop -o | head -15swap 사용 자체가 문제는 아닙니다
서버가 드물게 사용하는 페이지를 몇 주 동안 swap에 보관해도 문제가 없을 수 있습니다. 문제가 되는 것은 지속적인 이동입니다. vmstat의 si와 so 열을 확인하세요. 값이 계속 0보다 크다면 시스템이 swap으로 페이지를 내보내거나 다시 가져오는 작업을 활발하게 수행하고 있다는 뜻이며, 이는 실제 메모리 부족의 징후입니다.
swapon --show
vmstat 1 5메모리를 사용하는 대상 찾기
상주 메모리 기준으로 프로세스를 정렬하세요. RSS는 프로세스 간에 공유하는 페이지를 각 프로세스에 중복 계산하므로 여러 프로세스의 값을 단순히 더할 수 없습니다. smem처럼 PSS를 지원하는 도구가 설치되어 있다면 더 타당한 합계를 얻을 수 있습니다.
ps -eo pid,user,rss,comm --sort=-rss | head -15실제 메모리 부족 알아보기
징후는 적은 가용 메모리, 지속적인 swap 입출력, 메모리 부족 종료 기능인 out-of-memory killer에 의해 종료된 프로세스입니다. 커널 로그를 확인하세요. 수치를 좋아 보이게 하려고 drop_caches를 실행하지 마세요. 서버가 디스크에서 다시 읽게 할 뿐, 아무것도 해결하지 못합니다.
sudo journalctl -k --no-pager | grep -iE 'out of memory|oom-kill'CH-J Server Manager의 메모리
System Monitor는 SSH를 통해 이 값들을 읽습니다. Linux에서는 used를 MemTotal − MemFree − Buffers − Cached − SReclaimable로 정의하고, available에는 커널 추정치를 사용합니다. 공유 메모리는 Cached에 포함되며 반환할 수 없고, 막대의 각 범주는 겹치지 않습니다. 일부 free 버전과 계산식이 다르므로 수치가 정확히 일치하지 않을 수 있습니다. swap과 그 사용 이력도 표시합니다. ZFS ARC는 별도로 처리하지 않으므로 ZFS 호스트에서는 사용 중인 메모리로 계산합니다.