Huge memory foot print in master branch

[dhammika]

ISSUE TYPE

• Bug Report

OS

Linux/Debian 8.9

VERSION

ExaBGP : 4.0.2-1c737d99
Python : 3.4.2 (default, Oct  8 2014, 10:45:20)  [GCC 4.9.1]

ENVIRONMENT

CONFIGURATION

neighbor 10.1.1.2 {
    description "10.1.1.2";
    router-id 10.1.1.1;
    local-address 10.1.1.1;
    peer-as 666;
    local-as 666;
    hold-time 720;
    group-updates;
    capability {
	    asn4 enable;
	    add-path disable;
	    route-refresh enable;
    }
    family {
	    ipv4 unicast;
    }
}

SUMMARY

Huge memory foot print in master branch.

STEPS TO REPRODUCE

Create a bgp peer and send route-refresh.

EXPECTED RESULTS

Memory foot print to be similar to 3.4 branch.

ACTUAL RESULTS

Comparable mem for IPv4 rib with 650k routes.

       | vsz     | rss
master | 1058968 | 1005480
3.4    | 50084   | 15268

Curiously most of it is marked as rss memory. We're possibly leaking memory or creating a giant list??
tracemalloc shows following as most prominent allocation points, but they don't look suspicious.

Top 10 lines
#1: nlri/inet.py:99: 48702.8 KiB
    nlri = cls(afi,safi,action)
#2: nlri/inet.py:147: 43548.5 KiB
    nlri.cidr = CIDR(network + padding(IP.length(afi)-size),mask)
#3: rib/change.py:37: 36244.5 KiB
    self.__index = '%02x%02x' % self.nlri.family() + self.nlri.index()
#4: ip/__init__.py:77: 31073.7 KiB
    return socket.inet_ntop(socket.AF_INET if len(data) == 4 else socket.AF_INET6,data)
#5: reactor/peer.py:404: 29971.8 KiB
    self.neighbor.rib.incoming.update_cache(Change(nlri,message.attributes))
#6: exabgp/logger.py:81: 29918.6 KiB
    self.afi = afi
#7: rib/cache.py:76: 24576.2 KiB
    self._seen.setdefault(family,{})[index] = change
#8: attribute/attributes.py:328: 22869.4 KiB
    aid = Attribute.CODE(ordinal(data[1]))
#9: attribute/attributes.py:210: 17952.6 KiB
    self[attribute.ID] = attribute
#10: nlri/cidr.py:27: 14985.6 KiB
    self._packed = packed

IMPORTANCE

This is absolute show stopper for us.

[thomas-mangin]

By default the neighbour now enable the adj-rib-in which was disabled on 3.4
Can you add adj-rib-in false; to the peer and see if it makes a difference.

These two options may also affect memory usage:

./sbin/exabgp --help | grep cache
 - exabgp.cache.attributes      : cache all attributes (configuration and wire) for faster parsing. default (true)
 - exabgp.cache.nexthops        : cache routes next-hops (deprecated: next-hops are always cached). default (true)

I would appreciate if we could communicate off GitHub to get this moving forward as I fear this is would help with incoming routes and not outgoing or the API.

[thomas-mangin]

ExaBGP 3.4 uses python2 but ExaBGP 4.0 uses python3 - could you please re-perform the test for 4.0 using python2 as the code still works with both version.

[dhammika]

Turned out it was adj-rib-in false; IMO we should document this, is certainly a trap.
BTW python2 and cache flags didn't make any noticeable changes to mem.
Feel free to close this ticket, Thanks!

[thomas-mangin]

Great news ! Keeping the ticket open as I believe a 3.4 to 4.0 wiki entry is required and this should be added to it.

[thomas-mangin]

wiki updated https://github.com/Exa-Networks/exabgp/wiki/Migration-from-3.4-to-4.0