Date: Mon, 7 Jun 2004 21:15:43 -0400 From: Brian Feldman <green@freebsd.org> To: Ali Niknam <ali@transip.nl> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: FreeBSD 5.2.1: Mutex/Spinlock starvation? Message-ID: <20040608011543.GC23083@green.homeunix.org> In-Reply-To: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> References: <Pine.NEB.3.96L.1040604153442.34555O-100000@fledge.watson.org> <00da01c44b3f$74d3d8c0$0400a8c0@redguy>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 05, 2004 at 10:55:31PM +0200, Ali Niknam wrote: > I tried this; this helps performance a lot, here are the findings: > - under all conditions turning on HTT helps a *lot* (which is logical i > think) > - under non killing load (killing load = load where server would have > crashed without this option) it performs much much better > - under killing load it performs a lot better, up until a certain level: > - a new killing level: from this point onward basically the same thing > happens as before.. Something is happening which should not be at a much more fundamental level. Something is going on to cause everything to block in Giant. That could be some exceptionally-long operation that executes, holding Giant, without andy context switches. In general, this is really what you would call a "deadlock," but at least you can recover from it. If the system is totally unresponsive to your input, is it still working from the standpoint of the users on it? Are there strange syslog messages? Can you watch the history of sysctl vm.vmtotal, sysctl vm.zone, and vmstat -m to see if it's a memory starvation issue? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040608011543.GC23083>