Hi,
I try to migrate a Win2003-Client (2CPU / 3GB RAM) from a other well-known virtualisation platform to proxmox (i use raw-format for the disk drives).
Therefor the VM rip a huge postscriptfile - under the original vm (different hardware) it's take 4:20 (min:sec). This must to beat the pants off with proxmox.
The test-server has a 3Ghz AMD PhenomII X4 cpu (945) with 4GB-ECC-DDR3-Ram and an areca arc1212 raid-controller.
The first test with the actual pve-version 1.4 give 5:30. Damn! The rip-prozess need io and cpu, and the storage are only old sata-drives.
So, i invest in two fast sas-drives and split the drives - two sata as mirror for boot and pve-root and the two sas as stripe (not safe, but fast - this is only for test) for pve-data and swap. All partition are aligned - to get the maximum performance.
The results of pveperf are ok:
Due to the postings in the forum about the performance with pve-1.4 i first try pve-1.3 with the sas-drives. The ripping takes 3:45. thats ok, but not the best. Aften an upgrade to the actual 1.4 the ripping takes 5:07! Thats bad.
In a second test i take a WinXP-VM with one cpu and run h2benchw (www.heise.de) - this tests only disk-io. I got nearly the same results under pve-1.3 and pve-1.4 (app. an index of 80, sometime "only" 69). After switching to 2 cpus (at pve-1.4), i got very bad results (down to a index of 6 with negative read-timing-results).
Next test was 2 cores instead of 2 cpus. The results are app. an index of 45 (35-55). Better, but less than with one cpu - and also with timing problems (neg. seek.time).
The same test with 2 cpus on pve-1.3 shows also negatives seek-times and an index of 16 up to 60 (very unsteady).
I don't know, perhaps the results change if a server with 2 CPUs (and not only cores) are used.
As result, for VMs with bigger io-load i don't use more than one CPU. Unfortunately some software on the clients need more than one cpu.
I will do the ripping of the postscriptfile with one cpu as next test. But that's not so easy becourse the original server is in production and must switch off for the test.
Udo
I try to migrate a Win2003-Client (2CPU / 3GB RAM) from a other well-known virtualisation platform to proxmox (i use raw-format for the disk drives).
Therefor the VM rip a huge postscriptfile - under the original vm (different hardware) it's take 4:20 (min:sec). This must to beat the pants off with proxmox.
The test-server has a 3Ghz AMD PhenomII X4 cpu (945) with 4GB-ECC-DDR3-Ram and an areca arc1212 raid-controller.
The first test with the actual pve-version 1.4 give 5:30. Damn! The rip-prozess need io and cpu, and the storage are only old sata-drives.
So, i invest in two fast sas-drives and split the drives - two sata as mirror for boot and pve-root and the two sas as stripe (not safe, but fast - this is only for test) for pve-data and swap. All partition are aligned - to get the maximum performance.
The results of pveperf are ok:
Code:
# pveperf /var/lib/vz
CPU BOGOMIPS: 24082.13
REGEX/SECOND: 602977
HD SIZE: 251.00 GB (/dev/mapper/pve-data)
BUFFERED READS: 232.39 MB/sec
AVERAGE SEEK TIME: 5.68 msIn a second test i take a WinXP-VM with one cpu and run h2benchw (www.heise.de) - this tests only disk-io. I got nearly the same results under pve-1.3 and pve-1.4 (app. an index of 80, sometime "only" 69). After switching to 2 cpus (at pve-1.4), i got very bad results (down to a index of 6 with negative read-timing-results).
Next test was 2 cores instead of 2 cpus. The results are app. an index of 45 (35-55). Better, but less than with one cpu - and also with timing problems (neg. seek.time).
The same test with 2 cpus on pve-1.3 shows also negatives seek-times and an index of 16 up to 60 (very unsteady).
I don't know, perhaps the results change if a server with 2 CPUs (and not only cores) are used.
As result, for VMs with bigger io-load i don't use more than one CPU. Unfortunately some software on the clients need more than one cpu.
I will do the ripping of the postscriptfile with one cpu as next test. But that's not so easy becourse the original server is in production and must switch off for the test.
Udo
