[Kerridge0]

There's a big difference for me, (stock soft raid-1), 94.31 vs 510.61
:-

before:

root:~# pveversion -v
pve-manager: 1.6-2 (pve-manager/1.6/5087)
running kernel: 2.6.32-3-pve
pve-kernel-2.6.32-3-pve: 2.6.32-18
qemu-server: 1.1-18
pve-firmware: 1.0-7
libpve-storage-perl: 1.0-14
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-7
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1dso1
root:~# pveperf
CPU BOGOMIPS:      27602.51
REGEX/SECOND:      742807
HD SIZE:           9.92 GB (/dev/md1)
BUFFERED READS:    127.29 MB/sec
AVERAGE SEEK TIME: 7.55 ms
FSYNCS/SECOND:     94.31
DNS EXT:           88.21 ms
DNS INT:           19.08 ms (ovh.net)

after:

root:~# pveversion -v
pve-manager: 1.6-5 (pve-manager/1.6/5261)
running kernel: 2.6.18-4-pve
proxmox-ve-2.6.18: 1.6-8
pve-kernel-2.6.32-3-pve: 2.6.32-18
pve-kernel-2.6.18-4-pve: 2.6.18-8
qemu-server: 1.1-22
pve-firmware: 1.0-9
libpve-storage-perl: 1.0-14
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-8
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1dso1
pve-qemu-kvm-2.6.18: 0.9.1-8
root:~# pveperf
CPU BOGOMIPS:      27603.04
REGEX/SECOND:      742812
HD SIZE:           9.92 GB (/dev/md1)
BUFFERED READS:    124.84 MB/sec
AVERAGE SEEK TIME: 7.43 ms
FSYNCS/SECOND:     510.61
DNS EXT:           34.27 ms
DNS INT:           47.45 ms (ovh.net)

[Antennipasi]

Due networking problem with OpenVZ i tried stable pve-kernel-2.6.18-4-pve, and surprisingly it is lot faster in FSYNCS/SECOND: 453.37 vs. 324.57 with pve-kernel-2.6.32-4-pve.
Could someone try without hw-raid?

[DigitalDaz]

This is a new EG AMD with hardware raid, there is nothing at all on it except proxmox, should I be worried?

root@ns213686:~# pveperf /var/lib/vz
CPU BOGOMIPS: 27602.41
REGEX/SECOND: 772080
HD SIZE: 1375.55 GB (/dev/mapper/pve-data)
BUFFERED READS: 121.66 MB/sec
AVERAGE SEEK TIME: 13.48 ms
FSYNCS/SECOND: 19.65
DNS EXT: 75.02 ms
DNS INT: 18.77 ms (ovh.net)

[Antennipasi]

Check out http://forum.ovh.co.uk/showthread.php?t=4781
bartoll does not mention if he has hw-raid on EG AMD, but still changing scheduler gives interesting results. AFAIK "deadline" is considered to be default scheduler for KVM-only kernels.

I enabled write cache on raid-controller and got FSYNCS/SECOND: 324.57 afterwards. better by factor 15 than previous, an probably limit with this card. Scheduler changes did not affect with hw-raid.

And yes, i know enabling cache without battery backup-unit is not all-wise

[Winit]

I'm seeing similar buffered reads without hard RAID.

[Antennipasi]

All I can say is, if no-ones got any suggestions about how to raise this figure then when the 3 month trial lapses I will avoid installing proxmox on any other machines unless I can afford the extra £30+ per month for hardware RAID.

EG AMD with hardware-raid:

:~# pveperf /var/lib/vz
CPU BOGOMIPS:      27602.43
REGEX/SECOND:      738908
HD SIZE:           496.06 GB (/dev/mapper/pve-data)
BUFFERED READS:    82.36 MB/sec
AVERAGE SEEK TIME: 11.91 ms
FSYNCS/SECOND:     21.82
DNS EXT:           150.19 ms
DNS INT:           18.76 ms (ovh.net)

So there is something terribly wrong or test is not working in this machine.
I have been playing around with it, and it does not seem to be that slow.
I send ticket for this, firs answer was "No problem has been detected.", but i will keep writing.

In unixbench i got far superior results to yours, were probably using different version.

[Kerridge0]

Yes, I did check that thread after my initial post. There are some others too. Quite useful information. It still confirms that I have an issue. The fsync/sec for software raid1 in that example is 5 times higher, so again, no good.

All I can say is, if no-ones got any suggestions about how to raise this figure then when the 3 month trial lapses I will avoid installing proxmox on any other machines unless I can afford the extra £30+ per month for hardware RAID.

From what I can gather a measurement of the order of 80-120 Fsync's a sec will result in lamentable performance with a few VMs. At least it's great that the q-1t is such a good performer, I will have to just plan to order those instead.

thanks

Kerry

[Myatu]

IanK gave a good answer to a related question about this earlier this year: http://forum.ovh.co.uk/showthread.php?t=3423

Take note of the differences in buffered reads/fsync on the sw/hw raid versions as well, which you'll find to be similar to yours.

[Kerridge0]

Hi, and firstly thank you for your reply.

Don't take these numbers at face value

Well this is it, I'm not taking them at face value, I am taking them as indicative, and I am struggling to understand why some of those figures for the new system would be consistently 1/4 to 1/10th of the figures of the older system.

you can see that the buffered reads and bogomips stack up correctly comparing new to old. Whereas some of the other tests are in fact not much better, or significantly worse.

it's the FSYNCS/Second that really bothers me when a cheaper, slower system is getting around 1000 I would be hoping for at least 500 here- could something be wrong/is there anything that can be done?

Kerry

[Myatu]

perhaps the controller hardware is much worse in the AMD system?

could it be that sw raid 1 could be causing the problem?

pveperf does a "quick and dirty" test, mainly to see where there are obvious bottlenecks. Don't take these numbers at face value... Unixbench does a somewhat better job (depending on which version you use), but does not account for random seeks/reads/writes, which is where performance really matters on any system.

Sw raid obviously does take a bit of toll compared to hw raid (it's "emulated"), but the performance differences shouldn't be the other way around - if it is, I would investigate that.

why are the dns figures so bad comparatively speaking?

Don't use OVH DNS servers directly. Either use a local resolver (listening on 127.0.0.1) or use a public DNS such as Google or OpenDNS. Reason being that the OVH DNS servers are underperforming.

[Kerridge0]

Hi

I signed up for the eg amd trial and got activated yesterday. So I got some performance figures from it out of the box. The strange thing is that the performance is barely better than the kimsufi Q-1T.

It looks like it's the performance of the disk IO that is the problem:

pveperf:
eg amd:

CPU BOGOMIPS:      27601.28
REGEX/SECOND:      734583
HD SIZE:           9.92 GB (/dev/md1)
BUFFERED READS:    123.06 MB/sec
AVERAGE SEEK TIME: 7.70 ms
FSYNCS/SECOND:     85.29
DNS EXT:           60.34 ms
DNS INT:           19.01 ms (ovh.net)

ks q-1t:

CPU BOGOMIPS:      19205.72
REGEX/SECOND:      773222
HD SIZE:           4.92 GB (/dev/sda1)
BUFFERED READS:    75.72 MB/sec
AVERAGE SEEK TIME: 9.50 ms
FSYNCS/SECOND:     398.68
DNS EXT:           22.87 ms
DNS INT:           1.62 ms (ovh.net)

unixbench (within identical openvz instance)
eg amd:

INDEX VALUES 
TEST                                        BASELINE     RESULT      INDEX 

Dhrystone 2 using register variables        376783.7 17524224.8      465.1
Double-Precision Whetstone                      83.1      997.1      120.0 
Execl Throughput                               188.3     9606.1      510.1 
File Copy 1024 bufsize 2000 maxblocks         2672.0   325929.0     1219.8 
File Copy 256 bufsize 500 maxblocks           1077.0   106708.0      990.8 
File Read 4096 bufsize 8000 maxblocks        15382.0  2567696.0     1669.3 
Pipe Throughput                             111814.6  5114949.2      457.4 
Pipe-based Context Switching                 15448.6   278353.5      180.2 
Process Creation                               569.3    19860.3      348.9 
Shell Scripts (8 concurrent)                    44.8     3253.9      726.3 
System Call Overhead                        114433.5  5414220.2      473.1 
                                                                ========= 
    FINAL SCORE                                                     506.9

q-1t

INDEX VALUES 
TEST                                        BASELINE     RESULT      INDEX 

Dhrystone 2 using register variables        376783.7 20804647.2      552.2
Double-Precision Whetstone                      83.1     1314.9      158.2 
Execl Throughput                               188.3     8468.1      449.7 
File Copy 1024 bufsize 2000 maxblocks         2672.0   196720.0      736.2 
File Copy 256 bufsize 500 maxblocks           1077.0    53858.0      500.1 
File Read 4096 bufsize 8000 maxblocks        15382.0  1446398.0      940.3 
Pipe Throughput                             111814.6  3482194.2      311.4 
Pipe-based Context Switching                 15448.6   930533.3      602.3 
Process Creation                               569.3    22457.1      394.5 
Shell Scripts (8 concurrent)                    44.8     2888.0      644.6 
System Call Overhead                        114433.5  2859701.9      249.9 
                                                                ========= 
    FINAL SCORE                                                     452.3

My questions are:

• perhaps the controller hardware is much worse in the AMD system?
• could it be that sw raid 1 could be causing the problem?
• why are the dns figures so bad comparatively speaking?
• could it be a driver issue due to new hardware?

EDIT: I should say that the FSYNCS on the Q-1T have been better than this generally, last night i was getting over 1000 and just now I got 898, this figure may have been due to system load at the time. OF course the EG AMD has no load at all, and on that system I haven't got more than 120