Gentoo Archives: gentoo-user

From: "Hemmann
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Very bad system response
Date: Tue, 06 Feb 2007 22:36:46
Message-Id: 200702062326.18987.volker.armin.hemmann@tu-clausthal.de
1 On Dienstag, 6. Februar 2007, Pierre-Yves Rofes wrote:
2 > On Tue, February 6, 2007 9:29 pm, Michael Schreckenbauer wrote:
3 > > Hi List,
4 > > I have a very strange thing here. I don't know when this started, but my
5 > > feeling is, that it was around kernel 2.6.15 and it's getting worse with
6 > > each
7 > > version.
8 > > From time to time my system comes to a complete halt, that means not a
9 > > single
10 > > application shows any response to mouse and/or keyactions, sshing into it
11 > > takes forever. After a while (up to ~30s ) normal reaction is back again.
12 > > Strange thing is, there is no activity at the times this happens. Reading
13 > > email and browsing the web is all that is needed. CPU is at 3-5%
14 > > according to
15 > > top, mem has ~1GB free according to free.
16 > > I can somehow force this behaviour by doing some harddisc io, eg untaring
17 > > a
18 > > kernel-tarball. But it does not happen everytime I do this.
19 > > This is really, really annoying. I have no idea, if this is a kernel, a
20 > > FS or
21 > > any other issue. Any help with this is most welcome.
22 > > Some additional info: fs is xfs, kernel is 2.6.19-gentoo-r4 and I'm a
23 > > KDE-User, but this also happens with xfce4 ;)
24 >
25 > Maybe a faulty hard drive with bad sectors that can't be read. Anything in
26 > /var/log/messages or any other log file?
27 >
28 > --
29 > Pierre-Yves Rofes
30
31 I am not sure that something is 'broken'. His problem is like mine... heavy
32 disk i/o kills performance. And if the box hits swap, everything sucks....
33 because for some reason, always the wrong stuff is swapped out ;)
34
35 Really, sometimes, it is like every single bit is fetched individually from
36 the swap space...
37 --
38 gentoo-user@g.o mailing list

Replies

Subject Author
Re: [gentoo-user] Very bad system response Michael Schreckenbauer <grimlog@×××.de>