I have a repeating job scheduled using JobScheduler API in Android 7.0.
Please help me understand the following output of command:
adb shell dumpsys jobscheduler
u0a66 / < pkg >: 58x pending 5% 52x active
58 pending jobs, and 5 % (of total 52 running tasks) completed. /* 5 percent completed jobs id are stored in CompletedJobs queue to track */
adb shell dumpsys jobscheduler >> output.txt
gedit output.txt //read the complete output to get concepts
Commonly x is used to represent a number (how frequently).
I have an output something as below:
Current stats at 2017-07-25-01-42-38 (-5m30s657ms) over +5m30s657ms:
1000 / android: 2x pending 1x active
u0a14 / com.google.android.gms: 1x pending 1% 1x active-top
u0a66 / com.google.android.apps.photos: 3x pending 1x active
Max concurrency: 3 total, 1 foreground
Syntax:
/*<Uid> <reference> <app_name>: <% completed> <pending_jobs_count> <% completed>
<active_jobs_count> <status_that_tells_if_active_job_is_at_top_of_queue> */
It is a general understanding of how it should be. I can't provide you the link, so I am also not 100% certain. I just shared you my view.
JobScheduler is to effectively maintain the concurrency (from thread level -- called jobs). Even for the same program, there can be multiple processes (eg, service can start from the different process), and several threads. Ultimately these all threads are put in ThreadPoolExecuter and their operations are scheduled.
The job can be in pending, active and active-top state.
The u0a66 / package.name: 58x pending 5% 52x active line means that during that specified duration the package.name has 58 jobs in the pending state (which have been pending for less than 0.5% of the duration total), 52 jobs in the active state (which have been active for 5% of the duration total) and 0 jobs in the active-top state.
Related
I am trying to read (and understand) the CPU usage provided by the top command in my Samsung Galaxy S7.
From another post here I can see the explanation of the top command with the output that this person is getting.
However, when I go inside my Samsung using adb shell and I cal the top command, what I get is different from what the other used posted.
Am I doing something different/wrong?
If not, how do I read this output from top??
The output from the user on the other post has this:
User 5%, system 15%, IOW 0%, IRQ 0%
User 5 + Nice 0 + Sys 14 + Idle 73 + IOW 0 + IRQ 0 + SIRQ 0 = 92
PID CPU% S #THR VSS RSS UID Name
213 11% R 1 900K 340K app_16 top
However, the output from my top gives me something like that:
Tasks: 371 total, 7 running, 359 sleeping, 0 stopped, 0 zombie
Mem: 3618604k total, 3545056k used, 73548k free, 118980k buffers
Swap: 2097148k total, 894520k used, 1202628k free, 1441660k cached
800%cpu 9%user 0%nice 11%sys 780%idle 0%iow 0%irq 0%sirq 0%host
Basically, I cannot see the row
User 5%, system 15%, IOW 0%, IRQ 0%
which seems to be the key to understand the CPU usage.
Not really sure why, but "top" command is not longer accepting params on Android 8
I am trying to keep track of when the system wakes and suspends (ideally when monotonic_time starts and stops) so that I can accurately correlate monotonic time-stamps to the realtime clock.
On android the first method that came to mind was to monitor kmsg for a wakeup message and use its timestamp as a fairly accurate mark. As I was unsure of the accuracy of this timestamp, I decided to log the current monotonic time as well.
The following code is running in a standalone executable
while(true)
{
fgets(mLineBuffer, sizeof(mLineBuffer), mKmsgFile);
//Find first space
char * messageContent = strchr(mLineBuffer,' ');
//Offset one to get character after space
messageContent++;
if (strncmp (messageContent,"Enabling non-boot CPUs ...",25) == 0 )
{
clock_gettime(CLOCK_MONOTONIC,&mMono);
std::cout << mLineBuffer;
std::cout << std::to_string(mMono.tv_sec) << "." << std::to_string(mMono.tv_nsec) << "\n";
}
}
I expected the time returned by clock_gettime to be at some point after the kmsg log timestamp, but instead it is anywhere from 600ms before to 200ms after.
<6>[226692.217017] Enabling non-boot CPUs ...
226691.681130889
-0.535886111
<6>[226692.626100] Enabling non-boot CPUs ...
226692.80532881
+0.17922881
<6>[226693.305535] Enabling non-boot CPUs ...
226692.803398747
-0.502136253
During this particular session, CLOCK_MONOTONIC consistently differed from the kmsg timestamp by roughly -500ms, only once flipping over to +179ms over the course of 10 wakeups. During a later session it was consistently off by -200ms.
The same consistent offset is present when monitoring all kmsg entries during normal operation (not suspending or waking). Perhaps returning from suspend occasionally delays my process long enough to produce a timestamp that is ahead of kmsg, resulting in the single +179ms difference.
CLOCK_MONOTONIC_COARSE and CLOCK_MONOTONIC_RAW behave in the same manner.
Is this expected behavior? Does the kernel run on a separate monotonic clock?
Is there any other way to get wakeup/suspend times that correlate to monotonic time?
The ultimate goal is to use this information to help graph the contents of wakeup_sources over time, with a particular focus on activity immediately after waking. Though, if the kmsg timestamps are "incorrect", then the wakeup_sources ones probably are too.
I am doing some memory testing and I came across procstats in my research - before I start using it though I would like to fully understand everything before I start relying on its data.
Here is a condensed file of what I am trying to work with:
CURRENT STATS:
* com.samsung.android.providers.context / u0a6:
TOTAL: 100% (4.2MB-4.2MB-4.2MB/3.3MB-3.3MB-3.3MB over 1)
Service: 100% (4.2MB-4.2MB-4.2MB/3.3MB-3.3MB-3.3MB over 1)
* com.sec.android.inputmethod / 1000:
TOTAL: 100% (28MB-28MB-28MB/27MB-27MB-27MB over 2)
Imp Fg: 100% (28MB-28MB-28MB/27MB-27MB-27MB over 2)
* com.google.android.googlequicksearchbox / u0a54:
TOTAL: 0.05%
Imp Bg: 0.05%
(Cached): 100% (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB over 2)
* com.google.android.talk / u0a98:
TOTAL: 0.03%
Imp Bg: 0.03%
Receiver: 0.00%
(Cached): 100% (8.8MB-8.8MB-8.8MB/7.4MB-7.4MB-7.4MB over 2)
(Home): 100% (20MB-20MB-20MB/18MB-18MB-18MB over 1)
Run time Stats:
SOff/Norm: +24m36s393ms (running)
TOTAL: +24m36s393ms
Start time: 2014-12-08 14:22:50
Total elapsed time: +24m36s508ms (partial) libdvm.so chromeview
Here are the questions:
What does "over 1" / "over 2" mean?
What is the difference between Service, Imp Bg, Receiver, and Imp Fg?
Why doesn't every total list the RAM usage (com.google.android.talk for example)
What does 100% mean and what does .03% mean?
Why do only some have (Cached)/(Home)?
What does 100% (Cached)/(Home) mean?
What does "(partial) libdvm.so chromeview" mean?
Lastly, am I correct in assuming that (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB) is (low pss - avg pss - high pss / low uss - avg uss - high uss)?
If anyone could shed any light on this is would be greatly appreciated. Thanks.
As a heads up, I've already read these two links.... android-developers.blogspot.com/2014/01/ and android.googlesource.com/platform/frameworks/base/+/master/core/ .... and a few other pages - these are still the questions that I have left over. Can anyone go into detail about all 8 questions?
Edit
So I have been trying to compare numbers between procstats and meminfo and it really only adds more questions.
Here is an excerpt from procstats
CURRENT STATS:
* com.dropbox.android:crash_uploader / u0a87:
TOTAL: 100% (4.8MB-4.8MB-4.9MB/3.9MB-3.9MB-3.9MB over 6)
Service: 100% (4.8MB-4.8MB-4.9MB/3.9MB-3.9MB-3.9MB over 6)
* com.mobileposse.client / u0a22:
TOTAL: 0.16%
Service: 0.13%
Receiver: 0.03%
(Cached): 98% (7.2MB-8.4MB-9.3MB/6.1MB-7.2MB-8.1MB over 7)
* com.android.chrome / u0a79:
TOTAL: 0.01%
Receiver: 0.01%
(Cached): 86% (5.2MB-5.2MB-5.4MB/4.4MB-4.4MB-4.4MB over 3)
Here is an excerpt from meminfo
Total PSS by process:
5524 kB: com.android.chrome (pid 7334)
4969 kB: com.dropbox.android:crash_uploader (pid 5617)
Now dropbox makes sense, and I would say 80% of the processes follow dropbox's lead with having matching numbers between meminfo and pocstats. What I don't get - why does chrome not have any totals in the procstats but is listed in the meminfo and why does mobileposse have higher stats than chrome in the procstats but is not listed in the meminfo?
Take a look to the sources linked by Alex P. You can find the answer to some questions there:
What does "over 1" / "over 2" mean?
That is the number of samples taken.
What is the difference between Service, Imp Bg, Receiver, and Imp Fg?
They are different states (Imp Bg means Important Background, and Imp Fg Important Foreground)
Why doesn't every total list the RAM usage (com.google.android.talk for example)
What does 100% mean and what does .03% mean?
% of the time that these apps have been running.
Why do only some have (Cached)/(Home)?
What does 100% (Cached)/(Home) mean?
What does "(partial) libdvm.so chromeview" mean?
Lastly, am I correct in assuming that (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB) is (low pss - avg pss - high pss / low uss - avg uss - high uss)?
Yes, you are corrent, the documentation describes them as minPss-avgPss-maxPss / minUss-avgUss-maxUss
The percentages tell you how much of the overall time each process has spent in various key states. The memory numbers tell you about memory samples in those states, as minPss-avgPss-maxPss / minUss-avgUss-maxUss. The procstats tool also has a number of command line options to control its output — use adb shell dumpsys procstats -h to see a list of the available options.
Comparing this raw data from procstats with the visualization of its data we previously saw, we can see that it is showing only process run data from a subset of states: Imp Fg, Imp Bg, Service, Service Rs, and Receiver. These are the situations where the process is actively running in the background, for as long as it needs to complete the work it is doing. In terms of device memory use, these are the process states that tend to cause the most trouble: apps running in the background taking RAM from other things.
Quoted from: http://android-developers.blogspot.be/2014/01/process-stats-understanding-how-your.html Maybe you'll find more information using procstats -h or man procstats.
I am trying to monitor CPU usage using the top command in my android phone, using the following command:
Process p = Runtime.getRuntime().exec("top -m 15 -d 1 -n 1");
One of the output's of the top command I got is this:
User 2%, System 9%, IOW 0%, IRQ 0%
User 3 + Nice 0 + Sys 10 + Idle 95 + IOW 0 + IRQ 0 + SIRQ 0 = 108
PID PR CPU% S #THR VSS RSS PCY UID Name
743 0 15% R 1 2416K 948K bg u0_a692 top
15351 0 2% S 79 1921396K 114536K bg u0_a59 com.google.android.googlequicksearchbox:search
167 0 1% S 6 9668K 3512K logd /system/bin/logd
496 0 0% S 1 0K 0K root kworker/0:3
20447 0 0% S 1 0K 0K root kworker/u:34
I am using a Nexus 4 which has a quad core chip i.e. 4 CPUs
Here the total CPU usage is (intuitively) user + system = 11%. However, the top process itself takes 15% of the CPU. It happens most of the time. Here's a graph which I plotted using running the top command at an interval of 1s.
As seen in most cases, the top command uses more CPU than user and system CPU usage combined.
What causes this behavior?
I wanted to calculate how much CPU is used in an idle, sleep state. So, I thought of subtracting the CPU used by the top process from the combined CPU usage of user and system. But, having these kind of output cannot help me to determine exactly how much CPU the phone is using.
Also, is the CPU% of a process the total of user and system? i.e. if a process is utilizing 10% CPU, is it actually using something like 6% user and 4% system CPU?
1) Exclusive time is the time spent in the method
2) Inclusive time is the time spent in the method plus the time spent in any called functions
3) We refer to calling methods as "parents" and called methods as "children."
Reference Link : Click here
Question here is :
what are difference between
Incl CPU Time & Incl Real CPU Time ?
Excl CPU Time & Excl Real CPU Time ?
in my one example trace file
for Method1() : Incl CPU Time = 242 msec & Incl Real CPU Time = 5012 msec
i can not identify reason behind 5012-242 = 4770 msec gap in above both times.
Please help me if you have any idea.
Here's the DDMS documentation
Incl CPU time is the inclusive cpu time. It is the sum of the time spent in the function itself, as well as the sum of the times of all functions that it calls.
Excl CPU time is the exclusive cpu time. It is only the time spent in the function itself. You'll notice that it is always the same as the "incl time" of the "self" child.
The documentation doesn't clarify the difference between CPU time and real time, but I agree with Neetesh that CPU time is the time that the function is actually running (this would not include waiting on IO) and the real time is the wall clock time (which would include time spent doing IO).
cpu time is the time for which the process uses the cpu and cpu real time is the total time from the starting of process to end of process it includes waiting time of process to execute.
from the source code of .trace, you can see the cpu time detail different from the real cpu time, it's the same with the description of the android doc:
CPU time considers only the time that the thread is actively using CPU time, and real time provides absolute timing information from the moment your app enters a method to when it exits that method—regardless of whether the thread is active or sleeping.
Just as Chris and David said, I did a test.
#include <unistd.h>
#define S ((long long)1000 * 1000 * 1000)
// My CPU frequency is 3 GHz
void run() {
for (int i = 0; i < S; ++i);
}
void g() {
run();
run();
run();
for (int i = 0; i < S; ++i);
}
int main() {
g();
// run();
return 0;
}
As you can see, the inclusive time of function g is 8 s and its exclusive time is 2 s: