Virtual machine memory usage vmware ошибка

Июн 27, 2017 10:20

Часть 1. Про CPU
Часть 3. Про Storage

В этой статье поговорим про счетчики производительности оперативной памяти (RAM) в vSphere.
Вроде бы с памятью все более однозначно, чем с процессором: если на ВМ возникают проблемы с производительностью, их сложно не заметить. Зато если они появляются, справиться с ними гораздо сложнее. Но обо всем по порядку.

Немного теории

Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, ESXi начинает применять техники оптимизации потребления оперативной памяти (memory reclamation techniques). В противном случае операционные системы ВМ падали бы с ошибками доступа к ОЗУ.

Какие техники применять ESXi решает в зависимости от загруженности оперативной памяти:

Источник

minFree — это оперативная память, необходимая для работы гипервизора.

До ESXi 4.1 включительно  minFree по умолчанию было фиксированным — 6% от объема оперативной памяти сервера (процент можно было поменять через опцию Mem.MinFreePct на ESXi). В более поздних версиях из-за роста объемов памяти на серверах minFree стало рассчитываться исходя из объема памяти хоста, а не как фиксированное процентное значение.

Значение minFree (по умолчанию) считается следующим образом:

Источник

Например, для сервера со 128 Гбайт RAM значение MinFree будет таким:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайт = 1,88 Гбайт
Фактическое значение может отличаться на пару сотен МБайт, это зависит от сервера и оперативной памяти.

Обычно для продуктивных стендов нормальным можно считать только состояние High. Для стендов для тестирования и разработки приемлемыми могут быть состояния Clear/Soft. Если оперативной памяти на хосте осталось менее 64% MinFree, то у ВМ, работающих на нем, точно наблюдаются проблемы с производительностью.

В каждом состоянии применяются определенные memory reclamation techniques начиная с TPS, практически не влияющего на производительность ВМ, заканчивая Swapping’ом. Расскажу про них подробнее.

Transparent Page Sharing (TPS). TPS — это, грубо говоря, дедупликация страниц оперативной памяти виртуальных машин на сервере.

ESXi ищет одинаковые страницы оперативной памяти виртуальных машин, считая и сравнивая hash-сумму страниц, и удаляет дубликаты страниц, заменяя их ссылками на одну и ту же страницу в физической памяти сервера. В результате потребление физической памяти снижается и можно добиться некоторой переподписки по памяти практически без снижения производительности.

Источник

Данный механизм работает только для страниц памяти размером 4 Кбайт (small pages). Страницы размером 2 МБайт (large pages) гипервизор дедуплицировать даже не пытается: шанс найти одинаковые страницы такого размера не велик.

По умолчанию ESXi выделяет память большим страницам. Разбивание больших страниц на маленькие начинается при достижении порога состояния High и происходит принудительно, когда достигается состояние Clear (см. таблицу состояний гипервизора).

Если же вы хотите, чтобы TPS начинал работу, не дожидаясь заполнения оперативной памяти хоста, в Advanced Options ESXi нужно установить значение “Mem.AllocGuestLargePage” в 0 (по умолчанию 1). Тогда выделение больших страниц памяти для виртуальных машин будет отключено.

С декабря 2014 во всех релизах ESXi TPS между ВМ по умолчанию отключен, так как была найдена уязвимость, теоретически позволяющая получить из одной ВМ доступ к оперативной памяти другой ВМ. Подробности тут. Информация про практическую реализацию эксплуатации уязвимости TPS мне не встречалось.

Политика TPS контролируется через advanced option “Mem.ShareForceSalting” на ESXi:
0 — Inter-VM TPS. TPS работает для страниц разных ВМ;
1 – TPS для ВМ с одинаковым значением “sched.mem.pshare.salt” в VMX;
2 (по умолчанию) – Intra-VM TPS. TPS работает для страниц внутри ВМ.

Однозначно имеет смысл выключать большие страницы и включать Inter-VM TPS на тестовых стендах. Также это можно использовать для стендов с большим количеством однотипных ВМ. Например, на стендах с VDI экономия физической памяти может достигать десятков процентов.

Memory Ballooning. Ballooning уже не такая безобидная и прозрачная для операционной системы ВМ техника, как TPS. Но при грамотном применении с Ballooning’ом можно жить и даже работать.

Вместе с Vmware Tools на ВМ устанавливается специальный драйвер, называемый Balloon Driver (он же vmmemctl). Когда гипервизору начинает не хватать физической памяти и он переходит в состояние Soft, ESXi просит ВМ вернуть неиспользуемую оперативную память через этот Balloon Driver. Драйвер в свою очередь работает на уровне операционной системы и запрашивает свободную память у нее. Гипервизор видит, какие страницы физической памяти занял Balloon Driver, забирает память у виртуальной машины и возвращает хосту. Проблем с работой ОС не возникает, так как на уровне ОС память занята Balloon Driver’ом. По умолчанию Balloon Driver может забрать до 65% памяти ВМ.

Если на ВМ не установлены VMware Tools или отключен Ballooning (не рекомендую, но есть KB:), гипервизор сразу переходит к более жестким техникам отъема памяти. Вывод: следите, чтобы VMware Tools на ВМ были.

Работу Balloon Driver’а можно проверить из ОС через VMware Tools.

Memory Compression. Данная техника применяется, когда ESXi доходит до состояния Hard. Как следует из названия, ESXi пытается сжать 4 Кбайт страницы оперативной памяти до 2 Кбайт и таким образом освободить немного места в физической памяти сервера. Данная техника значительно увеличивает время доступа к содержимому страниц оперативной памяти ВМ, так как страницу надо предварительно разжать. Иногда не все страницы удается сжать и сам процесс занимает некоторое время. Поэтому данная техника на практике не очень эффективна.

Memory Swapping. После недолгой фазы Memory Compression ESXi практически неизбежно (если ВМ не уехали на другие хосты или не выключились) переходит к Swapping’у. А если памяти осталось совсем мало (состояние Low), то гипервизор также перестает выделять ВМ страницы памяти, что может вызвать проблемы в гостевых ОС ВМ.

Вот как работает Swapping. При включении виртуальной машины для нее создается файл с расширением .vswp. По размеру он равен незарезервированной оперативной памяти ВМ: это разница между сконфигурированной и зарезервированной памятью. При работе Swapping’а ESXi выгружает страницы памяти виртуальной машины в этот файл и начинает работать с ним вместо физической памяти сервера. Разумеется, такая такая “оперативная” память на несколько порядков медленнее настоящей, даже если .vswp лежит на быстром хранилище.

В отличие от Ballooning’а, когда у ВМ отбираются неиспользуемые страницы, при Swapping’e на диск могут переехать страницы, которые активно используются ОС или приложениями внутри ВМ. В результате производительность ВМ падает вплоть до подвисания. ВМ формально работает и ее как минимум можно правильно отключить из ОС. Если вы будете терпеливы

Если ВМ ушли в Swap — это нештатная ситуация, которую по возможности лучше не допускать.

Основные счетчики производительности памяти виртуальной машины

Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:

Active — показывает объем оперативной памяти (Кбайт), к которому ВМ получила доступ в предыдущий период измерения.

Usage — то же, что Active, но в процентах от сконфигурированной оперативной памяти ВМ. Рассчитывается по следующей формуле: active ÷ virtual machine configured memory size.
Высокий Usage и Active, соответственно, не всегда является показателем проблем производительности ВМ. Если ВМ агрессивно использует память (как минимум, получает к ней доступ), это не значит, что памяти не хватает. Скорее это повод посмотреть, что происходит в ОС.
Есть стандартный Alarm по Memory Usage для ВМ:

Shared — объем оперативной памяти ВМ, дедуплицированной с помощью TPS (внутри ВМ или между ВМ).

Granted — объем физической памяти хоста (Кбайт), который был отдан ВМ. Включает Shared.

Consumed (Granted — Shared) — объем физической памяти (Кбайт), которую ВМ потребляет с хоста. Не включает Shared.

Если часть памяти ВМ отдается не из физической памяти хоста, а из swap-файла или память отобрана у ВМ через Balloon Driver, данный объем не учитывается в Granted и Consumed.
Высокие значения Granted и Consumed — это совершенно нормально. Операционная система постепенно забирает память у гипервизора и не отдает обратно. Со временем у активно работающей ВМ значения данных счетчиков приближается к объему сконфигурированной памяти, и там остаются.

Zero — объем оперативной памяти ВМ (Кбайт), который содержит нули. Такая память считается гипервизором свободной и может быть отдана другим виртуальным машинам. После того, как гостевая ОС получила записала что-либо в зануленную память, она переходит в Consumed и обратно уже не возвращается.

Reserved Overhead — объем оперативной памяти ВМ, (Кбайт) зарезервированный гипервизором для работы ВМ. Это небольшой объем, но он обязательно должен быть в наличии на хосте, иначе ВМ не запустится.

Balloon — объем оперативной памяти (Кбайт), изъятой у ВМ с помощью Balloon Driver.

Compressed — объем оперативной памяти (Кбайт), которую удалось сжать.

Swapped — объем оперативной памяти (Кбайт), которая за неимением физической памяти на сервере переехала на диск.
Balloon и остальные счетчики memory reclamation techniques равны нулю.

Вот так выглядит график со счетчиками Memory нормально работающей ВМ со 150 ГБ оперативной памяти.

На графике ниже у ВМ явные проблемы. Под графиком видно, что для данной ВМ были использованы все описанные техники работы с оперативной памятью. Balloon для данной ВМ сильно больше, чем Consumed. По факту ВМ скорее мертва, чем жива.

ESXTOP

Как и с CPU, если хотим оперативно оценить ситуацию на хосте, а также ее динамику с интервалом до 2 секунд, стоит воспользоваться ESXTOP.

Экран ESXTOP по Memory вызывается клавишей «m» и выглядит следующим образом (выбраны поля B,D,H,J,K,L,O):

Интересными для нас будут следующие параметры:

Mem overcommit avg — среднее значение переподписки по памяти на хосте за 1, 5 и 15 минут. Если выше нуля, то это повод посмотреть, что происходит, но не всегда показатель наличия проблем.

В строках PMEM/MB и VMKMEM/MB — информация о физической памяти сервера и памяти доступной VMkernel. Из интересного здесь можно увидеть значение minfree (в МБайт), состояние хоста по памяти (в нашем случае, high).

В строке NUMA/MB можно увидеть распределение оперативной памяти по NUMA-нодам (сокетам). В данном примере распределение неравномерное, что в принципе не очень хорошо.

Далее идет общая статистика по серверу по memory reclamation techniques:

PSHARE/MB — это статистика TPS;

SWAP/MB — статистика использования Swap;

ZIP/MB — статистика компрессии страниц памяти;

MEMCTL/MB — статистика использования Balloon Driver.

По отдельным ВМ нас может заинтересовать следующая информация. Имена ВМ я скрыл, чтобы не смущать аудиторию:). Если метрика ESXTOP аналогична счетчику в vSphere, привожу соответствующий счетчик.

MEMSZ — объем памяти, сконфигурированный на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted в МБайт.

TCHD — Active в МБайт.

MCTL? — установлен ли на ВМ Balloon Driver.

MCTLSZ — Balloon в МБайт.

MCTLGT — объем оперативной памяти (МБайт), который ESXi хочет изъять у ВМ через Balloon Driver (Memctl Target).

MCTLMAX — максимальный объем оперативной памяти (МБайт), который ESXi может изъять у ВМ через Balloon Driver.

SWCUR — текущий объем оперативной памяти (МБайт), отданный ВМ из Swap-файла.

SWGT — объем оперативной памяти (МБайт), который ESXi хочет отдавать ВМ из Swap-файла (Swap Target).

Также через ESXTOP можно посмотреть более подробную информацию про NUMA-топологию ВМ. Для этого нужно выбрать поля D,G:

NHN – NUMA узлы, на которых расположена ВМ. Здесь можно сразу заметить wide vm, которые не помещаются на один NUMA узел.

NRMEM – сколько мегабайт памяти ВМ берет с удаленного NUMA узла.

NLMEM – сколько мегабайт памяти ВМ берет с локального NUMA узла.

N%L – процент памяти ВМ на локальном NUMA узле (если меньше 80% — могут возникнуть проблемы с производительностью).

Memory на гипервизоре

Если счетчики CPU по гипервизору обычно не представляют особого интереса, то с памятью ситуация обратная. Высокий Memory Usage на ВМ не всегда говорит о наличие проблемы с производительностью, а вот высокий Memory Usage на гипервизоре, как раз запускает работу техник управления памятью и вызывает проблемы с производительностью ВМ. За алармами Host Memory Usage надо следить и не допускать попадания ВМ в Swap.

Unswap

Если ВМ попала в Swap, ее производительность сильно снижается. Следы Ballooning’а и компрессии быстро исчезают после появления свободной оперативной памяти на хосте, а вот возвращаться из Swap в оперативную память сервера виртуальная машина совсем не торопится.
До версии ESXi 6.0 единственным надежным и быстрым способ вывода ВМ из Swap была перезагрузка (если точнее выключение/включение контейнера). Начиная с ESXi 6.0 появился хотя и не совсем официальный, но рабочий и надежный способ вывести ВМ из Swap. На одной из конференций мне удалось пообщаться с одним из инженеров VMware, отвечающим за CPU Scheduler. Он подтвердил, что способ вполне рабочий и безопасный. В нашем опыте проблем с ним также замечено не было.

Собственно команды для вывода ВМ из Swap описал Duncan Epping. Не буду повторять подробное описание, просто приведу пример ее использования. Как видно на скриншоте, через некоторое время после выполнения указанной команд Swap на ВМ исчезает.

Советы по управлению оперативной памятью на ESXi

Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:

• Не допускайте переподписки по оперативной памяти в продуктивных кластерах. Желательно всегда иметь ~20-30% свободной памяти в кластере, чтобы у DRS ( и у администратора) было пространство для маневра, и при миграции ВМ не ушли в Swap. Также не забывайте про запас для отказоустойчивости. Неприятно, когда при выходе из строя одного сервера и перезагрузке ВМ с помощью HA часть машин еще и уходит в Swap.
• В инфраструктурах с высокой консолидацией старайтесь НЕ создавать ВМ с памятью больше половины памяти хоста. Это опять же поможет DRS’у без проблем распределять виртуальные машины по серверам кластера. Это правило, разумеется, не универсальное :).
• Следите за Host Memory Usage Alarm.
• Не забывайте ставить на ВМ VMware Tools и не выключайте Ballooning.
• Рассмотрите возможность включения Inter-VM TPS и выключения Large Pages в средах с VDI и тестовых средах.
• Если ВМ испытывает проблемы с производительностью, проверьте не использует ли она память с удаленной NUMA-ноды.
• Выводите ВМ из Swap как можно быстрее! Помимо всего прочего, если ВМ в Swap’е, по очевидным причинам страдает СХД.

На этом про оперативную память у меня все. Ниже статьи по теме для тех, кто хочет углубиться в детали. Следующая статья будет посвящена стораджу.

Excessive memory consumption can cause performance issues for hosts and virtual machines. When a host is under pressure in terms of available physical memory, it may have to begin swapping memory to disk, which will negatively affect virtual machine performance.

I’ve previously written an article about monitoring memory performance using esxtop, but will cover the main metrics to be aware of when troubleshooting memory performance issues here. The memory page in esxtop is a good place to start:

 6:03:11pm up  1:18, 329 worlds, 4 VMs, 5 vCPUs; MEM overcommit avg: 0.50, 0.50, 0.50
PMEM  /MB:  4095   total:   883     vmk,  1258 other,   1953 free
VMKMEM/MB:  4077 managed:   244 minfree,  3062 rsvd,   1015 ursvd,  high state
PSHARE/MB:  2855  shared,    97  common:  2758 saving
SWAP  /MB:   257    curr,   241 rclmtgt:                 0.00 r/s,   0.00 w/s
ZIP   /MB:    26  zipped,    15   saved
MEMCTL/MB:  1330    curr,  1330  target,  3327 max
View VM only
     GID NAME               MEMSZ    GRANT    SZTGT     TCHD   TCHD_W    SWCUR    SWTGT   S
    3991 XP2              3072.00  3048.00   879.75    92.16    61.44     0.75     0.00
    3988 XP1              2048.00   503.92   175.12    43.03    21.51     5.46     3.88
    4004 TestVM08          700.00    61.86    90.16     0.00     0.00     0.00     0.00
    4007 TestVM07          128.00    56.99    80.79     2.56     0.00     0.00     0.00

There is a lot of data here, so I’ll break down what some of the metrics are.

• PMEM/MB – This is the amount of physical memory on the host. In this case it is 4095 MB.  VMK refers to the memory being used by the VMKernel, Other is the amount of memory being used by everything other than the VMkernel and Free, is the amount of free memory.
• VMKMEM/MB – This is the amount of physical memory currently managed by the VMkernel.  4077 MB. ‘Min Free’ is the amount of memory that the VMkernel aims to keep free (this can be tweaked with the mem.memfreepct advanced setting). ‘rsvd’ is the amount of memory reserved by resource pools. ‘ursvd’ is the amount of memory that is currently unreserved.
• PSHARE – This is the savings made by Transparent Page Sharing – The memory savings here are 2758MB from the 4 virtual machines that are running.
• State – The host is currently in the ‘high’ state. This is an indication of whether the host is currently reclaiming memory. More on this later.
• SWAP/MB – This is the total memory swapped out for all virtual machines on the host. ‘curr’ shows the current swap usage, r/s and w/s show the rate that ESXi is swapping memory to disk
• ZIP/MB – These are the memory compression statistics
• MEMCTL/MB – These are the memory balloon statistics.

Below these are the virtual machine specific counters, which include:

• MEMSZ – the amount of memory allocated to the virtual machine
• MCTLSZ – When > 0 the host is forving VMs to inflate balloon driver to reclaim memory.
• SWR/s –  If > 0 then the host is swapping memory in from disk.
• SWW/s – If > 0 then the host is swapping memory out to disk.
• SWCUR – The amount of swap space in use by the VM. A value greater than zero indicates that the host has previously swapped memory.
• SWTGT – The amount of swap space the host anticipates would be in use by a VM.
• SWPWT – Percentage of time a virtual machine is waiting for memory to be swapped back in from disk. A value exceeding five should be acted upon.
• MCTL – Displays whether or not the balloon driver is installed on the virtual machine.
• ZIP – If > 0 the host is actively compressing memory.
• UNZIP – if > 0 the host has accessed compressed memory.

Host Swapping and Memory Reclaimation

When a host is suffering from a lack of memory resources it will attempt to reclaim memory that it has already handed out to virtual machines. There are four host ‘free memory’ states, which indicate whether a host is attempting to reclaim memory. These are High, Soft, Hard and Low.

The state the host is currently in can be see clearly on the memory screen in ESXTOP:

11:40:06pm up 30 min, 326 worlds, 2 VMs, 3 vCPUs; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM  /MB:  4095   total:   878     vmk,   416 other,   2800 free
VMKMEM/MB:  4077 managed:   244 minfree,  3192 rsvd,    885 ursvd,  high state
PSHARE/MB:    39  shared,    21  common:    18 saving
SWAP  /MB:     0    curr,     0 rclmtgt:                 0.00 r/s,   0.00 w/s
ZIP   /MB:     0  zipped,     0   saved
MEMCTL/MB:     0    curr,     0  target,    36 max

The example output above shows a host in the ‘High’ state, which means it is not currently under memory contention. If the host is in the ‘Soft’ state then ballooning is used to reclaim memory. In ‘Hard’, Swapping and compression is used to reclaim, and when the host is in the ‘Low’ state, ballooning, swapping and compression are all used to attempt to reclaim memory. Swapping will have a negative affect on the performance of the host and virtual machines – you can monitor swapping by using the Swap In and Swap Out metrics in vCenter. On a healthy host, these values should always be low:

If the host has been or is under memory contention you will see something more along the lines of:

It is likely that the state will have changed in esxtop at this time:

 5:25:56am up  6:16, 344 worlds, 4 VMs, 5 vCPUs; MEM overcommit avg: 0.50, 0.50, 0.48
PMEM  /MB:  4095   total:   885     vmk,  2948 other,    261 free
VMKMEM/MB:  4077 managed:   244 minfree,  3020 rsvd,   1057 ursvd,  soft state
PSHARE/MB:  1444  shared,   154  common:  1290 saving
SWAP  /MB:   161    curr,   160 rclmtgt:                 0.02 r/s,   0.00 w/s
ZIP   /MB:    15  zipped,     9   saved
MEMCTL/MB:  1167    curr,  1310  target,  3327 max

As shown above, the host is in the ‘soft’ state, meaning that it is actively ballooning in order to reclaim memory. We can confirm that ballooning has occurred by adding the Balloon metric to the chart:

The state is good indication of what shape the hosts memory is in. If the host is actively swapping there will be performance degradation for the virtual machine(s). To see whether swapping is affecting a given virtual machine, you can use the %SWPWT metric, which is found on the CPU page in esxtop:

ID      GID NAME                      NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT
    3991     3991 XP2                 7   37.70   38.04    0.62  660.30   11.35    1.80   50.09    0.98    0.00    0.00   12.12
    3988     3988 XP1                 8    3.77    3.78    0.06  793.56    4.17    2.81  189.73    0.08    0.00    0.00    2.90
    4004     4004 TestVM08            6    0.22    0.21    0.01  599.57    0.00    0.34  100.10    0.00    0.00    0.00    0.00
    4007     4007 TestVM07            6    0.20    0.20    0.00  599.39    0.00    0.53  100.04    0.00    0.00    0.00    0.00

%SWPWT shows the percentage of time that a virtual machine is waiting for it’s pages to be swapped. In the example above we can see that the XP2 (and to a lesser extent, XP1) virtual machine is waiting for it’s pages to be swapped, which will negatively affect the VMs performance. Any value above zero indicates a problem. If the value is above 5 then the cause should be investigated immediately.

With this example the cause was due to memory over commitment, with both of the XP virtual machines using all their memory allocation at the same time. It’s also worth checking whether the balloon drivers are present in the virtual machines that are swapping, as without the driver the host may be forced to swap rather than use ballooning (which has a lower impact). The balloon drivers get installed onto the guest VM when you install VMtools. You can check that the balloon drivers are present and enabled by looking at the ‘MCTL?’ column:

 GID NAME                 MEMSZ    GRANT    SZTGT     TCHD     TCHD_W  MCTL?   MCTLSZ  MCTLTGT  MCTLMAX
    3991 XP2              3072.00  3048.14   576.71   153.60   122.88     Y     0.00     0.00  1996.46
    3988 XP1              2048.00   505.10   188.94    35.86    28.68     Y  1330.86  1330.86  1330.86
    4004 TestVM08          700.00    61.86    90.41     0.00     0.00     N     0.00     0.00     0.00
    4007 TestVM07          128.00    56.99    81.25     2.56     0.00     N     0.00     0.00     0.00

A ‘Y’ indicates that the balloon drivers are present in the virtual machine and enabled.

Анализ производительности ВМ в VMware vSphere. Часть 2: Memory

Разбираем, как не допустить проблем с производительностью виртуальной машины из-за памяти.

When I run a virtual machine in VMware workstation, after a few minutes of use, it uses all my RAM (16GB). My system performance slows down to a crawl. The problem happens with Linux guest too but its worse with Windows guest. In VMware Workstation Preferences I have Reserved Memory set to 2GB, and specified to fit all virtual machine memory into reserved host RAM but that didn’t help despite docs recommendation.

Does anyone know how to stop VMware Workstation from using up all my RAM when I run a guest Virtual Machine?

I don’t have the problem with VirtualBox and I have tried to re-install VMware Workstation and the problem persist. I’d stop using it but there are some projects that require me to use VMware.

Here are further details:

When I run free -m in the terminal when VMware Workstation is open but no guest running (before firing up the VM):

             total       used       free     shared    buffers     cached
Mem:         15945       3370      12575        198         23        696
-/+ buffers/cache:       2650      13295
Swap:        19072         74      18998

After starting a Windows 10 Guest and running for a few min, if I run free -m in my host I get:

             total       used       free     shared    buffers     cached
Mem:         15945      15694        251       2182         66      12158
-/+ buffers/cache:       3468      12477
Swap:        19072         74      18998

When I shutdown the Windows 10 guest and run free -m again:

             total       used       free     shared    buffers     cached
Mem:         15945      13499       2446        197         67      10209
-/+ buffers/cache:       3223      12722
Swap:        19072         74      18998

To get my RAM back I have to run:
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches and then I run free -m I get:

             total       used       free     shared    buffers     cached
Mem:         15945       3312      12633        198          2        642
-/+ buffers/cache:       2667      13278
Swap:        19072         74      18998

System Host and Guest Specs

//////////////////////////////////////
System Host:
Ubuntu 14.04LTS
VMware Workstation 12 Pro Version: 12.1.1 build-3770994
///////////////////////////////////////

//////////////////////////////////////
VM Guest:
Windows10
RAM: 1984MB
Processors: 1
DisplayRAM: 1GB
///////////////////////////////////////

//////////////////////////////////////
Motherboard:
ASUS AMD M5 A97 R2.0
///////////////////////////////////////

///////////////////////////////////////
CPU:
AM3+ AMD FX 8320 8-Core 
3.5GHz 16MB Total Cache, (5GHz Max)
///////////////////////////////////////

///////////////////////////////////////
Graphics Card:
ZOTAC Nvidia Geforce GT 730
4GB DDR3 64-bit HDCP
DUAL-Link DVI, HDMI, VGA
///////////////////////////////////////

///////////////////////////////////////
RAM: 16GB
Kingston Hyperx 
2x8GB Memory Sticks 
1866 DDR3 240-pin
///////////////////////////////////////

////////////////////////////////////////
POWER SUPPLY:
EVGA 1000w PS
1000GQ
80+ Gold series
///////////////////////////////////////

Update, 19th September 16

(Note that this is additional information by @granjow, which hopefully represents the OP’s experience.)

To add some clarifications, the problem is not that the number in the “free memory” column is small and we are just unhappy about this number because large numbers are nicer. The problem is that system performance is actually terrible.

The problem manifests itself as follows: After starting the VM and some programs, the amount of free memory drops, which is to be expected. The amount of memory used by VMware rises far over the configured limit (i.e. 10 GB instead of 4 GB, with only 8 GB of physical RAM in total). At some point, both guest and host start freezing for > 10 s on several occasions: for example navigating in files in WebStorm (guest), opening a new browser tab or terminal tab or just pressing Alt-Tab (host).

When observing CPU load on those occasions, the guest CPU usage goes to 100 % for as long as the system freezes, but no program is showing up as busy in the task manager. Basically, I can observe the typical symptoms of a system running out of RAM and heavily using the disk as cache. When observing the VMware log, there is often a line about ballooning kicking in, which is said to be the very intelligent mechanism of VMware which manages and releases memory freed by the guest.

We are not talking about bad specs of the host machine, because

• exactly the same VM has been running on exactly the same hardware on Windows 10 smoothly without ever experiencing performance issues
• the same VM, imported in VirtualBox on Ubuntu, runs equally well as with VMware on Windows 10, with htop/glances showing constant memory usage of around 4.6 GB, and with no freezes at all.