Tools for Monitoring Steal Time (st)
Clash Royale CLAN TAG#URR8PPP
We're running on a virtual "dedicated" server, which should, in theory, mean that we're the only guys on the server. In practice.... I'm thinking we might not be.
Notice that although it looks like we're killing our machine, "Steal time" is at 71%
I'm taking statistics on load and I was disappointed that this stat didn't show up in my graphs. Are there any tools which monitor this which might be able to help?
Additional information:
We're running 4 cores, model:
# grep "model name" /proc/cpuinfo | sort -u
model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
xen top virtualization
asked Jun 20 '12 at 17:36
mgjk
336719
|
show 4 more comments
We're running on a virtual "dedicated" server, which should, in theory, mean that we're the only guys on the server. In practice.... I'm thinking we might not be.
Notice that although it looks like we're killing our machine, "Steal time" is at 71%
I'm taking statistics on load and I was disappointed that this stat didn't show up in my graphs. Are there any tools which monitor this which might be able to help?
Additional information:
We're running 4 cores, model:
# grep "model name" /proc/cpuinfo | sort -u
model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
xen top virtualization
asked Jun 20 '12 at 17:36
mgjk
336719
1
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
1
How many vCPUs have you got and what type of CPU is reported ingrep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.
– Nils
Jun 20 '12 at 19:33
1
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
1
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
1
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15
|
show 4 more comments
We're running on a virtual "dedicated" server, which should, in theory, mean that we're the only guys on the server. In practice.... I'm thinking we might not be.
Notice that although it looks like we're killing our machine, "Steal time" is at 71%
I'm taking statistics on load and I was disappointed that this stat didn't show up in my graphs. Are there any tools which monitor this which might be able to help?
Additional information:
We're running 4 cores, model:
# grep "model name" /proc/cpuinfo | sort -u
model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
xen top virtualization
asked Jun 20 '12 at 17:36
mgjk
336719
We're running on a virtual "dedicated" server, which should, in theory, mean that we're the only guys on the server. In practice.... I'm thinking we might not be.
Notice that although it looks like we're killing our machine, "Steal time" is at 71%
I'm taking statistics on load and I was disappointed that this stat didn't show up in my graphs. Are there any tools which monitor this which might be able to help?
Additional information:
We're running 4 cores, model:
# grep "model name" /proc/cpuinfo | sort -u
model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
xen top virtualization
xen top virtualization
asked Jun 20 '12 at 17:36
mgjk
336719
asked Jun 20 '12 at 17:36
mgjk
336719
edited Jun 20 '12 at 19:40
asked Jun 20 '12 at 17:36
mgjk
336719
asked Jun 20 '12 at 17:36
mgjk
336719
asked Jun 20 '12 at 17:36
mgjk
336719
336719
1
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
1
How many vCPUs have you got and what type of CPU is reported ingrep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.
– Nils
Jun 20 '12 at 19:33
1
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
1
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
1
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15
|
show 4 more comments
1
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
1
How many vCPUs have you got and what type of CPU is reported ingrep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.
– Nils
Jun 20 '12 at 19:33
1
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
1
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
1
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15
1
1
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
1
1
How many vCPUs have you got and what type of CPU is reported in
grep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.– Nils
Jun 20 '12 at 19:33
How many vCPUs have you got and what type of CPU is reported in
grep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.– Nils
Jun 20 '12 at 19:33
1
1
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
1
1
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
1
1
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15
|
show 4 more comments
2 Answers
2
active
oldest
votes
You're question is well defined, but you're not giving a lot of information about your environment, how you're currently monitoring or what graphing tools you're using. However, given that SNMP is used pretty much universally for that I'll assume that you're using it and have at least some familiarity with it.
Although (as near as I can tell) the CPU Steal time isn't currently available from snmpd, you can extend it yourself with the UCD-SNMP-MIB::extOutput object and exec commands.
The easiest way (that I've found) to get the steal time is from iostat. Using the following construct we can get just the steal time:
$ iostat -c | awk 'NR==4 print $5'
0.00
Therefore, append the following to your snmpd.conf:
exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 print $5'
(Alternatively you can put the command in a wrapper script and call the wrapper from inside snmpd.conf.)
Each exec call in snmpd.conf is indexed starting from 1. So if you only have a single exec statement then you'll want to poll UCD-SNMP-MIB::extOutput.1. If this is the 5th exec statement then poll UCD-SNMP-MIB::extOutput.5, etc.
The numeric OID for UCD-SNMP-MIB::extOutput is .1.3.6.1.4.1.2021.8.1.101 so if you're at index 1 it would be .1.3.6.1.4.1.2021.8.1.101.1, and index 5 would be .1.3.6.1.4.1.2021.8.1.101.5, etc.
You then create a graph polling that SNMPD OID of type gauge, ranging from 0–100. This should give you some pretty graphs.
edited Dec 21 '18 at 0:38
slm♦
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time thesnmpdis queried for that OID.
– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
add a comment |
sar -u might be helpful in your case. sar is normally part of the sysstat-package.
answered Jun 20 '12 at 19:43
Nils
12.4k73670
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f41206%2ftools-for-monitoring-steal-time-st%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You're question is well defined, but you're not giving a lot of information about your environment, how you're currently monitoring or what graphing tools you're using. However, given that SNMP is used pretty much universally for that I'll assume that you're using it and have at least some familiarity with it.
Although (as near as I can tell) the CPU Steal time isn't currently available from snmpd, you can extend it yourself with the UCD-SNMP-MIB::extOutput object and exec commands.
The easiest way (that I've found) to get the steal time is from iostat. Using the following construct we can get just the steal time:
$ iostat -c | awk 'NR==4 print $5'
0.00
Therefore, append the following to your snmpd.conf:
exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 print $5'
(Alternatively you can put the command in a wrapper script and call the wrapper from inside snmpd.conf.)
Each exec call in snmpd.conf is indexed starting from 1. So if you only have a single exec statement then you'll want to poll UCD-SNMP-MIB::extOutput.1. If this is the 5th exec statement then poll UCD-SNMP-MIB::extOutput.5, etc.
The numeric OID for UCD-SNMP-MIB::extOutput is .1.3.6.1.4.1.2021.8.1.101 so if you're at index 1 it would be .1.3.6.1.4.1.2021.8.1.101.1, and index 5 would be .1.3.6.1.4.1.2021.8.1.101.5, etc.
You then create a graph polling that SNMPD OID of type gauge, ranging from 0–100. This should give you some pretty graphs.
edited Dec 21 '18 at 0:38
slm♦
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time thesnmpdis queried for that OID.
– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
add a comment |
You're question is well defined, but you're not giving a lot of information about your environment, how you're currently monitoring or what graphing tools you're using. However, given that SNMP is used pretty much universally for that I'll assume that you're using it and have at least some familiarity with it.
Although (as near as I can tell) the CPU Steal time isn't currently available from snmpd, you can extend it yourself with the UCD-SNMP-MIB::extOutput object and exec commands.
The easiest way (that I've found) to get the steal time is from iostat. Using the following construct we can get just the steal time:
$ iostat -c | awk 'NR==4 print $5'
0.00
Therefore, append the following to your snmpd.conf:
exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 print $5'
(Alternatively you can put the command in a wrapper script and call the wrapper from inside snmpd.conf.)
Each exec call in snmpd.conf is indexed starting from 1. So if you only have a single exec statement then you'll want to poll UCD-SNMP-MIB::extOutput.1. If this is the 5th exec statement then poll UCD-SNMP-MIB::extOutput.5, etc.
The numeric OID for UCD-SNMP-MIB::extOutput is .1.3.6.1.4.1.2021.8.1.101 so if you're at index 1 it would be .1.3.6.1.4.1.2021.8.1.101.1, and index 5 would be .1.3.6.1.4.1.2021.8.1.101.5, etc.
You then create a graph polling that SNMPD OID of type gauge, ranging from 0–100. This should give you some pretty graphs.
edited Dec 21 '18 at 0:38
slm♦
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time thesnmpdis queried for that OID.
– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
add a comment |
You're question is well defined, but you're not giving a lot of information about your environment, how you're currently monitoring or what graphing tools you're using. However, given that SNMP is used pretty much universally for that I'll assume that you're using it and have at least some familiarity with it.
Although (as near as I can tell) the CPU Steal time isn't currently available from snmpd, you can extend it yourself with the UCD-SNMP-MIB::extOutput object and exec commands.
The easiest way (that I've found) to get the steal time is from iostat. Using the following construct we can get just the steal time:
$ iostat -c | awk 'NR==4 print $5'
0.00
Therefore, append the following to your snmpd.conf:
exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 print $5'
(Alternatively you can put the command in a wrapper script and call the wrapper from inside snmpd.conf.)
Each exec call in snmpd.conf is indexed starting from 1. So if you only have a single exec statement then you'll want to poll UCD-SNMP-MIB::extOutput.1. If this is the 5th exec statement then poll UCD-SNMP-MIB::extOutput.5, etc.
The numeric OID for UCD-SNMP-MIB::extOutput is .1.3.6.1.4.1.2021.8.1.101 so if you're at index 1 it would be .1.3.6.1.4.1.2021.8.1.101.1, and index 5 would be .1.3.6.1.4.1.2021.8.1.101.5, etc.
You then create a graph polling that SNMPD OID of type gauge, ranging from 0–100. This should give you some pretty graphs.
edited Dec 21 '18 at 0:38
slm♦
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
You're question is well defined, but you're not giving a lot of information about your environment, how you're currently monitoring or what graphing tools you're using. However, given that SNMP is used pretty much universally for that I'll assume that you're using it and have at least some familiarity with it.
Although (as near as I can tell) the CPU Steal time isn't currently available from snmpd, you can extend it yourself with the UCD-SNMP-MIB::extOutput object and exec commands.
The easiest way (that I've found) to get the steal time is from iostat. Using the following construct we can get just the steal time:
$ iostat -c | awk 'NR==4 print $5'
0.00
Therefore, append the following to your snmpd.conf:
exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 print $5'
(Alternatively you can put the command in a wrapper script and call the wrapper from inside snmpd.conf.)
Each exec call in snmpd.conf is indexed starting from 1. So if you only have a single exec statement then you'll want to poll UCD-SNMP-MIB::extOutput.1. If this is the 5th exec statement then poll UCD-SNMP-MIB::extOutput.5, etc.
The numeric OID for UCD-SNMP-MIB::extOutput is .1.3.6.1.4.1.2021.8.1.101 so if you're at index 1 it would be .1.3.6.1.4.1.2021.8.1.101.1, and index 5 would be .1.3.6.1.4.1.2021.8.1.101.5, etc.
You then create a graph polling that SNMPD OID of type gauge, ranging from 0–100. This should give you some pretty graphs.
edited Dec 21 '18 at 0:38
slm♦
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
edited Dec 21 '18 at 0:38
slm♦
247k66511678
edited Dec 21 '18 at 0:38
slm♦
247k66511678
edited Dec 21 '18 at 0:38
slm♦
247k66511678
247k66511678
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
answered Jun 20 '12 at 18:42
bahamat
24.2k14890
24.2k14890
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time thesnmpdis queried for that OID.
– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
add a comment |
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time thesnmpdis queried for that OID.
– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
Great answer. How often will these statics be gathered? Just during poll, or is there a way like in the RMON-MIB that will record values without external poll?
– Nils
Jun 20 '12 at 19:36
I believe it would pull this each time the
snmpd is queried for that OID.– bahamat
Jun 20 '12 at 21:47
I believe it would pull this each time the
snmpd is queried for that OID.– bahamat
Jun 20 '12 at 21:47
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
If iostat is not installed: top -bn1 | sed -nr '3s/.*,//gp'
– davide
Nov 25 '14 at 1:51
add a comment |
sar -u might be helpful in your case. sar is normally part of the sysstat-package.
answered Jun 20 '12 at 19:43
Nils
12.4k73670
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
add a comment |
sar -u might be helpful in your case. sar is normally part of the sysstat-package.
answered Jun 20 '12 at 19:43
Nils
12.4k73670
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
add a comment |
sar -u might be helpful in your case. sar is normally part of the sysstat-package.
answered Jun 20 '12 at 19:43
Nils
12.4k73670
sar -u might be helpful in your case. sar is normally part of the sysstat-package.
answered Jun 20 '12 at 19:43
Nils
12.4k73670
answered Jun 20 '12 at 19:43
Nils
12.4k73670
answered Jun 20 '12 at 19:43
Nils
12.4k73670
answered Jun 20 '12 at 19:43
Nils
12.4k73670
12.4k73670
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
add a comment |
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
I wish I could set more than one answer as the accepted answer. Both answers have been very useful :-) Thank you!
– mgjk
Jun 22 '12 at 15:27
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2funix.stackexchange.com%2fquestions%2f41206%2ftools-for-monitoring-steal-time-st%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
1
Virtual dedicated? In case of XEN they would need to pin dedicated cores for dedicated use in your VM. Looks like your provider has overbooked CPUs by a unfair amout. What does he say to this?
– Nils
Jun 20 '12 at 18:56
1
How many vCPUs have you got and what type of CPU is reported in
grep "model name" /proc/cpuinfo|sort -u? If this really a dedicated server then there is something eating up CPU-time on the Dom0. OR they gave you more vCPUs than are available in the Dom0.– Nils
Jun 20 '12 at 19:33
1
Unless this is a momentary outlier, it looks like your isp is lieing to you and they are, in fact, running other cpu heavy vms on this machine, or there is something configured very wrong that is causing dom0 to hog a lot of cpu time.
– psusi
Jun 21 '12 at 3:33
1
SuSE recommends to reserve two cores solely for the Dom0 so it can do all IO-handling without bothering other VMs. In my eyes that would only be necessary for systems with stolen time in the DomUs AND heavy IO traffic. I wanted to know if your provider assigned more vCPUs than logical cores - like assign 4 vCPUs while only 2 logical CPUs are available in the Dom0 - that would explain "stolen", too (and is a pretty braindead idea - but possible in XEN).
– Nils
Jun 21 '12 at 20:55
1
The root cause of this one turned out to be that the ISP had the VM incorrectly configured. The guest was being told it had more cores than it actually did. This seemed to cause havoc with the scheduling. The ISP couldn't provide intelligent tech support, but we were able to "prove" the problem by disabling odd-numbered cores in /proc. Never a problem since.
– mgjk
Feb 23 '14 at 13:15