quick interactivity? question regarding -current
Brian Fundakowski Feldman
green at freebsd.org
Sat Jul 10 12:28:48 PDT 2004
On Sat, Jul 10, 2004 at 05:48:35PM +0100, Markie wrote:
> ----- Original Message -----
> From: "Brian Fundakowski Feldman" <green at freebsd.org>
> To: "Markie" <mark.cullen at dsl.pipex.com>
> Cc: <freebsd-current at freebsd.org>
> Sent: Saturday, July 10, 2004 3:36 PM
> Subject: Re: quick interactivity? question regarding -current
>
>
> | On Sat, Jul 10, 2004 at 01:44:51AM +0100, Markie wrote:
> | > Hello,
> | >
> | > I updated my 'do-it-all' home server box from 5.2.1-R to -CURRENT the
> other
> | > day, as suggested by someone a month ago because I was having panics
> along
> | > the lines of "kmem_malloc(4096): kmem_map too small". Now, I can't
> | > immediately tell if this upgrade has solved my problem as the first one
> | > appeared after 50 days of uptime (ish) and the one that happened the
> other
> | > day (same panic) occured after only around 20 days, this is when I
> decided
> | > to go for the installkernel/world.
> |
> | Did you try seeing where all the memory went? I reimplemented KVM
> support
> | in vmstat -m for -CURRENT, so it should be more useful for that if you
> get
> | a core dump (admittedly, a rare thing ...).
>
> I didn't know about vmstat -m until the other day, I read something about
> `vmstat -m | grep cred` should be really low, under 100k or something
> (which mine is)
>
> I have no idea what KVM is in terms of kernel stuff :-) What should I be
> looking for, just any entry with a high mem usage? Should I setup a cron
> job to dump the results to a file each day so incase I do still get the
> panic i'll be able to look at the results atleast from the day before,
> maybe that would help me determine what was up if it's due to a memory
> leak? At the moment the most memory seems to be in 'routetbl' - 6456k in
> the HighUse and 1793k MemUse. All the rest are pretty much below 100k.
That's an excellent plan. I would suggest doing it more like hourly, and
logging to separate files each time -- the individual file unit is not the
most resilient to a kernel panic, but a directory of separate files will
probably stand no chance of being wiped out. If you used one file, it
could be truncated, put in lost+found, or maybe just lost, although I
haven't specifically had any files that were not "recently created" lost
during crashes.
If you're doing it live, please do vmstat -z also (vmstat -mz works); it
should be easy to see where the problem is using both of those over time,
but only if it's a gradual leak (which most I've seen are).
Thanks!
--
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-current
mailing list