no priority on the console?
janm at transactionware.com
Mon Dec 1 14:41:34 PST 2008
> 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
> One of the things which made this nearly impossible to diagnose was
> the absolute lack of priority given to the console. Logging in on the
> 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
> This doesn't seem right to me. Can someone explain why the console
> isn't given a very high priority? Why not? What other mechanism does
> the sysadmin have for debugging, at a time when SSH logins either
> 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.
More information about the freebsd-stable