On Sat, Jul 16, 2016 at 6:37 AM, Mike Belopuhov <[email protected]> wrote: > On 14 July 2016 at 14:54, Maxim Khitrov <[email protected]> wrote: >> On Wed, Jul 13, 2016 at 11:47 PM, Tinker <[email protected]> wrote: >>> On 2016-07-14 07:27, Maxim Khitrov wrote: >>> [...] >>>> >>>> No, the tests are run sequentially. Write performance is measured >>>> first (20 MB/s), then rewrite (12 MB/s), then read (37 MB/s), then >>>> seeks (95 IOPS). >>> >>> >>> Okay, you are on a totally weird platform. Or, on an OK platform with a >>> totally weird configuration. >>> >>> Or on an OK platform and configuration with a totally weird underlying >>> storage device. >>> >>> Are you on a magnet disk, are you using a virtual block device or virtual >>> SATA connection, or some legacy interface like IDE? >>> >>> I get some feeling that your hardware + platform + configuration crappiness >>> factor is fairly much through the ceiling. >> >> Dell R720 and R620 servers, 10 gigabit Ethernet SAN, Dell MD3660i >> storage array, 1.2 TB 10K RPM SAS disks in RAID6. I don't think there >> is anything crappy or weird about the configuration. Test results for >> CentOS on the same system: 170 MB/s write, 112 MB/s rewrite, 341 MB/s >> read, 746 IOPS. >> >> I'm assuming that there are others running OpenBSD on Xen, so I was >> hoping that someone else could share either bonnie++ or even just dd >> performance numbers. That would help us figure out if there really is >> an anomaly in our setup. >> > > Hi, > > Since you have already discovered that we don't provide a driver > for the paravirtualized disk interface (blkfront), I'd say that most likely > your setup is just fine, but emulated pciide performance is subpar. > > I plan to implement it, but right now the focus is on making networking > and specifically interrupt delivery reliable and efficient. > > Regards, > Mike
Hi Mike, Revisiting this issue with OpenBSD 6.1-RELEASE and the new xbf driver on XenServer 7.0. The write performance is much better at 74 MB/s (still slower than other OSs, but good enough). IOPS also improved from 95 to 167. However, the read performance actually got worse and is now at 16 MB/s. Here are the full bonnie++ results: Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP web4.dhcp.bhsai. 8G 76191 43 10052 17 16044 25 167.3 43 Latency 168ms 118ms 416ms 488ms Here are two dd runs for writing and reading: $ dd if=/dev/zero of=test bs=1M count=2048 2147483648 bytes transferred in 25.944 secs (82771861 bytes/sec) $ dd if=test of=/dev/null bs=1M 2147483648 bytes transferred in 123.505 secs (17387767 bytes/sec) Here's the dmesg output: pvbus0 at mainbus0: Xen 4.6 xen0 at pvbus0: features 0x2705, 32 grant table frames, event channel 3 xbf0 at xen0 backend 0 channel 8: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: <Xen, phy xvda 768, 0000> SCSI3 0/direct fixed sd0: 73728MB, 512 bytes/sector, 150994944 sectors xbf1 at xen0 backend 0 channel 9: cdrom xbf1: timed out waiting for backend to connect Any ideas on why the read performance is so poor? Thanks, Max
