[j-nsp] (M7i RE5.0) memory usage
Richard A Steenbergen
ras at e-gerbil.net
Sun Mar 28 17:39:32 EDT 2010
On Sun, Mar 28, 2010 at 11:14:51AM +0200, Alfred Schweder wrote:
> So I see in "task memory" was is going on inside the rpd and with
> "sysem proc sum" I see the system over all ?
Correct.
> Im wondering, where I waste memory, cause there are many posts which
> state that 512MB would be fine for 4 full tables. Ive only three and
> the 768MB are full.
There is a big difference between paths and routes. When people say "4
full tables", they usually mean 4 full table FEEDS going into a single
table. This results in 310k routes, and 310k * 4 paths, which consumes a
lot less memory than if there were really 1240k routes. Based on the
results below it looks like yo may have some independent routing
configurations going on (4 seperate rpd processes at any rate), which is
going to incur a lot of extra overhead.
But if you strictly look at what memory is absolutely needed to
function, you're doing pretty well (especially if that is 4 full feeds
in that main rpd process). The amount of memory in "wired" (basically,
being used by the kernel or mlocked) is a little excessive, that's
probably attributable to feature bloat on modern code more than anything
else. You might be a lot better off running some older code if you're
going to keep trying to run the old RE too. :)
> Are there are some knobs to reduce the memory consumption like not to use
> "softreconfiguration" at cisco boxes ?
Yes, you can configure "keep none" under protocols bgp (or group or
neighbor levels) to do sortof the same thing. It doesn't completely
eliminate the adj rib in (which is a good thing), it just doesn't retain
a copy of any route you explicitly reject in your policies. I don't
think this is going to be a huge savings for you unless you are
receiving and rejecting a lot of routes, and FYI it will flap your bgp
sessions when you configure it.
> last pid: 37745; load averages: 0.01, 0.06, 0.07
> 68 processes: 1 running, 67 sleeping
> CPU states: 16.3% user, 2.4% nice, 6.0% system, 0.8% interrupt, 74.5% idle
> Mem: 509M Active, 56M Inact, 148M Wired, 24M Cache, 69M Buf, 4412K Free
> Swap: 1536M Total, 118M Used, 1418M Free, 7% Inuse
>
> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
> 1219 root 1 4 0 408M 389M kqread 653:16 1.56% rpd
> 1222 root 1 111 15 43100K 40116K select 12:52 0.59% sampled
If you aren't using netflow, you can disable your sampled process which
is sucking down a decent amount of ram. The problem is that the routing
table data is copied from rpd to sampled just so you can populate the
"asn" field of netflow, and there is no way to disable this behavior if
you don't care about that field. Unfortunately the only solution is to
kill sampled completely, if you aren't using netflow of course.
I'm not sure if it will automatically disable things if you don't have
sampling configured, but you can forcably disable things by configuring
"system processes sampling disable".
> 5188 root 1 96 0 34420K 13016K select 1:40 0.00% mgd
> 5187 alf 1 8 0 15264K 9760K wait 5:00 0.00% cli
> 13189 root 1 4 0 29680K 8980K kqread 10:45 0.00% rpd
> 16931 root 1 4 0 29680K 8964K kqread 6:56 0.00% rpd
> 1212 root 1 4 0 29444K 7848K kqread 10:29 0.00% rpd
> 1235 root 1 96 0 22408K 7056K select 104:56 0.29% snmpd
> 1234 root 1 96 0 14836K 6352K select 33:56 0.00% mib2d
> 1174 root 1 96 0 43204K 6300K select 39.2H 1.17% chassisd
> 6007 bg 1 96 0 15188K 4800K select 0:52 0.00% cli
> 1821 alf 1 96 0 15200K 4684K select 0:52 0.00% cli
> 1342 alf 1 96 0 15188K 4584K select 0:55 0.00% cli
4.5MB+ for each of those cli processes is probably going to add up too,
but realistically there are a lot of pages you just don't need in real
time, and the vm system is doing the right thing by swapping them out.
You can probably run "just fine" with a decent amount of memory used in
swap.
--
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
More information about the juniper-nsp
mailing list