Date: Tue, 21 Aug 2001 06:32:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Behl <jeff@expertcity.com> Cc: freebsd-fs@freebsd.org Subject: Re: syncer delay? Message-ID: <3B8262E8.B6F13E03@mindspring.com> References: <3B8143F6.4030908@expertcity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B8262E8.B6F13E03>