macOS에는 Linux의 free 명령이 기본으로 없다. 가장 가까운 한 줄 요약은 top -l 1 -s 0 | grep PhysMem, 시스템 압박 상태는 memory_pressure, 페이지 단위 상세 통계는 vm_stat으로 확인하면 된다.
처음에는 vm_stat의 Pages free만 바이트로 바꾸면 Linux의 free와 비슷하다고 생각했다. 하지만 macOS는 압축 메모리와 파일 캐시까지 함께 활용하므로, 빈 메모리의 크기보다 메모리 압박과 스왑의 추세를 같이 보는 것이 더 유용하다.
목적별로 어떤 명령을 쓰면 되는가
| 확인하려는 것 | 명령 또는 도구 |
|---|---|
| 물리 메모리 한 줄 요약 | `top -l 1 -s 0 |
| 시스템 전체 메모리 압박 | memory_pressure 또는 memory_pressure -Q |
| 페이지 상태와 누적 통계 | vm_stat |
| 설치된 물리 메모리 크기 | sysctl -n hw.memsize |
| 프로세스별 사용량과 압박 그래프 | 활동 모니터의 메모리 탭 |
Linux 서버의 출력과 비교해야 한다면 Linux free와 캐시 메모리 읽는 법도 함께 보면 차이가 선명하다.
빠르게 현재 메모리 요약 보기
top -l 1 -s 0 | grep PhysMem
출력은 macOS 버전과 시스템 상태에 따라 조금씩 달라지지만 다음 항목을 볼 수 있다.
PhysMem: 29G used (4010M wired, 1067M compressor), 2245M unused.
used: 현재 사용 중으로 집계된 물리 메모리wired: 시스템 동작에 필요해 압축하거나 디스크로 내보낼 수 없는 메모리compressor: 압축된 메모리unused: 현재 사용하지 않는 메모리
여기서 unused가 작다고 바로 메모리 부족은 아니다. macOS는 남는 메모리를 캐시에 활용하고 필요할 때 회수한다.
메모리가 정말 부족한지 확인하기
터미널에서는 다음 명령으로 시스템 전체 메모리 압박 정보를 볼 수 있다.
memory_pressure
짧은 결과만 필요하면 다음처럼 실행한다.
memory_pressure -Q
다만 출력되는 “free percentage”를 Linux free의 available과 같은 값으로 해석하지 않는 편이 안전하다. 실제 문제를 판단할 때는 스왑 입출력이 계속 늘어나는지, 압축 메모리가 커지는지, 체감 지연이 함께 나타나는지를 본다.
GUI에서는 활동 모니터 → 메모리가 가장 읽기 쉽다. Apple은 메모리 압박 그래프를 다음처럼 구분한다.
- 초록색: 메모리 자원이 효율적으로 사용되는 상태
- 노란색: 메모리 자원이 더 필요할 수 있는 상태
- 빨간색: 메모리 자원이 부족한 상태
단일 숫자보다 이 그래프와 Swap Used, 압축된 메모리를 함께 보는 것이 낫다.
vm_stat 출력 읽기
vm_stat
첫 줄에는 현재 시스템의 페이지 크기가 표시된다.
Mach Virtual Memory Statistics: (page size of 16384 bytes)
예전 글에서는 페이지 크기를 항상 4,096바이트라고 두었지만, Apple Silicon Mac에서는 16,384바이트가 표시될 수 있다. 고정값을 곱하지 말고 출력 첫 줄의 page size를 기준으로 계산해야 한다.
자주 보는 항목은 다음과 같다.
Pages free: 현재 비어 있는 페이지Pages active: 최근 사용된 활성 페이지Pages inactive: 당장 활발히 쓰이지 않는 페이지Pages wired down: 메모리에 유지해야 하는 페이지Pages occupied by compressor: 압축기에 들어간 페이지Pageins,Pageouts: 저장 장치와 메모리 사이 이동의 누적 횟수Swapins,Swapouts: 스왑 입출력의 누적 횟수
누적값은 한 번 본 숫자보다 시간 간격을 두고 얼마나 증가했는지가 중요하다. vm_stat 1을 실행하면 1초 간격으로 변화를 볼 수 있다.
페이지 수를 MiB로 바꾸기
현재 페이지 크기를 직접 읽어 계산하려면 다음처럼 할 수 있다.
vm_stat | awk '
NR == 1 {
gsub(/[^0-9]/, "", $8)
page_size = $8
}
/Pages free/ {
gsub(/\./, "", $3)
printf "Pages free: %.1f MiB\n", $3 * page_size / 1024 / 1024
}
'
이 값은 “지금 애플리케이션이 추가로 쓸 수 있는 전체 메모리”가 아니라 말 그대로 free page만 환산한 것이다. 캐시 회수, 압축, 스왑까지 포함한 가용성을 나타내지는 않는다.
어떤 순서로 진단할까
- 활동 모니터나
memory_pressure로 전체 압박 상태를 본다. top에서 메모리 한 줄 요약과 문제 프로세스를 찾는다.vm_stat 1로 압축·pageout·swapout의 증가 추세를 본다.- 특정 프로세스가 의심되면 활동 모니터,
vmmap, Instruments로 범위를 좁힌다.
이 흐름은 명령 하나의 숫자를 정상/비정상으로 단정하는 일을 줄여 준다. 시스템 전체에서 실제 메모리 문제를 좁혀 가는 방법은 실제 메모리 문제를 분석하는 흐름에 더 자세히 정리했다.
참고 자료
'배움과 성장 > 시스템·성능' 카테고리의 다른 글
| Linux 시스템 콜이란: 사용자 모드·커널 모드와 strace 추적 (4) | 2024.09.21 |
|---|---|
| macOS에서 smartctl·lspci·ethtool 대신 무엇을 쓸까 (3) | 2024.09.20 |
| Meltdown·Spectre 차이: transient execution과 CPU 완화책 (0) | 2024.09.19 |
| Hyper-Threading과 SMT: 논리 CPU·공유 자원·성능 측정 (1) | 2024.09.19 |
| macOS Hardware 정보 확인: system_profiler·sysctl·ioreg 안전하게 쓰기 (0) | 2024.09.19 |
댓글