Mike Fischer <fischer+o...@lavielle.com> writes:
>
> Could this be caused by something on the VMWare host machine? (The
> host seems to be operating at limit regarding RAM for example. But the
> VM is only using the normal percentage of its allocated RAM — way
> below 100% and very constant usage, no swap.)
>
...snip...
The machines are very similar (RAM, CPU, storage, OS version), but here
is the one I \
rebooted:
...snip...
OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023
r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277010432 (4078MB)
avail mem = 4127657984 (3936MB)
...snip...
bios0: vendor Phoenix Technologies LTD version "6.00" date 12/12/2018
bios0: VMware, Inc. VMware Virtual Platform
...snip...
cpu0 at mainbus0: apid 0 (boot processor)
...snip...
cpu1 at mainbus0: apid 2 (application processor)
...
You have to fix two problems in VMware before you can look at your
guests.
First, you say VMware is at it's limit for memory. Don't forget that
VMware is
a rebranded and hacked up Linux kernel....it is an operating system and
should
not be overcommitted in RAM. In this state performance is
unpredictable. You
should leave 10% or 20% RAM uncommitted.
Second, you have dual-core guests. On a VMware system, this guest has
to wait for exactly two cores to become available before it can be
scheduled.
The busyness of other guests controls this, not VMware and not OpenBSD.
A single-core guest improves the schedulability by the VMware kernel.
I suggest you are complaining on the wrong list.
J
