LXD Windows Server 2019 performance validation

LXD
,
1

Recently I have been benchmarking the performance of a Windows Server 2019 VM instance on LXD and comparing its performance values to that of a Ubuntu 20.04 VM instance to see if it would be viable for a production setup.

The Phoronix Test Suite was used to run performance tests on both instances. Following are the test suites executed in each category:

  • CPU - 7zip, C-RAY
  • Memory - OSBench, t-test1
  • Disk - IOZone, SQLite, pgbench

The test suites can be found over at OpenBenchmarking.

Following is the ratio ( Windows / Linux performance results ) for each test:

image
image590×677 48.9 KB

From these results we can see that while some variation is present, the most significant ones are the results related to disk IO and DB operations, where the Windows VM had significantly worse performance.

With this post I wanted to confirm whether these results are similar to the ones observed by the community as the Windows DB operation performance is rather poor.

Following is some additional information regarding the host machine and the instances:

Host:

  • CPU - AMD Opteron Processor 6348
  • Memory - Hynix HMT31GR7CFR4C-PB (8GB * 4)
  • Storage - Toshiba MG04SCA40EE 4TB (x4 in RAID 6 configuration with both read and write cache enabled)

The LXD storage pool driver is LVM:

info:
  description: ""
  driver: lvm
  name: default
  space used: 267.43GB
  total space: 7.89TB
used by:
  images:
  - 62b292b5a57e02d19d90ae99af4684323d029882bd98291c6ce77f5cc9b0a79f
  - 8b7992e7ca8ceef5d7205365dd1cbca01a5a35b5512bb0d72a621cf4da376982
  - a8402324842148ccfcbacbc69bf251baa9703916593089f0609e8d45e3185bff
  - cee305252934f842b4d9422ba378221bde8e893d35e1a62c40269823ec9b963c
  instances:
  - lxdui-container
  - private-ip-container
  - private-ip-vm
  - vpn-test
  - windows-test

Both Ubuntu and Windows Server 2019 instances were assigned 12 CPU cores and 16 GB memory, the tests were run on each instance separately.

Following are both instance configurations:

Ubuntu:

architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 20.04 LTS amd64 (release) (20211129)
  image.label: release
  image.os: ubuntu
  image.release: focal
  image.serial: "20211129"
  image.type: disk-kvm.img
  image.version: "20.04"
  limits.cpu: "12"
  limits.memory: 16GB
  volatile.base_image: 8b7992e7ca8ceef5d7205365dd1cbca01a5a35b5512bb0d72a621cf4da376982
  volatile.eth0.host_name: tap98c5b2bb
  volatile.eth0.hwaddr: 00:16:3e:b9:de:6a
  volatile.last_state.power: RUNNING
  volatile.uuid: 958d2e03-1345-4648-9b91-797ccaa0c778
  volatile.vsock_id: "20"
devices:
  root:
    path: /
    pool: default
    size: 20GB
    type: disk
ephemeral: false
profiles:
- vm-private
stateful: false
description: ""

Windows:

architecture: x86_64
config:
  limits.cpu: "12"
  limits.memory: 16GB
  security.secureboot: "false"
  volatile.base_image: cee305252934f842b4d9422ba378221bde8e893d35e1a62c40269823ec9b963c
  volatile.eth0.host_name: tapbeb313cd
  volatile.eth0.hwaddr: 00:16:3e:7f:af:5b
  volatile.last_state.power: RUNNING
  volatile.uuid: 37ff6b50-52d5-4c4b-92bf-f6a206b68150
  volatile.vsock_id: "14"
devices:
  root:
    path: /
    pool: default
    size: 500GB
    type: disk
ephemeral: false
profiles:
- vm-private
stateful: false
description: ""

Any input is appreciated :slightly_smiling_face:

1 Like
2

That’s interesting, it’d then either suggest some underlying issue in Windows itself as far as how it processes I/O or that the Windows virtio-scsi driver has some kind of performance issue.

1 Like
3

Would be great if somebody in the community could peer review this. We can share our spreadsheet with the raw data.

P.S.: I am working with @yang in real world use cases for LXD (datacenter, all-office in 1U) with IaC.

4

After taking the conversation over to the Windows Virtio drivers github page, the following was recommended to us:

I noticed that the VMs executed with the -cpu host option, how can we add the hv_time (i.e.: -cpu host,hv_time) option to it?

I have looked through the generated /var/snap/lxd/common/lxd/logs/windows-test/qemu.conf file but couldn’t find a solution.

5
2 Likes
6

You may be able to have LXD do it for you before this change by setting raw.qemu to -cpu host,hv_passthrough

1 Like