Date: Thu, 2 Oct 2014 15:25:02 -0700 From: Rumen Telbizov <telbizov@gmail.com> To: "Alexander V. Chernikov" <melifaro@ipfw.ru> Cc: brian@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>, "Alexander V. Chernikov" <melifaro@freebsd.org>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: 10.1-BETA2 possible kernel memory leak in routing table Message-ID: <CAENR%2B_XX=brNVRBOL-jeWPGSLpWZF9Gddso2FPJn5LKP3zG%2B%2Bg@mail.gmail.com> In-Reply-To: <CAENR%2B_Xv4iPAaOd3Vj%2BFQAZLu4%2BH3N1Rp6pd_b9UUSUu-a3j6A@mail.gmail.com> References: <CAENR%2B_UVLDDrsef2W4CXCFX65EYaxeKN4MNWbgoyaZ5qDGe1Pg@mail.gmail.com> <542AAA3C.1080803@ipfw.ru> <CAENR%2B_X5KTdeb00f9NShN1YK%2BT2aY1vG5YcTCgu4aXZO=%2Bpa=g@mail.gmail.com> <542AE376.6000003@FreeBSD.org> <CAENR%2B_XX4jnD6SBi8S1dGfWM68tmcm0aE2iMVA3LDR3R8ygQYw@mail.gmail.com> <542AFAE3.9030705@FreeBSD.org> <CAENR%2B_WbntqjE4b=iZS8z30AK7gSpur00HsWP9-T_UJ7OosU8Q@mail.gmail.com> <20141001135124.GM73266@glebius.int.ru> <542C20D7.3070606@sentex.net> <20141001171646.GQ73266@glebius.int.ru> <CAENR%2B_VwWor23sX4WAfzU18z8mdRxGverUsCKcjO=L3DVSuq6g@mail.gmail.com> <542C5529.9030800@FreeBSD.org> <7AB35136-89AA-48F2-8B0E-1BA3DCD4A6BA@ipfw.ru> <CAENR%2B_Xv4iPAaOd3Vj%2BFQAZLu4%2BH3N1Rp6pd_b9UUSUu-a3j6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello everyone,
Alexander, Gleb: good news guys. The problem seems to be resolved! Good
job.Here's what I have.
1. I upgraded the backup firewall to 10-STABLE (r272435), applied Gleb's
patch of pf_table.c and rebuilt. Just as reported by Gleb, the leak seemed
to be reduced but it was still present and leaked a little bit of memory
upon every PF reload.
2. In addition to 1) I applied the second patch from Alexander on radix.c
and rebuilt the kernel. After the reboot it seems like the amount of memory
consumed by the routetbl grows a little bit temporarily after reload and
then drops back to the previous, stable amount shortly after.
3. This is how I tested it with:
Just after boot I checked vmstat -m | grep routetbl
routetbl 606 170K - 4334 32,64,128,256,512,2048
Then I ran a tight loop of reloading the ruleset (and all tables) for a
while:
while true; do pfctl -f /etc/firewall/pf.conf; done
The memory output while the loop was still running looked something like
this:
...
routetbl 5166 2387K - 33177467 32,64,128,256,512,2048
routetbl 5358 2483K - 33190813 32,64,128,256,512,2048
routetbl 5598 2603K - 33202561 32,64,128,256,512,2048
routetbl 5870 2739K - 33214365 32,64,128,256,512,2048
routetbl 5634 2638K - 33226099 32,64,128,256,512,2048
routetbl 6286 2947K - 33239443 32,64,128,256,512,2048
routetbl 6510 3059K - 33251175 32,64,128,256,512,2048
routetbl 6750 3179K - 33262925 32,64,128,256,512,2048
routetbl 4622 2115K - 33274645 32,64,128,256,512,2048
routetbl 4910 2259K - 33286441 32,64,128,256,512,2048
routetbl 3582 1658K - 33298175 32,64,128,256,512,2048
routetbl 5326 2467K - 33311519 32,64,128,256,512,2048
...
after I stopped the reload loop and waited a minute the routetbl memory
pool went back to previous state
routetbl 606 170K - 35615574 32,64,128,256,512,2048
I assume this delay is normal and is simply the kernel freeing memory after
it gets "cold".
I will leave this machine running and reloading the ruleset every 30
seconds as intended in carp backup mode and will report any potential
problems back here. Aside from that I think we're all good. The problem
seems solved.
Gleb, Alexander, thank you very much for your help. I appreciate your quick
response in providing patches for this problem. I hope those 2 patches get
tested by more people and get MFC'ed into 10-STABLE soon.
Regards,
--
Rumen Telbizov
Unix Systems Administrator <http://telbizov.com>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAENR%2B_XX=brNVRBOL-jeWPGSLpWZF9Gddso2FPJn5LKP3zG%2B%2Bg>