3

I've been trying to figure out how Android/CyanogenMod manages RAM internally, and what exactly I can trim down.

I'm running CyanogenMod 10.1-M2 right now, but the memory usage has stayed fairly consistent over the updates ever since I installed the CM 10 about a half a year ago.

Here are my questions :

  • What could Trebuchet be doing eating away 100M RAM by itself?

    For that matter, systemui is eating over 70M RAM as well. A rough calculation of the video RAM requirements (4 colors x 1200 x 720 ~ 3-4MB) is nowhere near hundreds of megabytes, even if you have, say, 10 layers on your launcher and System UI, each taking the full screen.

  • system_server is taking ~150M, is that normal?

    I guess if you take into account services shown by dumpsys meminfo it all adds up, but I wanted to check.

For info, running dumpsys meminfo shows :

Total PSS by OOM adjustment:
   118491 kB: System
              118491 kB: system (pid 406)
    79619 kB: Persistent
               50892 kB: com.android.systemui (pid 19167)
               23670 kB: com.android.phone (pid 688)
                5057 kB: com.android.nfc (pid 697)
   112547 kB: Foreground
              112547 kB: com.cyanogenmod.trebuchet (pid 25585)
    97764 kB: Visible
               62079 kB: android.process.acore (pid 23677)
               13137 kB: com.google.process.gapps (pid 886)
                9092 kB: com.google.android.gsf.login (pid 6452)
                8151 kB: com.google.process.location (pid 855)
                2753 kB: com.android.nfc:handover (pid 788)
                2552 kB: com.android.smspush (pid 811)
     8094 kB: Perceptible
                5558 kB: com.android.inputmethod.latin (pid 9662)
                2536 kB: com.android.location.fused (pid 3493)
    67783 kB: A Services
               26124 kB: com.facebook.katana (pid 27504)
               16481 kB: com.facebook.orca (pid 26218)
               12152 kB: com.google.android.apps.maps:GoogleLocationService (pid 24846)
                7467 kB: android.process.media (pid 24905)
                5559 kB: net.nurik.roman.dashclock (pid 24926)
    28482 kB: B Services
               10988 kB: com.android.vending (pid 26889)
                7018 kB: com.google.android.apps.maps (pid 18348)
                5104 kB: com.dropbox.android (pid 25070)
                2710 kB: com.bel.android.dspmanager (pid 26346)
                2662 kB: com.cyanogenmod.updater.updater.service.UpdateCheckService (pid 25156)
    54121 kB: Background
               14159 kB: com.google.android.apps.plus (pid 27352)
               12993 kB: com.facebook.katana:providers (pid 27538)
                8600 kB: com.google.android.googlequicksearchbox (pid 27427)
                4848 kB: com.evernote.skitch (pid 27408)
                4101 kB: com.google.android.apps.maps:LocationFriendService (pid 27488)
                3833 kB: com.google.android.gms (pid 27474)
                2890 kB: com.google.android.partnersetup (pid 27445)
                2697 kB: com.android.defcontainer (pid 27379)

top shows :

  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
  406  1   0% S   101 689020K 138244K  fg system   system_server
25585  1   0% S    23 581124K 136528K  fg u0_a40   com.cyanogenmod.trebuchet
19167  0   0% S    20 507824K  71216K  fg u0_a36   com.android.systemui
23677  0   0% S    33 526580K  56076K  bg u0_a1    android.process.acore
27504  1   0% S    29 505836K  43828K  bg u0_a112  com.facebook.katana
  688  0   0% S    44 530180K  33860K  fg radio    com.android.phone
26218  1   0% S    24 491392K  31792K  bg u0_a92   com.facebook.orca
  128  0   0% S    10  69020K  27900K  fg system   /system/bin/surfaceflinger
27754  1   0% S    15 481612K  26892K  bg u0_a127  com.google.android.apps.maps:LocationFriendService
26889  0   0% S    29 495588K  26356K  bg u0_a55   com.android.vending
7
  • If you have plenty of icons and widgets running on your homescreen with live wallpaper, then trebuche using 100mb+ of RAM sounds reasonable. system_ui also caches screen bitmaps to reduce lags when scrolling and switching apps. Android will automatically reclaim their memory if a foreground app needs it so it shouldn't be an issue for concern. As for system_server, I dont have it and I think its abnormally consuming your RAM
    – forums
    Mar 27, 2013 at 6:56
  • Also, may I know your Phone model? (Xperia Z, HTC One, Nexus, etc)
    – forums
    Mar 27, 2013 at 7:07
  • @forums: Phone's a Galaxy Nexus. And system_server is a core component for Android that's running services, that's why I'm not that surprised by it using 100+ MB of RAM given that Facebook takes 40M on its own. Trebuchet is what's really baffling me, even with caching and widgets. The reason I'm asking this question, by the way, is that my phone becomes really laggy after a while, with Trebuchet/System UI getting OOM-killed each time I open an app.
    – F.X.
    Mar 27, 2013 at 8:18
  • Might a look at My device is getting slow, apps start misbehaving/crashing. What can I do? prove helpful then?
    – Izzy
    Apr 20, 2013 at 16:58
  • @Izzy: CM 10.1-M3 fixed a lot of things, although I'm not sure what happened. And removing the main Facebook app did wonders, I discovered it was registered on more or less EVERY system intent, and the whole phone just went haywire whenever I enabled the data connection -- I don't keep data enabled all the time, and, every time I turned it on, I suppose Facebook had to download and process tons of things. Other than that I don't have a lot to say.
    – F.X.
    Apr 23, 2013 at 11:22

1 Answer 1

6

These things helped a lot :

  • Looking at which apps drained the most power. Performance improved a lot after uninstalling Facebook and a few other apps I had downloaded over time.
  • Upgrading to CyanogenMod 10.1-M3 helped. They fixed a nasty memory leak, which probably accounted for parts of my issues.
  • A little before the first 10.1-RC candidates, the CM team tweaked memory settings that had changed without warning in one of the releases.
  • If you're running low on storage, you might want to run fstrim /data on a root shell. It seems to be a technical limitation of SSDs when they're low on space.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .