• 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

Service Console Memory, a common misunderstanding (ESX 4.0+)

Duncan Epping · Sep 21, 2010 ·

I was reading the Maximum vSphere book by Eric Siebert today and noticed something that I also spotted in Scott Lowe’s Mastering VMware Sphere book. Both Scott and Eric described the fact that the default amount of assigned Service Console memory for ESX has been increased from 272MB to X. I deliberately use “X” as both Eric and Scott mention a different value in their book.

The reason both Scott and Eric mention a different value in their book can be easily explained though, and I wrote about this a while ago, as of vSphere 4.0 there is no default value anymore. I gave this feedback to Scott a while back and of course he asked where this was documented. Back then it was nowhere to be found, well except for on my blog but that is not an official VMware publication. I asked our KB team to update the KB article that explains Service Console memory and I just noticed that they have:

src

ESX 4.x hosts – the default amount of RAM is dynamically configured to a value between 300MB and 800MB, depending on the amount of RAM that is installed in the host. For example, if the host has 32GB of memory the service console RAM will be set to 500MB, while a host which has 128GB of RAM will see the service console RAM set to 700MB. The maximum has not changed from 800MB, which would be seen on hosts with 256GB of RAM or higher, if it is being dynamically allocated.

This is exactly what I observed almost a year ago:

  • ESX Host – 8GB RAM -> Default allocated Service Console RAM = 300MB
  • ESX Host – 16GB RAM -> Default allocated Service Console RAM = 400MB
  • ESX Host – 32GB RAM -> Default allocated Service Console RAM = 500MB
  • ESX Host – 64GB RAM -> Default allocated Service Console RAM = 602MB
  • ESX Host – 96GB RAM -> Default allocated Service Console RAM = 661MB
  • ESX Host – 128GB RAM -> Default allocated Service Console RAM = 703MB
  • ESX Host – 256GB RAM -> Default allocated Service Console RAM = 800MB

Just wanted to point this out as I am certain that many people will not be aware of this.

Share it:

  • Tweet

Related

Server, Various 4.0, ESX, memory, vSphere

Reader Interactions

Comments

  1. Mike Laverick says

    21 September, 2010 at 10:57

    Yeah, I recently discovered this myself, after writing the vSphere4 book. I does appear in the newer design course… I guess the issue here is that in the effort to get books out in a timely fashion, something gives on the technical accuracy side – because often these niceties don’t come out or become officially documented until sometime after a GA date….

  2. dale says

    21 September, 2010 at 12:48

    Thanks for the info I certainly assumed the memory was a static allocation regardless of RAM size

  3. tom miller says

    21 September, 2010 at 13:14

    So what happens when you add RAM to a server and did not perform a custom install to maximize the swap file? I don’t see how this can dynamically adjust in that situation. Many times I follow your recommendation on vSphere partitions to adjust swap file to max so you don’t have to worry about this setting. By the way since we are being forced to ESXi after 4.1, how do you perform a custom install with ESXi?

  4. Duncan Epping says

    21 September, 2010 at 13:28

    @Tom:

    1) Swap is an issue indeed it will not be increased so you either accept you have less swap or reinstall
    2) ESXi doesn’t have “Service Console” memory so that is no issue. It does allow you to do a scripted install these days. Just check the ESXi install guide for that 🙂

  5. Jelle Kalf says

    21 September, 2010 at 14:32

    Thanks for the information. Something I didn’t know, only knew part of this by observations during installations.

    Keep feeding more good stuff 😀

  6. Forbes Guthrie says

    21 September, 2010 at 16:23

    It’s probably worth pointing out that VMware states in their documentation that 600MB is the “recommended minimum”, but then goes on to say “Use the default value applied during installation”. I always thought that was a little contradictory.

    I’d love to know more about ESXi partitioning, and what were the scripted install options if there were any. There isn’t anything in the official documentation per se, but I’ll be downloading the “ESXi internals” talk from VMworld as soon as its online, as this was mentioned there. Unfortunately I missed some of the talk so I need to review it to clarify what was said. Duncan, might be a good topic for you to blog about if you have access to anything internal about this, as there really isn’t that much available publicly at the moment.

  7. Duncan Epping says

    21 September, 2010 at 16:32

    I have access to a lot of internal stuff, but there is a good reason it is internal 🙂

  8. Forbes Guthrie says

    21 September, 2010 at 21:28

    Oh come on! Such a tease.

  9. Russell says

    22 September, 2010 at 00:08

    Adding swap to an existing system isn’t terribly hard:

    dd if=/dev/zero of=/path/to/swapfile.swap bs=2G count=1
    mkswap /path/to/swapfile.swap
    echo /path/to/swapfile.swap swap swap defaults 0 0 >> /etc/fstab
    swapon -a

    Though generally if your service console is actually hitting swap there are bigger issues at play.

  10. Russell says

    22 September, 2010 at 00:14

    To clarify:
    My previous post creates a 2GB file filled with zeroes
    Makes it a valid swapfile
    Appends the location to the end of fstab
    Then tells linux to go ahead and access it.

    If you wanted more then just pick a bigger size with the dd command and you’re set.

    That said I tend to monitor my service console for swap usage and when I hit the high water mark I increase RAM to avoid it in the future. My rule of thumb has always been “when you hit swap in the console you’re running too much in the console.”

  11. Guy Kalti says

    23 September, 2010 at 03:10

    All of us need more possibilities in order to help save our planet. Great learning about this.

  12. Justin Galbraith says

    27 September, 2010 at 23:30

    yes, we found this out when we initially moved to ESX 4.0 from 3.5. Since 4.0 dynamically allocation SC memory, the 3.5 deployment script which was looking for 272MB to change to 800 no longer functioned. To counter this change, we wrote an updated deployment script which updated any SC memory value to 800.

    sed -i -e ‘/boot\/memSize/s|”.*”|”800″|’ /etc/vmware/esx.conf
    sed -i -e ‘s/^.*uppermem.*/uppermem 819200/g’ -e ‘s/mem=.*M/mem=800M/g’ /boot/grub/grub.conf

  13. Cerro says

    25 October, 2010 at 12:49

    vimsh -ne “hostsvc/memoryinfo 838860800”

    this upgrade to 800Mb

    Bye

  14. Rob says

    7 November, 2013 at 08:11

    When I create a Host Profile based on a ESXi 5.0 host there is a configuration item for “Service console memory reservation”. Seems odd given there is no service console. Perhaps it is simply for backwards compatibility.

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

29-08-2022 – VMware Explore US
07-11-2022 – VMware Explore EMEA
….

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2022 · Log in