The stats at the end of 'bgpctl reload' are more interesting
if you want to size memory. Especially if you're running on
a secondary storage device you'd rather not swap to.
This is from a peering router (70 sessions, full table split across
a couple of it's neighbours plus about 3500 peer routes) - 1G ram,
amd64 (anyone else who experienced the pae pmap bug will understand;
I would probably choose i386 now...)
This is slightly old code as the box has been up for 6 months (yes,
bgpd is pretty reliable :)
slacking ->
load averages: 0.09, 0.11, 0.11 23:07:27
48 processes: 47 idle, 1 on processor
CPU states: 0.0% user, 0.0% nice, 1.0% system, 1.0% interrupt, 98.0% idle
Memory: Real: 249M/489M act/tot Free: 500M Swap: 0K/0K used/tot
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
15157 _bgpd 2 0 5844K 6740K sleep poll 786:34 0.20% bgpd: session engine
27390 _bgpd 2 0 92M 93M sleep poll 541:17 0.00% bgpd: route decision e
30126 root 2 0 17M 18M sleep poll 80:31 0.00% bgpd: parent
just finishing up a reload ->
load averages: 0.97, 0.40, 0.22 23:09:12
48 processes: 1 running, 46 idle, 1 on processor
CPU states: 95.8% user, 0.0% nice, 1.4% system, 2.8% interrupt, 0.0% idle
Memory: Real: 444M/684M act/tot Free: 305M Swap: 0K/0K used/tot
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
27390 _bgpd 56 0 286M 287M run - 542:56 98.39% bgpd: route decision e
30126 root 2 0 17M 18M sleep poll 80:31 0.05% bgpd: parent
15157 _bgpd 2 0 5840K 6736K sleep poll 786:34 0.00% bgpd: session engine
I wouldn't choose to run full tables with <1G.