load-causing processes disappearing from “top” ps -o pcpu shows bogus numbers The Next CEO of Stack Overflowhow do you interpret output of top?How is my server hitting swap?How to understand the memory usage and load average in linux serverWhat could be causing load spikes on this EC2 instance?my webserver with 16GB ram shows all RAM as used, but is it really, see the 'top'memory leak? RHEL 5.5. RSS show ok, almost no free memory left, swap used heavilyLoad Average cpu linux serverMySQL on Linux out of memoryWebserver is being blocked by some IO processRandom High CPU load
Audio Conversion With ADS1243
What are the unusually-enlarged wing sections on this P-38 Lightning?
Scary film where a woman has vaginal teeth
Calculate the Mean mean of two numbers
Getting Stale Gas Out of a Gas Tank w/out Dropping the Tank
What would be the main consequences for a country leaving the WTO?
Is there a reasonable and studied concept of reduction between regular languages?
Do I need to write [sic] when including a quotation with a number less than 10 that isn't written out?
Purpose of level-shifter with same in and out voltages
Does Germany produce more waste than the US?
What flight has the highest ratio of timezone difference to flight time?
Is fine stranded wire ok for main supply line?
Yu-Gi-Oh cards in Python 3
Is it OK to decorate a log book cover?
How did Beeri the Hittite come up with naming his daughter Yehudit?
What steps are necessary to read a Modern SSD in Medieval Europe?
Is it correct to say moon starry nights?
how one can write a nice vector parser, something that does pgfvecparseA=B-C; D=E x F;
Towers in the ocean; How deep can they be built?
Why do we say 'Un seul M' and not 'Une seule M' even though M is a "consonne"
Can Sneak Attack be used when hitting with an improvised weapon?
Is there a difference between "Fahrstuhl" and "Aufzug"?
Help/tips for a first time writer?
Does the Idaho Potato Commission associate potato skins with healthy eating?
load-causing processes disappearing from “top” ps -o pcpu shows bogus numbers
The Next CEO of Stack Overflowhow do you interpret output of top?How is my server hitting swap?How to understand the memory usage and load average in linux serverWhat could be causing load spikes on this EC2 instance?my webserver with 16GB ram shows all RAM as used, but is it really, see the 'top'memory leak? RHEL 5.5. RSS show ok, almost no free memory left, swap used heavilyLoad Average cpu linux serverMySQL on Linux out of memoryWebserver is being blocked by some IO processRandom High CPU load
I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld
ps -o pcpu,pid -p11008
%CPU PID
53.1 11008
, everything is consistent.
The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:
# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587
This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).
This is from an affected machine:
top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top
Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:
#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld
and
#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld
Here are the numbers from
# cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0
the 14th and 15th numbers according to
man proc
are supposed to be
utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.
stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).
On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.
Has anyone encountered this bug?
linux ubuntu top ps
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld
ps -o pcpu,pid -p11008
%CPU PID
53.1 11008
, everything is consistent.
The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:
# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587
This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).
This is from an affected machine:
top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top
Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:
#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld
and
#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld
Here are the numbers from
# cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0
the 14th and 15th numbers according to
man proc
are supposed to be
utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.
stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).
On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.
Has anyone encountered this bug?
linux ubuntu top ps
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54
add a comment |
I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld
ps -o pcpu,pid -p11008
%CPU PID
53.1 11008
, everything is consistent.
The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:
# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587
This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).
This is from an affected machine:
top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top
Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:
#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld
and
#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld
Here are the numbers from
# cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0
the 14th and 15th numbers according to
man proc
are supposed to be
utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.
stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).
On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.
Has anyone encountered this bug?
linux ubuntu top ps
I administer a large number of servers, and I have this problem only with Ubuntu 10.04 LTS:
I run a server under normal load (say load average 3.0 on an 8-core server). The "top" command shows processes taking certain % of CPU that cause this load average: say
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11008 mysql 20 0 25.9g 22g 5496 S 67 76.0 643539:38 mysqld
ps -o pcpu,pid -p11008
%CPU PID
53.1 11008
, everything is consistent.
The all of the sudden, the process causing the load average disappears from "top", but the process continues to run normally (albeit with a slight performance decrease), and the system load average becomes somewhat higher. The output of ps -o pcpu becomes bogus:
# ps -o pcpu,pid -p11008
%CPU PID
317910278 1587
This happened to at least 5 different severs (different brand new IBM System X hardware), each running different software: one httpd 2.2, one mysqld 5.1, and one Twisted Python TCP servers. Each time the kernel was between 2.6.32-32-server and 2.6.32-40-server. I updated some machines to 2.6.32-41-server, and it has not happened on those yet, but the bug is rare (once every 60 days or so).
This is from an affected machine:
top - 10:39:06 up 73 days, 17:57, 3 users, load average: 6.62, 5.60, 5.34
Tasks: 207 total, 2 running, 205 sleeping, 0 stopped, 0 zombie
Cpu(s): 11.4%us, 18.0%sy, 0.0%ni, 66.3%id, 4.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 74341464k total, 71985004k used, 2356460k free, 236456k buffers
Swap: 3906552k total, 328k used, 3906224k free, 24838212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
805 root 20 0 0 0 0 S 3 0.0 1493:09 fct0-worker
982 root 20 0 0 0 0 S 1 0.0 111:35.05 fioa-data-groom
914 root 20 0 0 0 0 S 0 0.0 884:42.71 fct1-worker
1068 root 20 0 19364 1496 1060 R 0 0.0 0:00.02 top
Nothing causing high load is showing on top, but I have two highly loaded mysqld instances on it, that suddenly show crazy %CPU:
#ps -o pcpu,pid,cmd -p1587
%CPU PID CMD
317713124 1587 /nail/encap/mysql-5.1.60/libexec/mysqld
and
#ps -o pcpu,pid,cmd -p1624
%CPU PID CMD
2802 1624 /nail/encap/mysql-5.1.60/libexec/mysqld
Here are the numbers from
# cat /proc/1587/stat
1587 (mysqld) S 1212 1088 1088 0 -1 4202752 14307313 0 162 0 85773299069 4611685932654088833 0 0 20 0 52 0 3549 27255418880 5483524 18446744073709551615 4194304 11111617 140733749236976 140733749235984 8858659 0 552967 4102 26345 18446744073709551615 0 0 17 5 0 0 0 0 0
the 14th and 15th numbers according to
man proc
are supposed to be
utime %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK). This includes guest time, guest_time (time spent running a virtual CPU, see
below), so that applications that are not aware of the guest time field do not lose that time from
their calculations.
stime %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by
sysconf(_SC_CLK_TCK).
On a normal server, these numbers are advancing, every time I check the /proc/PID/stat.
On a buggy server, these numbers are stuck at a ridiculously high value like 4611685932654088833, and it's not changing.
Has anyone encountered this bug?
linux ubuntu top ps
linux ubuntu top ps
edited Jul 10 '12 at 18:34
Alec Matusis
asked Jul 10 '12 at 17:57
Alec MatusisAlec Matusis
15116
15116
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54
add a comment |
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54
add a comment |
1 Answer
1
active
oldest
votes
I guess this might be a bug in procps
package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.
If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
add a comment |
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f406489%2fload-causing-processes-disappearing-from-top-ps-o-pcpu-shows-bogus-numbers%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I guess this might be a bug in procps
package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.
If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
add a comment |
I guess this might be a bug in procps
package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.
If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
add a comment |
I guess this might be a bug in procps
package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.
If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...
I guess this might be a bug in procps
package instead of kernel. Not seen the bug you described, but similar bugs over the years in various distros, yes.
If this is about procps, is there a bugfix available for Ubuntu 10.04 LTS? No idea, have not used it in a long, long time, and even the last time was in a galaxy far, far away...
answered Jul 10 '12 at 18:09
Janne PikkarainenJanne Pikkarainen
28.4k34268
28.4k34268
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
add a comment |
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
I suspect a kernel bug, since the 13th and 14th numbers (utime and stime) in /proc/<PID>/stat are very strange: they are larger by 5 orders of magnitude than on a normal server, and not advancing, while the process is running.
– Alec Matusis
Jul 10 '12 at 18:22
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f406489%2fload-causing-processes-disappearing-from-top-ps-o-pcpu-shows-bogus-numbers%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I have the same problem (almost) on two different servers. In both cases, the utime and stime in /proc/pid/stat are stuck at zero for all processes.
– user147739
Nov 30 '12 at 9:54