Re: Awful FreeBSD 9 block IO performance in KVM
da0: 3.300MB/s transfers da0: Command Queueing enabled root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) 1) Does a larger block size (bs=1m) help? 2) That's roughly the speed I'd expect without queueing. Is it really making effective use of queueing, or is something limiting queueing to one transfer at a time? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
You are right. It is not capped at that speed: root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 262144+0 records in 262144+0 records out 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) you did test da1 while dmesg are about da0? is it OK and da1 is another qemu-kvm vdisk? If so, check dd if=/dev/zero of=/dev/da1 bs=512 count=256k and compare speed. i bet at something near 250kB/s and i think it is long I/O service pathlength in qemu-kvm SCSI device simulator. Just my bet i don't run FreeBSD on any VM (as opposed to running Windows under FreeBSD in VBox) check out how much CPU is used on the host side when you do that test. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
2) That's roughly the speed I'd expect without queueing. Is it really making effective use of queueing, or is something limiting queueing to one transfer at a time? still 400-500 IOPS is way too little. FreeBSD without VM machine can do well over 1 IOPS of 512 byte sequential read with single process on my laptop using less than 20% of single not blazing fast CPU. dd if=/dev/ada0 of=/dev/null bs=512 117593+0 records in 117593+0 records out 60207616 bytes transferred in 7.709451 secs (7809585 bytes/sec) CPU: Pentium(R) Dual-Core CPU T4500 @ 2.30GHz (2294.56-MHz K8-class CPU) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
trafficserver and raw disk access in FreeBSD
Apache Traffic Server may use raw disk for caching, and for privilege elevation, the worker process(traffic_server) will setuid to nobody, my question is, how to make traffic_server access the /dev/ada*? in linux, disk permitting is root:disk 0660, we can go with: 1, setup a new user 'ats', and put it into 'disk' group 2, after setuid, run initgroups() to complete the groups evn. we need a safe and easy to implement way for raw disk access in FreeBSD. thanks for you help -- zym, Zhao Yongming. aka: yonghao @ taobao.com signature.asc Description: This is a digitally signed message part
Re: trafficserver and raw disk access in FreeBSD
Apache Traffic Server may use raw disk for caching, and for privilege elevation, the worker process(traffic_server) will setuid to nobody, my question is, how to make traffic_server access the /dev/ada*? in linux, disk permitting is root:disk 0660, we can go with: 1, setup a new user 'ats', and put it into 'disk' group 2, after setuid, run initgroups() to complete the groups evn. devfs.conf ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
- Original Message - From: Dieter BSD dieter...@engineer.com To: hack...@freebsd.org, curr...@freebsd.org Sent: Sunday, July 22, 2012 1:19:32 AM Subject: Re: Awful FreeBSD 9 block IO performance in KVM da0: 3.300MB/s transfers da0: Command Queueing enabled root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) 1) Does a larger block size (bs=1m) help? 2) That's roughly the speed I'd expect without queueing. Is it really making effective use of queueing, or is something limiting queueing to one transfer at a time? The likely fix here is basically do vtblk_startio() in a separate kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, but I never found much of a difference in my testing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, definitely. it is done by the host. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: trafficserver and raw disk access in FreeBSD
yeah, rules in devfs always work. and it may introduce more challenge on operation management, is there any way that we can do it more clean? should we set the permission for :operator g+w on disks and partitions? then we can put a dedicate user for trafficserver into operator group. 在 2012-07-22日的 17:03 +0200，Wojciech Puchar写道： Apache Traffic Server may use raw disk for caching, and for privilege elevation, the worker process(traffic_server) will setuid to nobody, my question is, how to make traffic_server access the /dev/ada*? in linux, disk permitting is root:disk 0660, we can go with: 1, setup a new user 'ats', and put it into 'disk' group 2, after setuid, run initgroups() to complete the groups evn. devfs.conf -- zym, Zhao Yongming. aka: yonghao @ taobao.com signature.asc Description: This is a digitally signed message part
Re: trafficserver and raw disk access in FreeBSD
On 23/07/2012, at 11:17, ming@gmail.com wrote: yeah, rules in devfs always work. and it may introduce more challenge on operation management, is there any way that we can do it more clean? should we set the permission for :operator g+w on disks and partitions? then we can put a dedicate user for trafficserver into operator group. I would change the ownership of the disk you want to use to trafficserver. This does mean you have double configuration (ie in devfs and ATS) but I think it's more sensible than giving operator write perms. AFAIK operator has read access so it can run dump. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
