Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Dec 2008 09:41:22 +1100
From:      "Jan Mikkelsen" <janm@transactionware.com>
To:        <jhrett@netconsonance.com>, "'FreeBSD Stable'" <freebsd-stable@freebsd.org>
Subject:   Re: no priority on the console?
Message-ID:  <1A7634CAC3E147CB8B5CDA853E4856D7@STUDYPC>

next in thread | raw e-mail | index | archive | help
Hi,

> As per my previous message, I've spent about 3 months trying to debug  =

> a problem that was causing all disk I/O to go very slowly.

A first glance this sounds similar to the problem I am having with very =
slow
I/O on the Areca controller.  (see: "7.1-PRERELEASE: arcmsr write
performance problem")  What controller are you using?  Is the write =
cache
enabled?

> One of the things which made this nearly impossible to diagnose was =20
> the absolute lack of priority given to the console.  Logging in on the =
=20
> console would take 12-15 minutes.  Hitting enter on the console would  =

> usually take between 3 and 5 minutes.

Yes, I see this when I get the slow I/O problem.  I think this has been =
a
problem for some time; I have also seen "console freezes" (ssh, console,
etc.) on 6.0 and 6.1 systems under SATA load.  That was a while ago now
(2006?).  I also recall others reporting have seen the same problem
intermittently.

> This doesn't seem right to me.  Can someone explain why the console =20
> isn't given a very high priority?  Why not?  What other mechanism does =
=20
> the sysadmin have for debugging, at a time when SSH logins either =20
> fail, or take up to an hour to complete?

In my case I could log into the system and start things like iostat and
gstat and they kept running while the problem occurred so that I could =
see
some of what was going on.  I could also have what seemed like a =
reasonable
ssh session with a jail on the same machine.  This indicates to me that =
it
is not the console that is the issue, but rather that the process of =
logging
into the main machine touches some file that causes it to get caught up =
in
the slow I/O quagmire.

If the problem I am seeing now is the same as the one I saw a few years =
ago
then I think the nature might have changed.  My recollection is that
utilities like iostat would also freeze back then, but I can't be sure.

I'd like to resolve this problem too.

Regards,

Jan.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A7634CAC3E147CB8B5CDA853E4856D7>