I'm currently working on a hybrid application that is exhibiting some peculiar memory usage that I'm trying to debug. As soon as the application starts, it appears to be immediately using close to 250MB of memory, which seems excessively given that all we have loaded at that point is the login screen. I've been looking at a few memory profiling tools for Android (the Xamarin profiler and the android profiler shipped with the SDK), but all of them show relatively low heap usage (~10-15MB, which I'm trying to get down). I ran "adb shell dumpsys meminfo APPNAME -d' and got the following trace:
** MEMINFO in pid 24925 [APPNAME] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 19439 19396 0 0 28672 22915 5756
Dalvik Heap 15441 14992 0 0 37319 36837 482
Dalvik Other 542 368 0 0
Stack 432 432 0 0
Ashmem 17388 16508 880 0
Gfx dev 40538 34504 0 0
Other dev 4 0 4 0
.so mmap 6211 224 3080 0
.apk mmap 10531 0 10232 0
.ttf mmap 453 0 260 0
.dex mmap 1263 0 980 0
.oat mmap 635 0 152 0
.art mmap 707 516 24 0
Other mmap 452 4 52 0
EGL mtrack 63508 63508 0 0
GL mtrack 79116 79116 0 0
Unknown 21756 21756 0 0
TOTAL 278416 251324 15664 0 65991 59752 6238
I've been trying to understand what this means by using the documentation provided at: https://developer.android.com/tools/debugging/debugging-memory.html, but that page doesn't seem to have any info on the biggest culprits: Gfx dev, EGL mtrack, GL mtrack, and Unknown. Is there some documentation on what these categories are or why they would grow to be so big?
Thanks
EGL and GL shows here memory consumed by Graphics layer basically. I am sure you are running adb shell dumpsys meminfo command on Android lollipop device. Actually dumpsys meminfo tool/command has been modified in lollipop to calculate and display graphics memory.
In old version (KitKat or older) you can not find EGL and GL information although graphics consumed memory in KitKat or older versions also.
This is we can request Google to update their documentation to explain new memory components also. In short you can say it is bug in documentation of Android. They should update it as per latest implementation of adb shell dumpsys meminfo tool/command.
References:
EGL - http://en.wikipedia.org/wiki/EGL_(API)
GL - http://en.wikipedia.org/wiki/OpenGL
GL mtrack is driver-reported GL memory usage. It's primarily the sum of GL texture sizes, GL command buffers, fixed global driver RAM overheads, etc.
EGL mtrack is gralloc memory usage. It's primarily the sum of the SurfaceView/TextureView.
Related
My Android project gets built fine on a Windows dev machine with lots of RAM. But in a simple Docker container (FROM ubuntu:xenial + Android SDK) gradle build (./gradlew assembleTrunkDebug) fails on 58% while executing the task:
transformClassesWithPreJackPackagedLibrariesForTrunkDebug
Even with --stacktrace --debug the most I get from the error is:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
There are several strange thing that I have noticed:
It doesn't matter what memory arguments I'm passing to the docker container instantiation. It always shows me the same memory stats.
Tasks: 2 total, 1 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1019776 total, 860604 free, 88840 used, 70332 buff/cache
KiB Swap: 1168688 total, 853640 free, 315048 used. 824484 avail Mem
I'm usually doing something like:
docker run -it --volume=/Users/MyUser/code/localDebugRepo:/localDebugRepo --workdir="/localDebugRepo" --memory="2048m" --memory-swap="2048m" 66b48030ee34 /bin/bash
But I have also tried to pass less memory and the same memory-swap or more total memory, but it always shows me Mem: 1019776 and Swap: 1168688.
I also noticed in the task manager that VBoxHeadless.exe uses only 41MB of RAM. While the misfortunate task is running (which takes a long time before crashing), the RAM usage doesn't change, but the Disk transfer is huge and only consumes more and more (since it's on SSD drive).
Android suggests the new build tool Jack and Jill used for the latest sdks has to be allowed to use at least 1536m memory. But the Docker image should run with max of 2048m and having in mind that I wasn't able to shrink the swap, I have the feeling something goes wrong there.
So any thoughts what might have caused this consistent error?
When I run "adb shell dumpsys meminfo" on android 4.2, I get the result like
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 28 8 28 16404 12256 3663
Dalvik 14062 10060 13736 20032 15254 4778
Cursor 0 0 0
Ashmem 0 0 0
Other dev 4762 9556 0
.so mmap 11699 1824 1500
.jar mmap 0 0 0
.apk mmap 368 0 0
.ttf mmap 811 0 0
.dex mmap 3736 0 0
Other mmap 114 16 32
Unknown 12064 544 12052
TOTAL 47644 22008 27348 36436 27510 8441
I have read the page of How do I discover memory usage of my application in Android?, but still have several questions:
Why the native Pss, shared dirty private dirty is very small?
the heap size should be smaller than Pss?
What does Unknown mean? Seems very big.
If I want to know how much memory my app uses, which data should I use? The Total Pss? But it doesn't include the native Pss which is nealy zero?
Please refer to the question How do I discover memory usage of my application in Android?.
I would also like you to refer to Detail VSS,RSS,PSS,USS link. The most appropriate data to use for a particular app is
USS (Unique Set Size ) as
USS is the total private memory for a process, i.e. that memory that is completely unique to that process . USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
which you can get by adb shell procrank | grep <your.package.name>
I've a Samsung Galaxy SIII with Android 4.1.2 "rooted". I need to measure the CPU usage for some multithreaded applications I've written in C/C++, however I need this information in a per core basis.
I know (due wikipedia, ...) that the Galaxy has a SoC with 4 ARM Cortex A9 however when I do a cat /proc/cpuinfo it doesn't show any information regarding the number of available cores (as usual in any Linux), is this correct behavior?
I've read somewhere that I can use cat /proc/stat to see the per core load average however, in my device, the content of such "file" only shows information for the "core0", again, is this correct or do I need to do something to enable all cores?
I also tried with top and ps without success.
EDITED:
----------------- cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1592.52
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Chip revision : 0011
Hardware : SMDK4x12
Revision : 000c
Serial : 11e16f694df1267e
----------------- cat /proc/stat
cpu 89515 1686 23283 464122 3835 2 376 0 0 0
cpu0 74214 457 16736 221609 1111 1 347 0 0 0
intr 1860068 0 0 0 0 0 0 0 0 0 0 .... (removed: a serie of numbers)
ctxt 3138146
btime 1371578546
processes 15904
procs_running 1
procs_blocked 0
softirq 1154788 12 403499 864 4501 12 12 444746 67202 576 233364
You can get information about the number of cores by examining the hotplug devices, /sys/devices/system/cpu/present and /sys/devices/system/cpu/possible. See also the hotplug docs.
I'm not sure this helps you much as far as getting CPU usage. You can get a crude sense for how much user and system time a thread has used from adb shell ps -x -t, e.g.:
USER PID PPID VSIZE RSS WCHAN PC NAME
system 19598 19574 955672 57324 ffffffff 4012d9b8 S system_server (u:2186, s:1521)
system 19602 19598 955672 57324 c007f840 4012db84 S GC (u:79, s:6)
This says that system_server's main thread has used 2186 ticks of user time, while the GC thread has used 79 ticks.
If you can instrument your application, you can use the POSIX clock_gettime() call with CLOCK_THREAD_CPUTIME_ID to measure the amount of CPU time used by a given thread. (The Dalvik VM uses this when generating results for traceview.)
This is all per-thread, however. Getting per-core usage information is much harder, especially on Android:
The hotplug mechanism can add or remove cores during your test.
The kernel can adjust the CPU frequency of each core individually, so doing X amount of work may take different amounts of time on different cores.
Threads can migrate between cores (by default there is no core affinity).
It should include the different cores (showing Nexus 7):
$ adb shell cat /proc/cpuinfo
Processor : ARMv7 Processor rev 9 (v7l)
processor : 0
BogoMIPS : 1993.93
processor : 1
BogoMIPS : 1993.93
processor : 2
BogoMIPS : 1993.93
processor : 3
BogoMIPS : 1993.93
and stat:
$ adb shell cat /proc/stat
cpu 1623573 112801 907626 32541158 125987 68 5952 0 0 0
cpu0 804181 45734 569092 7373416 43990 49 4990 0 0 0
cpu1 332438 26759 142892 8311267 31256 9 574 0 0 0
cpu2 332889 25551 130711 8319093 30900 7 218 0 0 0
cpu3 154065 14757 64931 8537382 19841 3 170 0 0 0
You can check if a core is Online/offline by reading the file
/sys/devices/system/cpu/CPUx/online (x is the number of the core and in Samsung S3: 0,1,2,3)
if it is "0" , the core is Offline and if it is "1" the core is online. Now, you can use /proc/stat to calculate CPU Usage but for Samsung S3 it will only show the cores which are active at the time you read /proc/stat. Now, to calculate CPU Usage for all the cores, you have to force all the cores online. You can use System Tuner App available at Play store: https://play.google.com/store/apps/details?id=ccc71.pmw&hl=en for forcing all the cores online. Install the app and then put the cores online by ( CPU -> Boot settings -> Force all CPUs online -> On boot Completed ), now you can reboot your device and all the cores are online. Now read /proc/stat and calculate CPU Usage for all the cores. If you need more explanation about /proc/stat http://www.linuxhowtos.org/System/procstat.htm
can help.
I noticed that load gets distributed among all the active cores (must be some system processes), I was running Skype over Wifi and without forcing all the cores online it was using 2 cores: core 0 and core 1 at 30% and 25% respectively. I measured the CPU Usage again for the same use case(Skype over wifi) after forcing all the cores online and I noticed that load was distributed among all active cores ( Core1: 26% , Core 2: 9%, Core 3: 11%, Core 4: 10% ).
I would like to know how I can troubleshoot high memory usage problems of my app on Android. I've search the internet and found out that the DDMS plugin is useful in taking a memory dump of the heap for my app. This however has been useless.
The app "Usage Timelines Free" is showing 94 MBs of memory used, while the DDMS heap dump shows me a total of 8.4 MBs, with the suspected leaks being the resource files.
When I generate a dump from adb (dumpsys meminfo), I get:
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 20 8 20 54588 39431 1892
Dalvik 6732 9952 6396 10756 10028 728
Cursor 0 0 0
Ashmem 184 0 184
Other dev 11462 1172 11384
.so mmap 2467 2072 1156
.jar mmap 0 0 0
.apk mmap 48 0 0
.ttf mmap 2 0 0
.dex mmap 1037 0 0
Other mmap 41 16 32
Unknown 46352 292 46348
TOTAL 68345 13512 65520 65344 49459 2620
How can I know what is behind this huge memory consumption. My app is a foreground monitor service which runs forever, with a few activities which are accessed a few times per day.
Thanks.
Minimize your android data usage. Check the link :http://engineroots.games4punk.com/minimize-your-android-data-usage/
DDMS and got a heap memory dump. It only showed 8.4 MBs being used!
Then you are only using 8.4MB of heap space after a complete garbage collection (a net effect of creating the heap dump).
Note that if you ran this on Android 1.x/2.x, MAT will not report space consumed by bitmaps. Always try to dump the heap from an Android 3.0+ device or emulator.
When I generate a dump from adb (dumpsys meminfo), I get:
My guess is that you are running this on an Android 1.x/2.x device or emulator, and you have a lot of bitmap memory. Try running your heap dump and other tests on an Android 3.0+ environment.
Also, bear in mind that adb dumpsys meminfo does not perform a complete garbage collection, whereas dumping the HPROF file does. The Android garbage collector is optimized to minimize CPU utilization and therefore does not attempt to perform a complete garbage collection. Hence, at runtime, the heap is usually filled with garbage that will be reclaimed, as needed, by the GC engine.
You might also wish to read Dianne Hackborn's essay on this subject.
I have seen some memory leak in my phone.
Steps :
Open Browser (Home Page : www.google.com). It will fetch the Page.
Select Back Key to come out from browser (close).
Repeat the same steps (1-2) for 5 times.
Observer following data by "adb shell dumpsys meminfo PID (of browser) :
First Time (when open browser first time - After Step 1):
Applications Memory Usage (kB):
Uptime: 428816 Realtime: 434932
** MEMINFO in pid 899 [com.android.browser] **
native dalvik other total
size: 24296 6727 N/A 31023
allocated: 24241 3955 N/A 28196
free: 54 2772 N/A 2826
(Pss): 3455 2259 30025 35739
(shared dirty): 2064 1772 7444 11280
(priv dirty): 3388 548 21116 25052
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 34 Proxy Binders: 28
Death Recipients: 1
OpenSSL Sockets: 0
Second Time (After Step - 4) Opening - Closing of Browser 5 times :
Applications Memory Usage (kB):
Uptime: 473642 Realtime: 479758
** MEMINFO in pid 899 [com.android.browser] **
native dalvik other total
size: 45616 7559 N/A 53175
allocated: 45322 4850 N/A 50172
free: 29 2709 N/A 2738
(Pss): 4602 2301 51988 58891
(shared dirty): 2060 1736 7440 11236
(priv dirty): 4536 584 42360 47480
Objects
Views: 0 ViewRoots: 0
AppContexts: 0 Activities: 0
Assets: 3 AssetManagers: 3
Local Binders: 113 Proxy Binders: 47
Death Recipients: 1
OpenSSL Sockets: 0
Could you please help us to find out what data here shows which information (like what is Size, Allocated, free, Local Binders etc) and where in above data it is showing that there is memory leak.
New to all these analysis so asking basic questions :-(
Please help me for this.
Thanks
Rke
You know, I don't really see a memory leak here. The most common way to get memory leak is to have references to Activity which had to be destroyed. Anyway, there is a way to search for leak, there is a good article in Android developers blog about memory analysis in Eclipse with MAT and there is also a video from Google IO-2011. Try it, and maybe you'll find what's wrong.