Check the memory utilisation by the procedure mentioned below.
1.Checking memory with the VMware Infrastructure Client
As an example, I have taken screenshots from a host with 64 GB of physical RAM with 29 VMs running on it. In the first screenshot, we go to the VMware Infrastructure Client (VI Client), select the host and watch the summary tab. In the right-hand corner, we see the "Resources" section. The image below shows that memory usage is at 41.06 GB out of 64 GB.
From this image, we can see that 41.06 GB of memory is in use out of an available 64. But wouldn't you also like to know which processes or VMs are using the 41.06 GB? To find out, we'll use PuTTY as our SSH client to run VMware ESXtop tool
Let's start a Putty. Log on, start esxtop and press M for memory. The top of the screen features an impressive amount of info on your host's memory usage.
Let's take it from the top.
The MEM overcommit avg tells us that the average memory overcommitment over the past one is between five and 15 minutes. A value of 0.20 is a 20% overcommitment of memory. In the second line, we see the PMEM stats that describe physical memory in the host. This host has 65,534 MB (or 63.99 GB), of which 800 MB is allocated to the cos (i.e., the service console); 672 MB is being used by the VMkernel and 4,0437 MB (or 39.489 GB) is used by "other," which leaves 23,624 MB of free memory.
Note: The memory used by "other" is officially described as: "everything other than the ESX Service Console and ESX VMkernel." It is not necessarily all memory consumed by the VM. Each VM, for example, also has memory overhead. The amount of overhead memory depends on the type of guest OS,the number of virtual CPUs, configured amount of guest memory and on whether the guest is 32-bit or 64-bit. For example, a dual-CPU virtual machine with 2,048 MB memory will have 126 MB overhead as 32-bit system and 163 MB overhead as a 64-bit system.
The next line about VMKMEM is of less importance, though it does tell you how the VMkernel performs. But unless you're troubleshooting an unusual problem, you won't work with these values. Of more value is how the service console (cos) is doing, which is detailed on the next line. The first value (in this case, free) is the amount of idle memory in your cos. In our example, the cos has 92 MB RAM free out of the 800 MB allocated. Next, we see the swap space configured and swap space free, which are both 1,600 MB. Usually, I configure a host with a 1,600 MB swap partition and 800 MB cos memory.
While 800 MB may seem like a lot, third-party agents often run in the console and so the default 272 MB of memory is not enough. In that event, you want to increase cos memory and set it to 800 MB. You could set it for a higher number, but you might run out of partition space. I therefore always set the swap partition to 1,600 MB since you can also assign only a maximum of 1,600 MB to the cos. Since implementing that as a best practice, I haven't had to resize a swap partition once.
Hope it may help
Mark as final or helpful if sounds ok