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.
Add comment