Thanks, Blue, for the super-generous commentary. I'm continuing this from the original thread (Re: Diagnosing slow Windows guest performance )
For convenience, I'm appending your comments to the end of this post.
Having read them a few times, it looks like they're all excellent information, and play well for good performance over time. The exception is the GPU, which I'll look into later today. (Thanks!)
What's most notable is that your comments don't address the gross breakage I'm seeing ... the slowdown (observed after bootup, once I/O and CPU settle down) is profound. I can watch windows being painted, and slowness in general processing (e.g., Office, Quicken, Paperport file opening and recalc). Because this is so aberrant, I need to investigate further before applying your suggestions.
The previous machine was a fast Lenovo T530 (5 years old), and this troublesome machine is a new Lenovo P51. The T530 beats the P51 under Workstation Pro 12.x enough so that I went to synthetic benchmarking (Novabench) to better understand what affects what. Here are the configurations:
T530: I7-3720QM 2.6GHz, Hyperthreading, 16GB RAM, Windows 10/1703
P51: Xeon E3-1505M v6 3.6GHz, Hyperthreading, 16GB RAM, Windows 10/1703
The P51 should be handily faster than the T530, and it is about 20% faster when not running Workstation Pro. Under Workstation Pro, it's about 20% slower. Gross breakage. FYI, under both systems I allocate 4 cores and 3.1GB RAM to my VM.
As background, Novabench measures "CPU", "RAM", "GPU" and "Disk". The "CPU" and "RAM" measurements scale with the number of cores and GB RAM, but since both physical machines have 4 hyperthreaded cores (8 threads) and 16GB RAM, and the VMs have 4 cores and 3GB RAM, Novabench can report apple-to-apples comparisons. Novabench GPU numbers for the VM are irrelevant, as the VM doesn't pass the GPU through, and the disk numbers aren't calculated because of access permissions unavailable to the VM. Here's what I get ... higher numbers are better:
| Machine | CPU (Host) | RAM (Host) | GPU (Host) | Disk (Host) | CPU (VM) | RAM (VM) |
|---|---|---|---|---|---|---|
| T530 | 763 | 239 | 179 | N/A | 463 | 122 |
| P51 | 900 | 233 | 610 | 136 | 463 | 98 |
CPU(Host): Xeon is clearly faster than I7-3720QM, as expected
RAM(Host): Same speed, a little surprising
GPU(Host): M2200 is much faster, as expected
Disk(Host): ...
CPU(VM): Shows major drag in VM ... expected 550, got 463
RAM(VM): Shows major drag in VM ... expected 122, got 98
So, with due respect for your suggestions, it seems there are deeper problems than the tuning you're recommending. True?
Could this be a Xeon thing?? Any ideas on where to be looking??
Thanks!! (and thanks to anyone else who can weigh in)
------ From previous thread ----------------
@bdemchak2
I have split into several categories. I think it would be best to start another thread if you have more questions.
Video/Display
From the log, the more capable Quadro M2200 is not being used as the "Successfully created a device" immediately follows after VMware finds the Intel P630. Set the default GPU in the Nvidia Control Panel to use Nvidia. With Nvidia Optimus GeForce, that option is available, so it might be available also on mobile Quadro. If the option is not available in the Nvidia Control Panel, add the following line to the vmx configuration file so that the Quadro M2200 is used.
mks.dx11.vendorID = "0x10de"
2017-10-08T18:30:50.386-07:00| mks| W115: DX11Renderer: Enumerating adapter 0
2017-10-08T18:30:50.386-07:00| mks| W115: DX11Renderer: `Intel(R) HD Graphics P630` vendor=0x8086 device=0x591d revision=4
2017-10-08T18:30:50.386-07:00| mks| W115: DX11Renderer: video=128MB system=0MB shared=8095MB
2017-10-08T18:30:50.403-07:00| mks| W115: DX11Renderer: Successfully created a device
2017-10-08T18:30:50.403-07:00| mks| W115: DX11Renderer: Enumerating adapter 1
2017-10-08T18:30:50.403-07:00| mks| W115: DX11Renderer: `NVIDIA Quadro M2200` vendor=0x10de device=0x1436 revision=161
2017-10-08T18:30:50.403-07:00| mks| W115: DX11Renderer: video=4062MB system=0MB shared=8095MB
2017-10-08T18:30:50.404-07:00| mks| W115: DX11Renderer: Enumerating adapter 2
vCPU/Memory
One of the logs shows VM memory swapping every 30 minutes. This is not swapping to pagefile.sys within the VM but the concept is similar. While swapping in of itself isn't an indicator of a problem, the amount swapped increased over time. And if the processes within the VM requires memory that has been swapped out, it may have to wait for it to be swapped back in although fast SSD should not present an issue but the host SSD is split into multiple volumes (see below about Disk).
For memory, it is better to to allocate on 1-gigabyte increments. The 4MB increments guideline has been around even before there was VT-x in Intel chips. With EPT in the Intel chip, there can be 1GB pages. So it would be best to allocate 6144MB (6 x 1024MB) instead of 6200MB.
If the VM is not processor-intensive, it might be better to allocate less vCPU to have a higher per GB per vCPU number even though OS doesn't allocate uniformly per CPU. Since the Windows OS edition is Professional it would be better to allocate two virtual sockets to achieve to 2 or 4 vCPUs (i.e. 2 processors, 1 or 2 cores per processors for 2 x 1 cores or 2 x 2 cores instead of 1 x 2 cores or 1 x 4 cores).
2017-10-08T19:00:50.475-07:00| vmx| I125: MemSched: locked 1547142 target 1601469 balloon 0 0 1031680 swapped 7868 0 allocd 3 512 state 0 100
2017-10-08T19:30:50.501-07:00| vmx| I125: MemSched: locked 1533827 target 1601469 balloon 0 0 1031680 swapped 21808 0 allocd 1 512 state 0 100
2017-10-08T20:00:50.968-07:00| vmx| I125: MemSched: locked 1524069 target 1601469 balloon 0 0 1031680 swapped 32511 0 allocd 1 512 state 0 100
2017-10-08T20:30:51.600-07:00| vmx| I125: MemSched: locked 1508416 target 1601469 balloon 0 0 1031680 swapped 48309 0 allocd 3 512 state 0 100
2017-10-08T21:00:52.102-07:00| vmx| I125: MemSched: locked 1499774 target 1601469 balloon 0 0 1031680 swapped 57145 0 allocd 5 512 state 0 100
2017-10-08T21:30:52.732-07:00| vmx| I125: MemSched: locked 1485281 target 1601469 balloon 0 0 1031680 swapped 71724 0 allocd 1 512 state 0 100
2017-10-08T22:00:53.238-07:00| vmx| I125: MemSched: locked 1483671 target 1601469 balloon 0 0 1031680 swapped 73963 0 allocd 2 512 state 0 100
2017-10-08T22:30:53.855-07:00| vmx| I125: MemSched: locked 1470425 target 1601469 balloon 0 0 1031680 swapped 87305 0 allocd 5 512 state 0 100
2017-10-08T23:00:54.506-07:00| vmx| I125: MemSched: locked 1459580 target 1601469 balloon 0 0 1031680 swapped 98256 0 allocd 13 512 state 0 100
2017-10-08T23:30:54.962-07:00| vmx| I125: MemSched: locked 1448818 target 1601469 balloon 0 0 1031680 swapped 109124 0 allocd 3 512 state 0 100
2017-10-09T00:00:55.633-07:00| vmx| I125: MemSched: locked 1439943 target 1601469 balloon 0 0 1031680 swapped 118057 0 allocd 1 512 state 0 100
2017-10-09T00:30:55.959-07:00| vmx| I125: MemSched: locked 1438267 target 1601469 balloon 0 0 1031680 swapped 120716 0 allocd 3 512 state 0 100
2017-10-09T01:00:56.450-07:00| vmx| I125: MemSched: locked 1435146 target 1601469 balloon 0 0 1031680 swapped 124475 0 allocd 1 512 state 0 100
2017-10-09T01:30:56.711-07:00| vmx| I125: MemSched: locked 1430788 target 1601469 balloon 0 0 1031680 swapped 129142 0 allocd 3 512 state 0 100
2017-10-09T02:00:57.155-07:00| vmx| I125: MemSched: locked 1447321 target 1601469 balloon 0 0 1031680 swapped 113108 0 allocd 3 512 state 0 100
2017-10-09T02:30:57.637-07:00| vmx| I125: MemSched: locked 1436175 target 1601469 balloon 0 0 1031680 swapped 124280 0 allocd 3 512 state 0 100
2017-10-09T03:00:58.289-07:00| vmx| I125: MemSched: locked 1429085 target 1601469 balloon 0 0 1031680 swapped 131485 0 allocd 1 512 state 0 100
2017-10-09T03:30:58.890-07:00| vmx| I125: MemSched: locked 1417044 target 1601469 balloon 0 0 1031680 swapped 143621 0 allocd 15 512 state 0 100
2017-10-09T04:00:59.429-07:00| vmx| I125: MemSched: locked 1410042 target 1601469 balloon 0 0 1031680 swapped 150696 0 allocd 5 512 state 0 100
2017-10-09T04:31:00.042-07:00| vmx| I125: MemSched: locked 1398631 target 1601469 balloon 0 0 1031680 swapped 162206 0 allocd 3 512 state 0 100
2017-10-09T05:01:00.440-07:00| vmx| I125: MemSched: locked 1425378 target 1601469 balloon 0 0 1031680 swapped 135738 0 allocd 4 512 state 0 100
2017-10-09T05:31:01.078-07:00| vmx| I125: MemSched: locked 1413539 target 1601469 balloon 0 0 1031680 swapped 147678 0 allocd 479 512 state 0 100
2017-10-09T06:01:01.563-07:00| vmx| I125: MemSched: locked 1407668 target 1601469 balloon 0 0 1031680 swapped 153676 0 allocd 31 512 state 0 100
2017-10-09T06:31:02.140-07:00| vmx| I125: MemSched: locked 1397888 target 1601469 balloon 0 0 1031680 swapped 163534 0 allocd 20 512 state 0 100
Disk
I see that there are many logical drives even though there is only one physical SSD in the host. Same goes with the VM, multiple virtual drives with only one virtual SCSI controller. Eventually, the single controller would become a bottleneck if the multiple logical drives are receiving read/write requests. With hard disk platters, this would come in the form of the single controller and single drive arm being the resource in contention. With SSD, I would think it would be the command queue in the controller. With the VM, the virtual SCSI controller becomes the potential bottleneck for the different virtual disks. See if you can reduce the number of virtual disks on the VM and the number of logical drives on the host SSD.
DisplayLink
It looks like you have a DisplayLink dock device. I used to have a USB 2.0 DisplayLink graphic adapter with a Windows 7 laptop; even without VMware running, occasionally CPU usage would spike for the dwm.exe process (Windows Display Manager) for an extended period of time (I didn't figure out why but found the difference was the DisplayLink being attached). You may want to compare performance with and without the DisplayLink dock.