안드로이드에서 프로세스가 도대체 얼만큼의 메모리를 사용하고 있는지 분석해본다.
시스템 메모리 사용 현황
우선 전체 시스템의 메모리부터 파악하자. $> adb shell 로 접속한 후 /proc/meminfo를 열어본다.
MemTotal: 94172 kB
MemFree: 2136 kB
Buffers: 12 kB
Cached: 46380 kB
SwapCached: 0 kB
Active: 36868 kB
Inactive: 46140 kB
Active(anon): 18548 kB
Inactive(anon): 19584 kB
Active(file): 18320 kB
Inactive(file): 26556 kB
Unevictable: 264 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 36892 kB
Mapped: 29344 kB
Slab: 2952 kB
SReclaimable: 740 kB
SUnreclaim: 2212 kB
PageTables: 3176 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 47084 kB
Committed_AS: 914824 kB
VmallocTotal: 876544 kB
VmallocUsed: 11376 kB
VmallocChunk: 863236 kB
MemTotal, MemFree 같은 필드는 대충 감이 잡히는데, 모르는 항목이 많이 보인다. 넘어가자. -.-;;
VSS와 RSS
이론적으로(?) 프로세스가 차지하는 정확한 메모리의 크기를 알 수는 없다고 한다. 다만, 프로세스에 매핑되는 page 수를 해석하는 다양한 방법이 있는데, VSS, RSS, USS, PSS 등이 그것이다.
- VSS(Virtual Set Size) : 프로세스와 관련된 버추얼 메모리(virtual memory) 크기. 메모리 맵(나도 자세한 건 모른다)이 1M이면 프로세스가 어떤 리소스도 사용하지 않아도 VSS는 1MB가 된다. 의미있는 수치라고 볼 수 없음.
- RSS(Resident Set Size) : 프로세스와 관련된 물리적 페이지(physical pages) 수. 여러 프로세스 사이에서 공유된 페이지(shared pages) 수를 확인할 수 없어 별 의미없음. A프로세스의 RSS가 2MB, B프로세스의 RSS가 2MB일 때 실제 물리 페이지 수는 4MB이거나 2MB일 수 있다.
어쨌거나 프로세스별 VSS와 RSS 값은 top 명령어로 구할 수 있다.
User 1%, System 6%, IOW 0%, IRQ 0%
User 6 + Nice 0 + Sys 20 + Idle 293 + IOW 0 + IRQ 0 + SIRQ 0 = 319
PID CPU% S #THR VSS RSS PCY UID Name
205 4% R 1 888K 368K fg root top
54 1% S 40 149592K 31644K fg system system_server
99 0% S 17 117416K 22028K fg radio com.android.phone
4 0% S 1 0K 0K fg root events/0
5 0% S 1 0K 0K fg root khelper
6 0% S 1 0K 0K fg root suspend
7 0% S 1 0K 0K fg root kblockd/0
8 0% S 1 0K 0K fg root cqueue
9 0% S 1 0K 0K fg root kseriod
10 0% S 1 0K 0K fg root kmmcd
11 0% S 1 0K 0K fg root pdflush
12 0% S 1 0K 0K fg root pdflush
1 0% S 1 296K 204K fg root /init
14 0% S 1 0K 0K fg root aio/0
21 0% S 1 0K 0K fg root mtdblockd
22 0% S 1 0K 0K fg root hid_compat
23 0% S 1 0K 0K fg root rpciod/0
24 0% S 1 0K 0K fg root mmcqd
25 0% S 1 728K 308K fg root /system/bin/sh
26 0% S 1 796K 260K fg system /system/bin/servicemanager
27 0% S 1 832K 384K fg root /system/bin/vold
28 0% S 1 656K 248K fg root /system/bin/debuggerd
29 0% S 4 5420K 728K fg radio /system/bin/rild
30 0% S 1 81428K 25528K fg root zygote
31 0% S 6 20944K 3332K fg media /system/bin/mediaserver
32 0% S 1 784K 284K fg root /system/bin/installd
33 0% S 1 1616K 404K fg keystore /system/bin/keystore
34 0% S 1 728K 324K fg root /system/bin/sh
35 0% S 1 824K 336K fg root /system/bin/qemud
37 0% S 4 3372K 184K fg root /sbin/adbd
46 0% S 1 780K 308K fg root /system/bin/qemu-props
94 0% S 6 109168K 18604K bg system com.android.settings
97 0% S 7 107548K 18784K fg app_4 com.android.inputmethod.latin
102 0% S 12 133720K 28496K fg app_4 android.process.acore
132 0% S 6 102392K 18260K bg app_6 com.android.alarmclock
144 0% S 7 103136K 18908K bg app_1 android.process.media
165 0% S 6 114060K 19036K bg app_12 com.android.mms
183 0% S 7 105492K 19592K bg app_21 com.android.email
197 0% S 1 728K 324K fg root /system/bin/sh
13 0% S 1 0K 0K fg root kswapd0
2 0% S 1 0K 0K fg root kthreadd
3 0% S 1 0K 0K fg root ksoftirqd/0
USS와 PSS
VSS나 RSS보다 조금 더 의미있는 수치는 USS와 PSS인데, procrank 명령어로 구할 수 있다.
- USS(Unique Set Size) : 프로세스만의 고유한 페이지 수. 공유되지 않는 프로세스에 private한 메모리 크기이다.
- PSS(Proportional Set Size) : USS + (공유 페이지 / 공유하는 프로세스 수). 즉, 프로세스 고유 메모리 사용량 + 하나의 프로세스가 차지하는 공유 메모리 비율이다. 만약 A프로세스가 6MB 메모리를 사용하고 그 중 2MB가 그 프로세스의 고유 영역이라면, 나머지 4MB는 공유 메모리이다. 4MB의 공유메모리를 4개의 프로세스가 공유하고 있다면 PSS는 2MB + (4MB/4) = 3MB가 된다.
PSS는 공유되는 페이지를 공유 프로세스의 수로 나누어서 좀더 정확한 메모리 사용량을 파악할 수 있게 해준다. 이게 프로세스가 사용하는 실제 메모리 크기에 가장 근접한 값이라고 볼 수 있다.
PID Vss Rss Pss Uss cmdline
54 32244K 31644K 14353K 10860K system_server
102 28496K 28496K 10835K 7164K android.process.acore
30 25528K 25528K 8585K 5636K zygote
99 22028K 22028K 6146K 3604K com.android.phone
183 19592K 19592K 4461K 2480K com.android.email
165 19036K 19036K 4122K 2136K com.android.mms
144 18908K 18908K 3953K 2148K android.process.media
94 18604K 18604K 3868K 1780K com.android.settings
97 18784K 18784K 3734K 1712K com.android.inputmethod.latin
132 18260K 18260K 3352K 1508K com.android.alarmclock
31 3332K 3332K 1002K 628K /system/bin/mediaserver
203 456K 456K 269K 260K procrank
29 728K 728K 258K 220K /system/bin/rild
1 204K 204K 185K 184K /init
37 184K 184K 169K 168K /sbin/adbd
27 384K 384K 156K 144K /system/bin/vold
35 336K 336K 134K 124K /system/bin/qemud
33 404K 404K 107K 88K /system/bin/keystore
34 324K 324K 102K 68K /system/bin/sh
197 324K 324K 102K 68K /system/bin/sh
25 308K 308K 96K 68K /system/bin/sh
46 308K 308K 95K 84K /system/bin/qemu-props
32 284K 284K 93K 84K /system/bin/installd
26 260K 260K 92K 84K /system/bin/servicemanager
28 248K 248K 84K 76K /system/bin/debuggerd
프로세스별 PSS 수치는 DDMS의 Sysinfo 탭을 통해서도 볼 수 있다. 파이그래프로 비주얼하게 보여주므로, 메모리 사용 비율을 쉽게 파악할 수 있다.
조금 더 상세한 메모리 정보
top과 procrank를 통해 애플리케이션의 개략적인 메모리 사용량을 알수 있었다면, dumpsys meminfo <PID(프로세스 ID)> 명령어로 약간 더 상세한 메모리 사용정보를 구할 수 있다. dumpsys meminfo 명령어는 프로세스가 사용하는 native(C/C++)와 dalvik(JAVA) 영역을 구분하여 보여주므로 달빅 VM 만의 메모리 크기를 알 수 있다.
Currently running services:
meminfo
----------------------------------------------------------
DUMP OF SERVICE meminfo:
Applications Memory Usage (kB):
Uptime: 3793754 Realtime: 3793754
** MEMINFO in pid 183 [com.android.email] **
native dalvik other total
size: 3436 3139 N/A 6575
allocated: 3425 2639 N/A 6064
free: 10 500 N/A 510
(Pss): 824 1893 1461 4178
(shared dirty): 1888 4916 972 7776
(priv dirty): 620 540 552 1712
Objects
Views: 0 ViewRoots: 0
AppContexts: 2 Activities: 0
Assets: 2 AssetManagers: 2
Local Binders: 4 Proxy Binders: 8
Death Recipients: 0
OpenSSL Sockets: 0
SQL
heap: 56 dbFiles: 0
numPagers: 3 inactivePageKB: 13
activePageKB: 0
- Pss 필드 : procrank에 나온 PSS 값과 동일
- shared dirty : 다른 프로세스와 공유하는 dirty pages(디스크로부터 페이징 불가능?)
- private dirty : 프로세스 고유의 dirty pages
참고로 위의 Objects와 SQL 섹션에는 View/Context/Activity 등의 개수와 SQL 페이지 크기 등 중요한 정보를 제공하므로 활용가치가 높다.
dumpsys meminfo 출력 결과에 나온 dalvik 컬럼의 size, allocated, free 필드값은 DDMS의 VM Heap 탭을 통해서도 확인할 수 있다. 각각 VM Heap 탭의 Heap Size, Allocated, Free 컬럼에 해당한다. DDMS의 VM Heap 탭의 정보는 달빅 VM만의 메모리 정보일 뿐, 애플리케이션의 native 라이브러리가 사용하는 메모리 정보는 제외되었다.
힙 메모리 분석
애플리케이션 프로세스가 차지하는 메모리 크기는 이 정도면 파악되었고, 힙 메모리 안에서 자바 객체 레벨의 메모리 사용량을 분석하려면 힙덤프를 떠서 분석해야한다. 이건 다음 기회에... ^^;;
* 참조
'안드로이드' 카테고리의 다른 글
[Android 문서번역] Avoiding Memory Leaks (메모리 누수를 피하는 방법) (0) | 2011.10.23 |
---|---|
[안드로이드] 시스템 분석을 위한 쉘 명령어 (0) | 2011.10.21 |
안드로이드 Cache 파일 삭제하기 (0) | 2011.10.20 |
TextView - 문자열 다루는 방법 (spannable) (1) | 2011.10.04 |
[자바] 자바 정규표현식(Regular Expression) (2) | 2011.09.29 |
[안드로이드] repo 다운로드 받기 (3) | 2011.09.25 |
[안드로이드] 파일복사 어떻게 해야 빨라질까? (1) | 2011.09.22 |
[안드로이드] 윈도우 백그라운드 & UI 속도 (번역) (0) | 2011.09.11 |
[안드로이드] 죽어도 다시 살아나는 서비스 (0) | 2011.09.10 |
[안드로이드] Runnable 생성&호출 성능 비교 (0) | 2011.09.07 |