Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Aug 2014 17:16:57 +1000
From:      Paul Koch <paul.koch@akips.com>
To:        <freebsd-stable@freebsd.org>
Subject:   10.0 interaction with vmware
Message-ID:  <20140826171657.0c79c54d@akips.com>

next in thread | raw e-mail | index | archive | help

Curious if anyone has an understanding of what actually goes on
with VMWare memory control of a FreeBSD 10 guest when open-vm-tools
is installed and how it could affect performance.

Our typical customer environment is a largish VMWare server with
an appropriate amount of RAM allocated to the guest, which currently
runs FreeBSD 10.0p7 + our software, UFS root, and data stored on a
ZFS partition.  Our software mmaps large database files, does rather
largish data collection (ping, snmp, netflow, syslog, etc) and
mostly cruises along, but performance drops off a cliff in low
memory situations.

We don't install open-vm-tools at the moment, therefore we have a known
amount of memory to work with (ie. what the customer initially=20
configured the guest for), but our customers (or in particular, their
VM guys) would really like vmware tools or open-vm-tools by default.

=46rom what we gather, many sites choose to "over provision" the memory
in the VM setups, and when memory gets low, the host takes back=20
some of the RAM allocated to the guest.

How does this work actually work ?  Does it only take back what
FreeBSD considers to be "free" memory or can the host start taking
back "inactive", "wired", "zfs arc" memory ?  We tend to rely on
stuff being in inactive and zfs arc.  If we start swapping, we
are dead.

Also, is there much of a performance hit if the host steals back
free memory, and then gives it back ?  We'd assume all memory
the host gives to the guest is pre-bzero'ed so the FreeBSD wouldn't
need to also bzero it.

	Paul.
--=20
Paul Koch | Founder, CEO
AKIPS Network Monitor
http://www.akips.com
Brisbane, Australia



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140826171657.0c79c54d>