Date: Thu, 31 Jan 2008 22:54:30 -0600 From: Eric Anderson <anderson@freebsd.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-performance@freebsd.org, Steven Hartland <killing@multiplay.co.uk> Subject: Re: newfs locks entire machine for 20seconds Message-ID: <47A2A606.9080702@freebsd.org> In-Reply-To: <200801310147.BAA04522@sopwith.solgatos.com> References: <200801310147.BAA04522@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dieter wrote: >>> What *exactly* do you mean by >>> >>>> machine still locks up with no activity for anywhere from 20 to 30 seconds. >>> Is there disk activity? (e.g. activity light(s) flashing if you have them) >> Cant tell if there is disk activity its in a DC miles away ;) >> >>> Does top continue to update the screen during the 20-30 seconds? >>> >>> I'm thinking that newfs has queued up a bunch of disk i/o, and other >>> disk i/o gets locked out, but activities that don't require any disk i/o >>> (like top, once it is up and running) could continue. Is that what is >>> happening? >> No all sessions totally freeze. I have top set to 1 second refreshes and >> the clock literally stops and then 20-30 seconds later continues. > > Wow! > >> All sessions are via ssh not X if that's of interest. >> >> I could understand if IO to disk for other processes became slow but >> everything including things like top just stop which is quite odd and >> concerning. > > Ok, new idea. Your disk activity is via the network, and your sessions > are via the network. Could it be that something network related is saturated? I saw this once before, a long time back, and every time I went through a debugging session, it came to some kind of lock on the sysctl tree with regards to the geom info (maybe the XML kind of tree dump or something). I don't recall all the details, but it was something like that. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A2A606.9080702>