Heavy I/O blocks FreeBSD box for several seconds

Alexander Best arundel at freebsd.org
Wed Jul 6 13:33:37 UTC 2011

On Wed Jul  6 11, arrowdodger wrote:
> 2011/7/6 O. Hartmann <ohartman at zedat.fu-berlin.de>
> > When performing an update on the ports tree via "portsnap fetch update" or
> > when checking out (or) large Subversion repositories or when copying large
> > data files (~ 50 to 250 GB in size, results from numerical modelings) or
> > when compiling world, FreeBD 9.0 and FreeBSD 8.2-STABLE tend to "freeze" for
> > several seconds or drop overall performance dramatically for seconds. On
> > boxes with only console- or terminal access (no GUI) a running 'vi' gets
> > stuck for seconds while one of the processes producing heavy I/O is running,
> > or the output of a 'cat' of a large file stops for several seconds.

this might be a scheduling issue. iirc i/o intensive tasks have higher priority
than cpu intensive tasks, because they are expected to only issue a i/o request
and then free the processor, while cpu intensive tasks occupy the cpu a lot
longer. so maybe a process whith cyclic i/o requests blocks processes which
aren't doing i/o.

maybe playing with ULE's options can improve the situation. since you're
running GENERIC, preemption *should* be enabled. however you should double
check. i once tried running ULE without preemption and experienced exactly the
same situation you described in your mail. for ULE preemption is pretty much
mandatory. for the old 4bsd scheduler, running without preemtion doesn't really
make that much of a difference, compared to running with preemption.

you might also want to try enabling options IPI_PREEMPTION. no idea, if this
improves your situation, though.


> >
> > Using X11, this phenomenon gets even worse and the 'freezing' tends to
> > persist sometimes for more than 10 or 15 seconds.
> >
> I've also had (and still having) this problem on FreeBSD 7.2-RELEASE and
> 8-STABLE with both UFS and ZFS. Though, i've been running FreeBSD not on
> powerful servers, but on laptops (2-core CPU's, 2 GB of RAM). But still,
> KDE4 on Linux performs much better during high disk IO.

More information about the freebsd-questions mailing list