Re: quick interactivity? question regarding -current

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.                       \,,,,,,,,,,,,,,,,,,,,,,\