On 07/06/11 12:37, 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. >> >> 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. I read about issues with the old codebase of X11 in FreeBSD's ports used, which could be the cause of some performance problems, but I wouldn't expect those I/O-triggered blockings on boxes without any GUI. I saw Linux very often performing tremendously better when used as a workstation or desktop, but this is often gained on the costs of other subsystems. I followed a very hard-to-understand discussion about grouping threads related to ttys which seems to get higher priorized in Linux to make the GUI more fluent, but this is definitely on cost of other subsystems, which in consequence gets less priorized. But even without GUI, Linux seems to perform I/O much better on multicore-/multiprocessor boxes than FreeBSD *.X and 9.X). Today I looked at some benchmarks performed by Phoronix/openbenchmark.org (http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=9) and it seems that threaded I/O is an issue in FreeBSD (compared to Linux). I have no glue how to "tune" those bottlenecks away in FBSD. I use SCHED_ULE on all machines, since it is supposed to be performing better on multicore boxes, but there are lots of suggestions switching back to the old SCHED_4BSD scheduler. OliverReceived on Wed Jul 06 2011 - 13:29:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC