8-STABLE Slow Write Speeds on ESXI 4.0

[Joshua Boyd]

On Sat, Aug 7, 2010 at 1:58 PM, Ivan Voras <ivoras at freebsd.org> wrote:

> On 7 August 2010 19:03, Joshua Boyd <boydjd at jbip.net> wrote:
> > On Sat, Aug 7, 2010 at 7:57 AM, Ivan Voras <ivoras at freebsd.org> wrote:
>
> >> It's unlikely they will help, but try:
> >>
> >> vfs.read_max=32
> >>
> >> for read speeds (but test using the UFS file system, not as a raw device
> >> like above), and:
> >>
> >> vfs.hirunningspace=8388608
> >> vfs.lorunningspace=4194304
> >>
> >> for writes. Again, it's unlikely but I'm interested in results you
> >> achieve.
> >>
> >
> > This is interesting. Write speeds went up to 40MBish. Still slow, but 4x
> > faster than before.
> > [root at git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=250
> > 250+0 records in
> > 250+0 records out
> > 262144000 bytes transferred in 6.185955 secs (42377288 bytes/sec)
> > [root at git ~]# dd if=/var/testfile of=/dev/null
> > 512000+0 records in
> > 512000+0 records out
> > 262144000 bytes transferred in 0.811397 secs (323077424 bytes/sec)
> > So read speeds are up to what they should be, but write speeds are still
> > significantly below what they should be.
>
> Well, you *could* double the size of "runningspace" tunables and try that
> :)
>
> Basically, in tuning these two settings we are cheating: increasing
> read-ahead (read_max) and write in-flight buffering (runningspace) in
> order to offload as much IO to the controller (in this case vmware) as
> soon as possible, so to reschedule horrible IO-caused context switches
> vmware has. It will help sequential performance, but nothing can help
> random IOs.
>

Hmm. So what you're saying is that FreeBSD doesn't properly support the ESXI
controller?

I'm going to try 7.3-RELEASE today, just to make sure that this isn't a
regression of some kind. It seems from reading other posts that this used to
work properly and satisfactorily.

-- 
Joshua Boyd
JBipNet

E-mail: boydjd at jbip.net

http://www.jbip.net