vSphere Performance troubleshooting

“The server has poor performance because the server is running virtual.”
“Virtual server are always slower than physical servers.”
“My vSphere server has 60% CPU utilization but the performance of my Virtual Server is poor.”

When you are a VMware administrator you constantly have to defend your self that it doesn’t matter if a server is virtualized or that it running on physical hardware. But how can you troubleshoot these issues?

In these Performance Troubleshooting series I’m going to explain how you can troubleshoot performance problems in your virtualized environment.
This series will contain the following chapters:

  1. CPU
  2. Memory
  3. Storage
  4. Network
  5. Virtual Machine

If you think I left something out. Let me know!

Before you dive into the different chapters, first let me explain how esxtop works.

Running esxtop
You can run esxtop in 2 different ways. One directly in the ESXi Console (the so called busybox) or remote through the remote CLI command called resxtop.
In case you want to run esxtop on the ESXi console,  login as root and start esxtop by typing the command esxtop followed by a enter.

esxtop

If you want to use resxtop start resxtop on a OS where the remote CLI commands are installed with the following parameters:

esxtop –server [dns or ip adres of ESXi host] –user [username probably root] –password [password of the user]

The option –user and –password are not required. If you don’t provide them as a parameter, you will be prompted for them.

Alter esxtop view
When esxtop is started (it doesn’t matter if this is remote or local) you can alter you view.

Option Result
V (Capital) The esxtop screen will only view Virtual Machines. If V is pressed again all other worlds are displayed again.
f Alters the field list. This enables you to create a custom view.
s Changes the refresh time of the screen. This is default 5 sec.
h Help screen
c CPU view
m Memory view
n Network view
i Interrupt view
d Disk Adapter view
u Disk Devices view
v Disk VM view
p Power State view
# Limits the number of rows displayed in esxtop
w Write the alter config. If you just press enter after pressing w, the default configuration is altered. If you provide a path and file-name you can use this configuration the next time you start esxtop. You will have to provide the option -c with the path of the configuration file.
Example: esxtop -c ~/myesxtopconf.cfg

Running esxtop in batch mode
It’s also possible to start esxtop in batch mode. The results are saved in a CSV file. This can be done with the option -b. With the option -d you can specify the delay for the refresh and the option -n specifies the amount of iterations. Example:

esxtop -c ~/myesxtopconf.cfg -b -d 5 -n 10 > ~/esxtop-output.csv

In this example esxtop is started with a custom configruation file called myesxtopconf.cfg, in batch mode, with a delay of 5, and 10 iterations.
With resxtop you have to provide the IP or DNS name of the ESXi host.

The CSV file can be imported in Microsoft Perfmon for example. Note that if you have a large CSV file the import can take a very long time.

About Michael
Michael Wilmsen is a VMware training/consultant (no specific order) with more than 15 years in the IT industry. Main focus is VMware vSphere, Horizon View and Site Recovery Manager with a deepdive to performance. Michael is VCDX 210, VCAP 4/5 certified, has been rewarded with the vExpert title from 2011, is a PernixPro, Nutanix Tech Champion and a Nutanix Platform Professional.

4 Comments to “vSphere Performance troubleshooting”

  1. By Rogier, December 14, 2011 @ 22:33

    Very good explanation of esxtop, thanks. I was expecting more information on how to interpret this information to track where the bottlenecks are, and what to possibly do about it. Maybe good for a part b of the CPU part of this series (did put it in my RSS)

    • By Mike, December 14, 2011 @ 22:40

      Troubleshooting with esxtop can not be done only by looking at only CPU or memory etc. After Ive written the other parts Im planning a post where it all will come together.
      For now look at the final table with my thresholds.

  2. By Rogier, December 14, 2011 @ 22:33

    Very good explanation of esxtop, thanks. I was expecting more information on how to interpret this information to track where the bottlenecks are, and what to possibly do about it. Maybe good for a part b of the CPU part of this series (did put it in my RSS)

    • By Mike, December 14, 2011 @ 22:40

      Troubleshooting with esxtop can not be done only by looking at only CPU or memory etc. After Ive written the other parts Im planning a post where it all will come together.
      For now look at the final table with my thresholds.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

You must be logged in to post a comment.