insufficiently W2008r performance, which runs inclined ?

[ravistellus]

We test even different virtualisations solutions, also Proxmox 3.1, operation and options of this environment please us particularly well.
On an IBM x3850M2 4X6 core Xeon 2,66GHz/96GB RAM 8 X 15KSAS we habe 3 VM's W2008r2, one is a Terminal Server for 16 Users, but the performance is however unacceptable, the servers load with a test run all day long between 80 -100% was. Which could be false at my configuration?

the node:
root@x3850m2:~# pveperf
CPU BOGOMIPS: 127926.96
REGEX/SECOND: 1068422
HD SIZE: 94.49 GB (/dev/mapper/pve-root)
BUFFERED READS: 374.80 MB/sec
AVERAGE SEEK TIME: 3.63 ms
FSYNCS/SECOND: 2457.92
DNS EXT: 48.60 ms
DNS INT: 47.72 ms (highendsmoke.local)

root@x3850m2:~# pveversion -v
proxmox-ve-2.6.32: 3.1-114 (running kernel: 2.6.32-26-pve)
pve-manager: 3.1-21 (running version: 3.1-21/93bf03d4)
pve-kernel-2.6.32-26-pve: 2.6.32-114
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-2
pve-cluster: 3.0-8
qemu-server: 3.1-8
pve-firmware: 1.0-23
libpve-common-perl: 3.0-8
libpve-access-control: 3.0-7
libpve-storage-perl: 3.0-17
pve-libspice-server1: 0.12.4-2
vncterm: 1.1-4
vzctl: 4.0-1pve4
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.1-1

VM
root@x3850m2:/etc/pve/qemu-server# cat 106.conf
bootdisk: virtio0
cores: 4
memory: 32768
name: SC-TS-CleanInstall
net0: virtio=42:96:8F:AC:F92,bridge=vmbr0
ostype: win7
sockets: 4
tablet: 0
virtio0: local:106/vm-106-disk-1.raw,format=raw,cache=none,size=850G
virtio1: NFS-Raid5:106/vm-106-disk-2.raw,format=raw,cache=none,size=500G
root@x3850m2:/etc/pve/qemu-server#

best regards
Stephan

 

[udo]

... Which could be false at my configuration?


virtio1: NFS-Raid5:106/vm-106-disk-2.raw,format=raw,cache=none,size=500G

Hi Stephan,
perhaps the nfs-performance is the problem?

Does the same happens with local storage only?

Udo

 

[ravistellus]

Hi Udo,

thanks for reply! No, the disk @ NFS Storage is only for WindowsServerBackup, the Win2K8r2 run form the local storage.
With only local storage is the same problem.

Stephan

 

[udo]

Hi,
ist the cpu-load only inside the VM, or also with top on the host visible?
Any "high" io-wait/system values with top?

I had an issue with an w2k8-server which need a very long time to switch off (with 24GB ram). after downsizing the ram to 12GB the server switch off in a normal time...
Perhpas you should try (only for test) with fewer ram?

Udo

 

[ravistellus]

Hi Udo,

the high cpu-load is in top of the host, without any io-wait (max 0,3%). I will try with fewer RAM and post the result.
Possibly it is a problem with NUMA and/or CPU pinning, is there a possibility , similarly as under KVM@CentOS for set CPU pinning?

Stephan

 

[spirit]

which applications do you use in your windows guest ?

 

[ravistellus]

Hi Spirit,

thanks for reply, this W2K8r2 Standard Server runs as a Terminal Server for 14-16 Users with MS Office 2010 & Addison http://www.addison.de (Tax Consulting Software) the DB-Server for this runs on a other VM @ the same Host. The DC for this runs on a other Host.

Stephan

 

[ravistellus]

Hi Folks,

today we have a test run with fewer ram, but no significantly modification of the cpu load, 12-14 user normal working 90-100% CPU Load without any io-wait.

Someone has ideas in addition?

Stephan

 

[jbennet]

Although it is not exactly the same hardware, your are perhaps hitting this proxmox-openvz-kernel bug (http://forum.proxmox.com/threads/14800-pve-(host)-vs-ubuntu-performance), where it basically runs as if the hyperthreaded cores were disabled.

If you are still able to carry out some quick test against another KVM host.. it might be interesting to compare the performance with some standard benchmark (e.g. phoronix-test-suite).

 

[Nachtfalke]

If you are using MSSQL you could check this here:
http://pve.proxmox.com/wiki/Performance_Tweaks#Microsoft_SQL_Server

 

[ravistellus]

Hi Nachtfalke,

i know this, but we are don't have a MSSQL server on this machine.

Yesterday i running a test with 7zip benchmark, 1 Core = 2033MIPS | 4 Core = 7324MIPS ( 1927 MIPS per Core) | 16 Core = 6431MIPS ( 869 Mips per Core)

Stephan

 

[ravistellus]

yesterday we made a test with Centos 6,4 and KVM, result better performance in the VM, but with CPU pinning

Stephan

 

[ravistellus]

Hi Folks,

perhaps is it because of it that the L3 cache of the host on the guest does not arrive?



root@x3850m2:~# dmidecode -t cache
# dmidecode 2.11
SMBIOS 2.4 present.


Handle 0x0043, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 9216 kB
Maximum Size: 4096 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x0044, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 16384 kB
Maximum Size: 32768 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x0046, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 9216 kB
Maximum Size: 4096 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x0047, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 16384 kB
Maximum Size: 32768 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x0049, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 9216 kB
Maximum Size: 4096 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x004A, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 16384 kB
Maximum Size: 32768 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x004C, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 9216 kB
Maximum Size: 4096 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative


Handle 0x004D, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 16384 kB
Maximum Size: 32768 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative



@win2008r2 Guest
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.


C:\Users\sbsadmin>wmic.exe cpu get l3cachesize
L3CacheSize
0

 

[jbennet]

I have a similar "L3 cache" output between host and VM. But I don't think it can explain our cpu performance issues.

On top of that, our benchmarks revealed issues when testing directly on the host, so I would still blame the old RHEL kernel+patches.