From owner-freebsd-fs Tue Aug 21 6:31:53 2001 Delivered-To: freebsd-fs@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 40F1637B403 for ; Tue, 21 Aug 2001 06:31:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.137.2.Dial1.SanJose1.Level3.net [209.245.137.2]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id GAA29609; Tue, 21 Aug 2001 06:31:46 -0700 (PDT) Message-ID: <3B8262E8.B6F13E03@mindspring.com> Date: Tue, 21 Aug 2001 06:32:24 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Behl Cc: freebsd-fs@freebsd.org Subject: Re: syncer delay? References: <3B8143F6.4030908@expertcity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jeff Behl wrote: > > howdy, > We have a very time sensitive application that we think is being > affected by the kernel syncer process. While doing a poll call, every > 30 seconds we will have iterations that take 300+ ms longer than on average. This > only started happening after our app started needing to log data to > disk, and the delays are longer when there are more connections (more to > write/log). > I turned on IDE write caching (hw.ata.wc) but this has had no noticeable > effect. What else can we do to try and minimize this hiccup every 30 > seconds? Is adjusting the time between sync's a worthwhile approach > (using sysctl)? We're using 4.3-RELEASE. You don't say how the logging is taking place Adjusting the time will generally not help you any. Probably you are seeing it stall because your writes are conflicting with other writes, or more likely, reads (e.g. as a result of paging in -- makes you want the sticky bit working like in "the good old days"). You can check this by mounting the disk async; if there is no improvement, then it's not just a metadata stall, and you're stuck. If that's the case, then you might want to try using a SCSI disk, instead, since it can have multiple outstanding commands, and will satisfy them asynchronously. Another alternative would be to log in a seperate process (e.g. use syslog for what it was designed to do), which is generally more efficient anyway (better concurrency). If the problem is just the fact that your latency isn't being spread out more equally, and you are doing the writes in your program, you have a few options: first, you can explicitly fsync() your log file, which will make the list of buffers needing to be sync'ed much shorter; second, you could log over the net to a different system, which is dedicated to doing logging, and nothing else. My personal bet is on it being a disk stall, since I've seen the same issue with local disk logging with ATA disks in a lab environment -- even IBM ATA disks, which claim to support tagged command queueing. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message