FreeBSD 9.0 hangs on heavy I/O

[Kees Jan Koster]

Dear Freddie,

>> You may want to play around with gshed, the GEOM Scheduler.
>> 
>> Matt Dillon did a bunch of tests comparing FreeBSD+UFS to
>> DragonflyBSD+HAMMER and found that FreeBSD starves read threads in
>> order to satisfy write threads (or the other way around?).  But,
>> adding gsched into the mix helped things immensely, allowing mixed
>> reads/writes to better shares disk I/O resources.
>> 
>> I'll see if I can dig up a link to his testing e-mail messages.
> 
> Here's the post, part of a thread on benchmarking RAID controllers:
> 
> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00034.html


*cloink* /me goes to pick my jam off of the floor. I can insert a I/O scheduler in full flight? Ok. I need to adjust my mental image of the world a bit.

I just played with the examples on a test machine and the effect is quite visible. I ran a CVS checkout of the ports collection concurrent with dd writing a massive file. Insert scheduler -> CVS update is faster; destroy scheduler -> CVS update crawls. This is so easy it's almost scary.

The behaviour that Matt describes is what I thought I was seeing too: write a *lot* and it becomes hard to read from the disk. In my system, writing data is largely asynchronous and can lag the actual arrival of data by as much as a few minutes. Reads are always synchronous to a user request and need to be served asap. Some writes are database writes and they should be services quickly too.

This is definitively something I need to look into. Thank you for the reference.
--
Kees Jan

http://java-monitor.com/
kjkoster at kjkoster.org
+31651838192

Change is good. Granted, it is good in retrospect, but change is good.