안드로이드에서 프로세스가 도대체 얼만큼의 메모리를 사용하고 있는지 분석해본다.

시스템 메모리 사용 현황

우선 전체 시스템의 메모리부터 파악하자. $> adb shell 로 접속한 후 /proc/meminfo를 열어본다.

# cat /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 명령어로 구할 수 있다.

# 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는 공유되는 페이지를 공유 프로세스의 수로 나누어서 좀더 정확한 메모리 사용량을 파악할 수 있게 해준다. 이게 프로세스가 사용하는 실제 메모리 크기에 가장 근접한 값이라고 볼 수 있다.

# procrank

  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 만의 메모리 크기를 알 수 있다.

# dumpsys meminfo 183
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 라이브러리가 사용하는 메모리 정보는 제외되었다.




힙 메모리 분석
애플리케이션 프로세스가 차지하는 메모리 크기는 이 정도면 파악되었고, 힙 메모리 안에서 자바 객체 레벨의 메모리 사용량을 분석하려면 힙덤프를 떠서 분석해야한다. 이건 다음 기회에... ^^;;


* 참조

http://tinysense.textcube.com/11

신고
Posted by 에코지오

댓글을 달아 주세요

  1. BlogIcon nhk8318 2010.04.23 16:41 신고  댓글주소  수정/삭제  댓글쓰기

    깔끔하고 멋진 정리에 감격하며 블로그에 링크 걸도록 하겠습니다. 허락하여주세요...:-)

  2. sharpen 2011.09.05 11:17 신고  댓글주소  수정/삭제  댓글쓰기

    와~ 감사합니다. 잘 봤습니다.

  3. sharemind 2012.06.19 16:14 신고  댓글주소  수정/삭제  댓글쓰기

    깔끔한 정리 감사합니다. 많은 도움이 되었습니다.

  4. gg 2012.10.19 11:12 신고  댓글주소  수정/삭제  댓글쓰기

    와 잘봤습니다. 퍼가요 ^^

  5. 안녕하세요 2012.11.13 11:03 신고  댓글주소  수정/삭제  댓글쓰기

    안드로이드 cpu사용량 구글링하다 여기까지 왔네요 ^^
    혹시 adb shell top 과 adb shell cpuinfo 에서 나오는 각 pid의 cpu 사용률이 상이한데요
    어떤 차이점이 있는지 조언을 구할수 있을까요



티스토리 툴바