5.2-rel NFS lockup and networking performance
rwatson at freebsd.org
Mon Jan 26 10:10:19 PST 2004
On Mon, 26 Jan 2004, Harald Schmalzbauer wrote:
> On Monday 26 January 2004 17:46, you wrote:
> > On Mon, 26 Jan 2004, Harald Schmalzbauer wrote:
> > > Thank you. I have set it up but I only get the following lines when
> > > sending a "~#" via tip:
> > > ~#
> > > The following connections are open:
> > > #0 client-session (t4 r0 i0/0 o0/0 fd 4/5)
> > >
> > > A bit googling showed something like "options COMCONSOLE".
> > > Do I need this? Th message was back from 1996 so I'm not sure what to do.
> > Sorry, make sure you have:
> > console="comconsole"
> > in /boot/loader.conf. Nothing further should be required.
> Did that. I also edited ttys so I can login via serial. No luck so far.
> Still the same result when sending the "~#". But since I now have a
> real console, I found that not the whole machine is locked up, it seems
> just networking is frozen for some time. I still have a very
> interactive console while networking on the same box is completely dead.
> Regrettably sysstat doesn't work vi tip so I can't tell you if there
> were any interrupts on the network interface during the lock.
> If you're still interested in some traces please give me a hint how I
> can use the serial debuger (I also had a quick look into the developer
> handbook, but ddb via serial isn't mentioned)
On the console, since it sounds like that's still running, it would be
very interesting to see the output of:
And see what's going on with interrupts. Also, when it's "hung", could
you do a stack trace of any nfsd processes lying around? It's as though
we're hitting some edge case that causes the server to spin quite hard
doing some sort of work, it's just not clear what it is. Speaking of
spinning, general vmstat -w 1 would be interesting during the hang also to
see what's going on with CPU.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org Senior Research Scientist, McAfee Research
> > > Breaking to debugger is working on the console. (Which crashes my /home
> > > each time) Is there a possibility to shutdown the machine "clean" after
> > > the ddb? Like I mentioned before, this is my production Fileserver :(
> > Normally, assuming your machine isn't already hung, you can type in "cont"
> > to continue, which should allow the system to continue normally. If the
> > system was hung/generally broken when you entered DDB, you can try "call
> > boot(0)" to see if you can get it to cleanly sync to disk, but whether
> > that succeeds depends a lot on how hung/broken the kernel was already.
> > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> > robert at fledge.watson.org Senior Research Scientist, McAfee Research
More information about the freebsd-current