From owner-freebsd-questions@FreeBSD.ORG Wed Jul 6 08:50:34 2011 Return-Path: Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95E0F1065672; Wed, 6 Jul 2011 08:50:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 558758FC15; Wed, 6 Jul 2011 08:50:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QeNoX-0000ve-5b>; Wed, 06 Jul 2011 10:50:33 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QeNoX-0001CJ-3Y>; Wed, 06 Jul 2011 10:50:33 +0200 Message-ID: <4E1421D9.7080808@zedat.fu-berlin.de> Date: Wed, 06 Jul 2011 10:50:33 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-questions@FreeBSD.ORG, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 08:50:34 -0000 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. The boxes in question are all 64Bit, do have 2 to 8 CPUs/cores (no SMT) and not less than 8 GB of RAM (the 8 core box is a dual socket Dell server with two 4-core C2D-type XEON CPUs and 16 GB of RAM). All these boxes uses ZFS filesystems for data along with UFS2 for the OS. On a notebook with a relative modern Core-5 dual core CPU and 4 GB RAM (running FreeBSD 9.0-CURRENT/amd64), not ZFS, all UFS, with a 500GB harddrive at 5400 upm (Dell Latitude E6510), this phenomenon is even worse. Heavy disk I/O blocks the GUI for nearly half a minute, even when no X11 is activated, the console gets stuck for a while. First I thought this could be a problem with the "slow" harddrive, but I tried also a Linux Ubuntu 11.04 on the box and forcing heavy I/O by copying the large files in question from one location on the disk to another is performed even faster and without any freezing of a console or GUI (used EXT4 filesystem). I'm curious about this behavior. I use FreeBSD as my favourite HPC platform as far as this is possible with FreeBSD, but I realized this bottleneck when it comes to heavy I/O and I'd like to know whether this is only a "superficial" phenomenon (like caused by the outdated X11 version FreeBSD use or a low priorized tty handling, means only the observer "realize" a performance drop). I've got not the time to investigate this deeper (I'd like to perform some benchmarks on the notebook if it is available again, but my knowledge on Linux/Ubuntu is very limited and the how-to setting up FreeBSD and Linux to match each other on the same hardware could be tricky). My kernel setups on FreeBSD are mostly the GENERIC kernel with extracted drivers I do not use (like some USB devices, SAS/SCSI adaptors etc. we do not use, et cetera), nothing special. Either way I follow the tips presented in "tuning(7)" or not, the phenomenon is present. Thanks, Oliver