8-STABLE Slow Write Speeds on ESXI 4.0
Ivan Voras
ivoras at freebsd.org
Sat Aug 7 18:23:36 UTC 2010
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.
More information about the freebsd-stable
mailing list