From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
To: Leroy van Logchem <leroy.vanlogchem@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Kernel Netdev Mailing List <netdev@vger.kernel.org>,
ph0x <ph0x@freequest.net>
Subject: Re: PROBLEM: bug in e1000 module causes very high CPU load
Date: Mon, 9 Jan 2006 18:41:08 -0800 [thread overview]
Message-ID: <4807377b0601091841j76c6093an8117ad66cd32981@mail.gmail.com> (raw)
In-Reply-To: <b7561c4a0512231514y3bd6564jd13d16ea4476f07e@mail.gmail.com>
On 12/23/05, Leroy van Logchem <leroy.vanlogchem@gmail.com> wrote:
> <snip>
> > Yes, let the server act as usual, it just starts happening out of the blue.
> > No new hardware has been added or removed, no new programs has been
> > installed.
>
> "Me too"
<snip>
> Is there a method which can give hints about what was going on during
> the sharply rising load? My guess is that even monitoring/sampling
well, maybe top, maybe you could schedule sar to gather stats on your system.
> aint doable anymore if the bad situation occurs. Tips on obtaining
> information about subjects like:
> - who was using which tcp/udp connection with what bandwidth
i like a utility like iptraf to help with this.
> - who was generating how many read/writes on which filesystem incl. location
hm, thats a little tougher, nfsstat doesn't give that does it.
> - etc etc.
> are more then welcome too. Does using profile=2 and storing
> readprofile output to files every 5 seconds give enough information to
> tacle the source of this problem?
yes, i think that would certainly help figure out what happens at the TOD :-)
you could enable sysrq in order to get a stack after it hung. For
bonus points you can hook up a serial console and dump the state of
all processes with sysrq.
hopefully before it died you would be able to sync your drive and
reboot in order to maximize your chances of fully writing files.
Jesse
prev parent reply other threads:[~2006-01-10 2:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051210114100.QFYF676.mxfep01.bredband.com@ph0x>
2005-12-10 22:16 ` PROBLEM: bug in e1000 module causes very high CPU load Jesse Brandeburg
2005-12-11 19:41 ` ph0x
2005-12-23 23:14 ` Leroy van Logchem
2006-01-10 2:41 ` Jesse Brandeburg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4807377b0601091841j76c6093an8117ad66cd32981@mail.gmail.com \
--to=jesse.brandeburg@gmail.com \
--cc=leroy.vanlogchem@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ph0x@freequest.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox