From: William Lee Irwin III <wli@holomorphy.com>
To: Chris Wood <cwood@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
Date: Wed, 8 Jan 2003 18:57:36 -0800 [thread overview]
Message-ID: <20030109025736.GF23814@holomorphy.com> (raw)
In-Reply-To: <3E1A12B5.4020505@xmission.com>
[-- Attachment #1: brief message --]
[-- Type: text/plain, Size: 760 bytes --]
On Mon, Jan 06, 2003 at 04:35:17PM -0700, Chris Wood wrote:
> With some tips from James Cleverdon (IBM), I turned on some kernel
> debugging and got the following from readprofile when the server was
> having problems (truncated to the first 22 lines):
> 16480 total 0.0138
Here are some monitoring tools that might help detect the cause of
the situation.
bloatmon is the "back end"; there's no reason to run it directly.
bloatmeter shows the "least utilized" slabs.
bloatmost shows the largest slabs.
These sort of make for a top(1) for "lowmem pressure". Not everything
is accounted there, though. The missing pieces are largely
(1) simultaneous temporary poll table allocations
(2) pmd's
(3) kernel stacks
Bill
[-- Attachment #2: bloatmost --]
[-- Type: text/plain, Size: 110 bytes --]
#!/bin/sh
while true
do
bloatmon < /proc/slabinfo \
| sort -rn -k 3,3 \
| head -22
sleep 60
echo
done
[-- Attachment #3: bloatmeter --]
[-- Type: text/plain, Size: 133 bytes --]
#!/bin/sh
while : ; do
grep -v '^slabinfo' /proc/slabinfo \
| bloatmon \
| sort -n -k 4,4 \
| head -22
sleep 5
echo
done
[-- Attachment #4: bloatmon --]
[-- Type: text/plain, Size: 413 bytes --]
#!/usr/bin/awk -f
BEGIN {
printf "%18s %8s %8s %8s\n", "cache", "active", "alloc", "%util";
}
{
if ($3 != 0.0) {
pct = 100.0 * $2 / $3;
frac = (10000.0 * $2 / $3) % 100;
} else {
pct = 100.0;
frac = 0.0;
}
active = ($2 * $4)/1024;
alloc = ($3 * $4)/1024;
if ((alloc - active) < 1.0) {
pct = 100.0;
frac = 0.0;
}
printf "%18s: %8dKB %8dKB %3d.%-2d\n", $1, active, alloc, pct, frac;
}
next prev parent reply other threads:[~2003-01-09 2:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-06 23:35 2.4.20, .text.lock.swap cpu usage? (ibm x440) Chris Wood
2003-01-06 23:50 ` William Lee Irwin III
2003-01-06 23:52 ` Andrew Morton
2003-01-09 17:17 ` Chris Wood
2003-01-09 20:18 ` Andrew Morton
2003-01-10 0:25 ` William Lee Irwin III
2003-01-10 0:44 ` Brian Tinsley
2003-01-10 0:55 ` William Lee Irwin III
2003-01-10 20:42 ` Chris Wood
2003-01-09 2:20 ` James Cleverdon
2003-01-09 2:57 ` William Lee Irwin III [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-10 3:17 Brian Tinsley
2003-01-10 3:29 ` William Lee Irwin III
2003-01-10 3:42 ` Brian Tinsley
2003-01-10 3:54 ` William Lee Irwin III
2003-01-10 4:08 ` Brian Tinsley
2003-01-10 4:19 ` William Lee Irwin III
2003-01-10 4:50 ` Brian Tinsley
2003-01-10 5:17 ` Martin J. Bligh
2003-01-10 5:24 ` William Lee Irwin III
2003-01-10 5:45 ` Brian Tinsley
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=20030109025736.GF23814@holomorphy.com \
--to=wli@holomorphy.com \
--cc=cwood@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.