- I am monitoring ESX / ESXi 4.x systems using sensors I created in PRTG 9.1 or earlier. On high load (CPU above 80 - 85%) PRTG reports a 'not found' error for those sensors.
- I am monitoring ESX / ESXi 4.x or 5.x systems using sensors I created in PRTG 9.2 or higher. PRTG reports a CPU-load of 100% and higher for this server and I am not aware that any of my virtual machines is creating this load.
What can I do about this?
Article Comments
This article applies to PRTG Network Monitor 9 or later
Processes 'Hanging' on ESX Server
If your VMware CPU sensors report unusually high CPU load and you're pretty sure that those systems do not actually consume as much CPU performance, there might be processes 'hanging' on your VMware system. Usually, this is resolved by a reboot of your VMware hosts.
However, sometimes a reboot is not an option.
Forced Close of 'Hanging' Processes
WARNING: The procedures described in this article are intended for experienced users only! The suggested commands can lead to system crashes and might also cause data loss on your target systems. We recommend you always keep a proper backup at all times.
Connect via SSH, View Processes
In this case, enable SSH on your host(s) and connect using an SSH command line client.
Using the command
esxtop
or
top
you can view the top list of running processes (type q to quit).
In the %SYS column (esxtop)—respectively the %CPU column (top)—you see the current load of the single processes.
Determine Critical Processes
Check if you see one or more of the following processes with high resource consumption. If they exist there are 'hanging' SSH sessions in the background and you should close them:
- ESXi 4.x: Process named Dropbear (i.e. the busybox implementation of SSH)
- ESX 4.x or ESXi 5.x: Process named sshd
Determine IDs of Processes
Commands vary depending on the version of the ESX(i) host. Please see table below.
| System | Execute Command | Where to find Process ID |
|---|
| ESX 4.x | ps -ef | grep sshd: | First number after the user name |
| ESXi 4.x | ps | grep dropbear | First number in the line |
| ESXi 5.x | ps | grep sshd | First number in the line |
Kill Processes
Warning: Follow these instructions only if you know what you're doing! The following commands will also end your own remote SSH connection (and you'll have to reconnect).
For each process, execute the command
kill -9 <processID>
(replace <processID> by the ID you determined before).
Done
This should solve the issue without rebooting your ESX(i) hosts.
Feb, 2012 - Permalink
This article applies to PRTG Network Monitor 9 or later
Processes 'Hanging' on ESX Server
If your VMware CPU sensors report unusually high CPU load and you're pretty sure that those systems do not actually consume as much CPU performance, there might be processes 'hanging' on your VMware system. Usually, this is resolved by a reboot of your VMware hosts.
However, sometimes a reboot is not an option.
Forced Close of 'Hanging' Processes
WARNING: The procedures described in this article are intended for experienced users only! The suggested commands can lead to system crashes and might also cause data loss on your target systems. We recommend you always keep a proper backup at all times.
Connect via SSH, View Processes
In this case, enable SSH on your host(s) and connect using an SSH command line client.
Using the command
esxtoportopyou can view the top list of running processes (type q to quit).In the %SYS column (esxtop)—respectively the %CPU column (top)—you see the current load of the single processes.
Determine Critical Processes
Check if you see one or more of the following processes with high resource consumption. If they exist there are 'hanging' SSH sessions in the background and you should close them:
Determine IDs of Processes
Commands vary depending on the version of the ESX(i) host. Please see table below.
ps -ef | grep sshd:ps | grep dropbearps | grep sshdKill Processes
Warning: Follow these instructions only if you know what you're doing! The following commands will also end your own remote SSH connection (and you'll have to reconnect).
For each process, execute the command
kill -9 <processID>(replace <processID> by the ID you determined before).Done
This should solve the issue without rebooting your ESX(i) hosts.
Feb, 2012 - Permalink