• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

esxtop -l ?

Duncan Epping · Jun 2, 2010 ·

I received a couple of questions around my esxtop article yesterday so I guess it wasn’t completely clear what “locked” meant. I had a difficult time understanding it myself but I was fortunate enough that one of my colleagues (Thanks Valentin) got to the bottom of it and emailed me the following explanation. I rewrote parts of it and this is the outcome, hope that it clears things up:

As most of you know esxtop takes snapshots from VSI nodes (similar to proc nodes) to capture the running entities and their states. The rate in which these snapshots are taken can be changed with the “s”. The default setting is 5 seconds and the minimum, which most people probably use, is 2 seconds. This means that every entity (worlds, for instance a virtual machine) and the associated info is queried again every two seconds. As many of the metrics shown in esxtop are calculated based on the difference of two successive snapshots, e.g. %USED (CPU), esxtop just rereads all the info(all entities and all values) and calculates the values of the metrics.

As you can imagine this can cause stress on your CPU in a very large environment. The reason for this is the amount of data that needs to be gathered for these entities and the amount of calculations which need to take place. However, with “lock mode” enabled only the changing states from those entities will be read from the VSI nodes. The entities(VMs, Worlds, LUNs etc) themselves will be copied over from the first snapshot that was taken when esxtop was started. This does however mean that when a new helper world is spawned or a virtual machine is powered on or VMotioned to the host it will not appear within esxtop until esxtop is restarted!

Below you see an example of entities and values that will definitely not change as long as esxtop with lock mode is running. All other stats will be updated and you are still free to select whatever fields you want, everything will be available as if nothing happened.

Since those entities and their relations don’t have to be read and calculated every time, esxtop’s CPU consumption will drop significantly. Again, please note that when a new VM is powered on, a VM is vMotion to the host or a new world is created it will not show up within esxtop when “-l” is used as the entities are locked! This also applies to starting esxtop in batch mode with -b.

Related

Server, Various esxtop, performance

Reader Interactions

Comments

  1. Craig Risinger says

    2 June, 2010 at 20:05

    Changing the delay between updates will of course also reduce load much. Try “-d ” if calling in batch mode (-b).

    Batch mode puts out values in comma-separated values format, which you can redirect to a file:
    esxtop -b -a -d 20 > my_esxtop_data_allFields.csv

    The first row will be the header, which gives the names and order of every field. Every subsequent row will be just the values.

    So if VMs were created during the run, you’d have to add more columns and therefore reprint a new header row. So that’s presumably why batch mode implies locked mode.

  2. Duncan Epping says

    4 June, 2010 at 13:15

    Correct, changing the delay will also reduce workload. However changing the delay also means that it’s not really real time monitoring.

  3. Josh Coen says

    31 July, 2010 at 13:00

    Duncan, I wanted to leave this in the ESXTOP post you have pinned to the top, but the option wasn’t available.

    A good thing to mention in the ESXTOP post would be utilizing vifs to move the csv file for individuals using ESXi/vMA. Maybe there is another way to do it, but this was the only way I could find after a bit of research.

    vifs –server –username –password –put “[] /”

  4. Josh Coen says

    31 July, 2010 at 13:02

    seems you can’t use lt/gt combos

    vifs –server –username –password –put filename “[datastorename] folder/filename”

  5. rotary laser levels says

    7 October, 2010 at 17:39

    I like this site and saw it on AOL search. I think your thoughts on esxtop -l ? » Yellow Bricks are right on. Thanks for blogging about this and looking forward to reading more on your site.

  6. rotary laser levels says

    7 October, 2010 at 17:39

    I utterly liked reading about esxtop -l ? » Yellow Bricks and think it was well worth the read. The only other site I found on Bing wasnt as good as this one, thanks.

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

May 24th – VMUG Poland
June 1st – VMUG Belgium
Aug 21st – VMware Explore
Sep 20th – VMUG DK
Nov 6th – VMware Explore
Dec 7th – Swiss German VMUG

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2023 · Log in