Subject: (usr-tc) big memory leak

From: Mike Andrews <[email-masked]>
Date: Sat, 10 Jun 2000 04:12:26 +0000

What's the best way to track down a really big memory leak?

"Big" = enough to crash a 64 meg ARC in 24 hours.

law-ts1> show mem util

SYSTEM MEMORY RESOURCES
Total System Memory Resources:             49509 KB
Code Size:                                 5833 KB
Initialized Data Size:                     1490 KB
Uninitialized Data Size:                   4356 KB
Stack Size:                                512 KB
Free Memory Current Value:                 13451 KB
Free Memory 1 Hour Before:                 14590 KB
Free Memory 12 Hours Before:               20724 KB
Free Memory 24 Hours Before:               19901 KB
Total Buffer Cache:                        40000
Free Buffer Cache:                         26690

Almost a meg an hour.  Ouch.

This just started happening about 28 hours ago, probably when I changed
something in the config... hell if I remember what it was though.  OSPF
maybe.  It's kinda like what happens to a NETserver when syslog is broken,
but I don't think syslog is the culprit here...

Is there some way I can get a list of running processes (like "list
processes" does) on the card and how big each one is?  I've got a list of
all commands in 5.0, including the "_" commands, but so far I haven't
found a winner.

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville
www.fark.com: If it's not news, it's Fark.  (Or something like that.)

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Mike Andrews <[email-masked]>
Date: Sat, 10 Jun 2000 08:38:19 +0000

Question still stands, but I think I found my leak.

Remember how we just discovered that new table that had, among other
things, idle time in it?  Well, the leak seems to come from walking that
table.  Sigh.

I went back through everything I touched on the chassis in the last day
and a half, and realized it was probably my newly-rewritten 'arcwho'
utility.

(I had thought OSPF because I had made a change yesterday... but only on
two chassis, and the leak showed up on *all* of them, including some I
hadn't touched in weeks.  So it's not OSPF.)

Here's the leak: if I snmpwalk the uumActiveSessionIfName tree,
.1.3.6.1.4.1.429.4.2.1.46.1.6 (interface names of current sessions), I
leak a few KB of free memory per walk.

If I walk .46.1.7 (ip addresses), .46.1.8 (start time), or .46.1.9 (idle
time), I do NOT leak memory.

It's a shame I didn't know about this table in the beta, 'cause I probably
would have found the leak then instead of on a Friday night.  Bummer.

I can't find a "disable snmp server/enable snmp server" type of command to
try to clear memory usage either.  More bummer.

If a fix is released, I won't be able to download it 'cause I don't have a
contract.  More more bummer.

-