From owner-freebsd-smp@FreeBSD.ORG Tue Apr 24 01:04:24 2007 Return-Path: X-Original-To: freebsd-smp@freebsd.org Delivered-To: freebsd-smp@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CE7016A400 for ; Tue, 24 Apr 2007 01:04:24 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from fep3.cogeco.net (smtp2.cogeco.ca [216.221.81.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6CC13C469 for ; Tue, 24 Apr 2007 01:04:24 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from elehost-can.cogeco.ca (d141-2-106.home.cgocable.net [24.141.2.106]) by fep3.cogeco.net (Postfix) with ESMTP id 9E9376A4; Mon, 23 Apr 2007 21:04:21 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Apr 2007 21:04:37 -0400 To: Kris Kennaway From: Paul In-Reply-To: <20070423155922.GA1156@xor.obsecurity.org> References: <00a601c78549$6b480fa0$b6db87d4@multiplay.co.uk> <20070423135619.D6FB4495@fep9.cogeco.net> <009c01c785b6$c8ac36e0$b6db87d4@multiplay.co.uk> <20070423145954.8244094A@fep1.cogeco.net> <00b301c785b9$0bc9b180$b6db87d4@multiplay.co.uk> <20070423152703.715922D1@fep2.cogeco.net> <20070423153334.GA530@xor.obsecurity.org> <20070423153808.831BF56B@fep3.cogeco.net> <20070423154745.GA872@xor.obsecurity.org> <20070423155500.413CB3A5@fep9.cogeco.net> <20070423155922.GA1156@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070424010422.9E9376A4@fep3.cogeco.net> Cc: freebsd-smp@freebsd.org Subject: Re: System Cpu Between 50-70% and need to find out why X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 01:04:24 -0000 > > options QUOTA > >This is going to make filesystem operations very slow. It is fixed in >7.0 and might be backported at some point. kib@ may be able to >provide a patch again 6.x that you could test. > >Kris Dear Gentlemen, I appreciate your suggestions today. Unfortunately I had to dump the 6.2 and scale back to the 4.12 for now and possibly for good as I could not find a solution. Just for point of reference here is a snapshot of the 4.12 box (see below). Notice the 98% idle. This is what I experienced in the old box. Most of the time it was idle in a range of 20-70% during busy times and 70-90% idle during non busy times. On the new box it was hardly ever idle. I still am not sure what was wrong but we had a difficult time simulating this as it was quite well tested. Today, when all I had was qpopper actively running on the new 6.2 "super" machine it was choking on the system being 50-70% used. The only reason I point this out is to comment and be complete on this thread on the belief that I would expect 100% usage on the new freebsd 6.2 amd64 with the double dual core xeon processors (technically 2* the cpus) and 4* the ram. This is in no way a complaint on the suggestions that were given. I have a hunch it was an issue with the speed it was able to write to the disk as qpopper moves the mail files from the /usr partition to the /var partition during transfer. This works just fine on the old machine but it was not working fine on the new machine. I am still unclear as to why this was not visible in the drive statistics (which seemed normal) and was visible in the CPU usage. Everything on the new 6.2 server seemed to take a lot more cpu percentages as a matter of visual inspection for the same versions of the 32bit i386 programs. In the old freebsd 4.12 server rarely would a process take >20% cpu. On the new 6.2 I commonly saw 20-50% for simple qpopper processes. I am going to try and reproduce the errors in a non-live environment to see if there is a fix for these problems. For people looking to roll out a 6.2 stable system on the Intel S5000PAL dual core Intel platform using SATA II on the amd64 branch be forewarned it may not be simple given my experience. Before the areca card arc-1130d, I tried an Intel raid card SRCS16 which in my opinion on Freebsd gave poor performance on disk transfers during tests for Raid 5. The areca card on the benchmarks and install seemed to be quite superior for every test. I even had a 1gig chip installed in the raid card to take advantage of the extra ram for caching. I made an effort on this system to get everything up-to-date for all firmware and to the best of my ability configured "right" over the last 3 months. It is unfortunate that it seems to be a shadow in comparison of the old slower 4.12 box. Clearly I must have had something wrong. If anyone has some tips on how to try and reproduce the errors I would greatly appreciate it. Regards and in appreciation for your efforts and suggestions thus far, Paul last pid: 40347; load averages: 0.44, 0.66, 0.59 up 0+05:30:50 20:37:27 127 processes: 2 running, 125 sleeping CPU states: 0.0% user, 0.0% nice, 0.9% system, 0.4% interrupt, 98.7% idle Mem: 1355M Active, 1937M Inact, 191M Wired, 180M Cache, 199M Buf, 235M Free Swap: 400M Total, 400M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 40276 spamfilter 2 0 144M 143M sbwait 0 0:02 2.64% 1.95% perl 39569 vscan 2 0 51940K 45896K accept 0 0:03 1.42% 1.42% perl5.8 1095 nobody 18 0 52340K 39128K lockf 0 0:21 0.98% 0.98% httpd 39643 vscan 2 0 50864K 44920K select 0 0:02 0.63% 0.63% perl5.8 19715 root 2 0 47852K 43548K select 0 1:19 0.59% 0.59% perl 39880 vscan 2 0 53516K 47412K accept 0 0:03 0.54% 0.54% perl5.8 39977 vscan 2 0 53600K 47512K accept 0 0:02 0.54% 0.54% perl5.8 489 root 2 0 14248K 12892K poll 0 28:52 0.39% 0.39% bbackup 40097 user1 2 0 2704K 2268K sbwait 0 0:01 0.05% 0.05% qpopper