VMware Cloud Community
usmansiddiqui83
Contributor
Contributor

overestimated and incorrect memory usage displayed in vcenter server

Hi,

I have two problems

1) Incorrect memory usage information in Vcenter server (despite applying all critical host patches to ESX host server)

The following patch seems to be developed for fixing this particular problem

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101401...

But after applying All critical patches for Host, patch ESX400-200909401-BG is not applied. Message in the log is "ObseletedByHost" and incorrect

memory usage information is still displayed in vcenter server.For example in vcenter a host or virtual machine is using upto 90% memory and inside that machine it is not even using 40% of the memory assigned.There are many red alerts on vcenter interface.

2)USB devices are not accessible in virtual machines.

Regards

0 Kudos
6 Replies
sflanders
Commander
Commander

Without more information I am not sure if this is relevant or not, but remember the summary information in vCenter Server for a host or VM is not in real time. Which performance option are you selecting to see the utilization? Also, the alerts will often go off once ia problem is noticed (e.g. spiked CPU or memory), but may take quite a while to refresh even if the issue is resolved. As an example, I often see alerts when powering on a VM though once it is fully online the task manager or top displays low CPU/memory utilization.

Hope this helps! === If you find this information useful, please award points for "correct" or "helpful". ===
0 Kudos
VMmatty
Virtuoso
Virtuoso

What you're seeing isn't actually a problem but rather normal behavior when using modern processors like an Intel Nehalem based CPU. I'd strongly suggest reading through the following thread, especially the last two pages, to get a better understanding of why this is happening:

http://communities.vmware.com/message/1262016

The short version is this - the processor you're using uses large memory pages. ESX's transparent page sharing can't share those pages, so there is effectively no memory sharing going on. That's why you see such high memory usage at the host level despite the guest not actually using that much memory. As soon as you start to overcommit memory on that host, the large pages will be broken down into smaller pages and begin to get shared. At that point you'll see the memory numbers go down. Right now there is nothing to worry about.

The patch that you linked doesn't fix the problem (since there really is no actual problem) and instead just fixes the issue where vCenter was firing high memory usage alarms because it thought there was a problem.

Matt | http://www.thelowercasew.com | @mattliebowitz
0 Kudos
RyanWI
Enthusiast
Enthusiast

I'm seeing the same thing on my newer Dell R710's patched to the latest build. 244038. The "fix" patch is obsoleted and I see the same problem. I've purposely forced a "high state" memory condition on two of the ESX hosts in the clsuter by overcommitting and running them at >90% memory usage. TPS is not working. Memory Zero seems incorrect as well. I have a ticket with VMware and a ticket with Dell open. So far no news.

0 Kudos
VMmatty
Virtuoso
Virtuoso

What "problem" are you seeing? If you're seeing high memory usage in the guest, remember that this is completely normal on modern processors such as the Nehalem processors found in your Dell R710. If you haven't overcommitted memory, then you will not see any transparent page sharing occurring.

If you have overcommitted memory, how are you confirming that TPS is not working? Have you looked in esxtop? Remember that page sharing will only kick in if you assign more memory to VMs than is physical in an ESX host. If you don't then you can expect to see almost no memory sharing occurring at all. If that happens it isn't broken and is working as designed.

Matt | http://www.thelowercasew.com | @mattliebowitz
0 Kudos
RyanWI
Enthusiast
Enthusiast

The problem I'm seeing is that the r710 is overcommited and reports 90+ % memory usage.

8:59:52am up 21 days 23:06, 192 worlds; MEM overcommit avg: 0.11, 0.11, 0.11

PMEM /MB: 73718 total: 800 cos, 1010 vmk, 65409 other, 6499 free

VMKMEM/MB: 71983 managed: 4319 minfree, 7141 rsvd, 64315 ursvd, high state

COSMEM/MB: 78 free: 1600 swap_t, 1600 swap_f: 0.00 r/s, 0.00 w/s

NUMA /MB: 36582 ( 6121), 35852 ( 377)

PSHARE/MB: 13368 shared, 2559 common: 10809 saving

SWAP /MB: 137 curr, 0 target: 0.00 r/s, 0.00 w/s

MEMCTL/MB: 0 curr, 0 target, 50021 max

GID NAME MEMSZ GRANT SZTGT TCHD %ACTV %ACTVS %ACTVF %ACTVN MCTL? MCTLSZ MCTLTGT MCTLMAX OVHDUW OVHD OVHDMAX

31 ENTWBWEB03P 4096.00 4096.00 4195.72 614.40 9 10 9 5 Y 0.00 0.00 2661.89 38.44 81.85 148.39

40 APWMAD0D0354 8192.00 8191.47 6326.00 1310.72 9 9 10 4 Y 0.00 0.00 5324.29 54.63 135.15 197.56

41 UTLMAD0P0187 2048.00 1457.19 1547.89 163.84 1 3 2 4 Y 0.00 0.00 1308.54 39.35 72.67 126.56

43 SLES10sp3x64_vs 1024.00 642.54 590.61 10.24 1 0 0 0 Y 0.00 0.00 653.02 24.27 39.55 91.22

45 UTLMAD0P0036 3000.00 2624.34 2848.25 330.00 0 3 2 5 Y 0.00 0.00 1930.97 32.09 52.00 114.55

47 UTLMAD0D0031 4096.00 2382.32 2302.52 81.92 1 0 0 2 Y 0.00 0.00 2472.69 36.41 66.40 127.00

49 APWMAD0P0352 2048.00 2039.18 1993.52 163.84 5 2 4 4 Y 0.00 0.00 1330.81 30.35 55.27 124.06

51 ENTWBWEB03A 2048.00 2033.11 1814.11 204.80 5 5 5 5 Y 0.00 0.00 1330.81 30.35 59.41 124.06

57 APWMAD0P0931 8192.00 8174.34 5434.37 327.68 2 3 2 4 Y 0.00 0.00 5324.29 54.63 118.84 197.56

58 APWMAD0P0357 8192.00 8192.00 7602.99 1310.72 6 7 5 8 Y 0.00 0.00 5324.29 58.68 125.89 239.78

67 APWMAD0A0353 8192.00 8190.87 7020.71 1310.72 6 6 6 8 Y 0.00 0.00 5324.29 54.63 118.07 197.04

70 APLMAD0P0184 8192.00 8168.00 7950.46 2867.20 13 15 15 13 Y 0.00 0.00 5190.25 153.71 306.89 377.80

72 APWMAD0P0359 2048.00 2048.00 1539.50 327.68 6 5 5 4 Y 0.00 0.00 1330.81 30.35 58.75 124.06

74 APWMAD0P0360 8192.00 8192.00 8216.85 1310.72 7 8 7 8 Y 0.00 0.00 5324.29 58.68 116.59 239.78

76 APLMAD0A0168 8192.00 8165.15 7709.72 3276.80 20 17 20 17 Y 0.00 0.00 5190.25 153.71 291.75 364.31

0 Kudos
VMmatty
Virtuoso
Virtuoso

You might do better by posting a new message rather than continuing to reply to this one. You would probably get more people to see your posts.

From what you posted here it looks like memory is overcomitted by 11% and you're saving close to 11GB from Transparent Page Sharing. Without knowing more about what you're actually running as virtual machines it's hard to say if what you're seeing is normal or if you could expect more sharing. How many VMs do you have any how much memory have you allocated to them?

Matt | http://www.thelowercasew.com | @mattliebowitz
0 Kudos