On Tue, 4 Feb 2020 at 17:29, Tim Woodall via GLLUG
wrote:
>
> Hi,
>
> Last night radvd got killed by the oom killer
> Feb 4 02:32:11 firewall17 vmunix: [1762825.239631] [ pid ] uid tgid
> total_vm rss pgtables_bytes swapents oom_score_adj name
> Feb 4 02:32:11 firewall17 vmunix: [1762825.239671] [ 3882] 105 3882
> 6849019387 58163248648 0 radvd
>
> When I look on another host I see that it's rather larger than I would
> have expected:
> 3247 radvd 20 0 177228 41016556 S 0.0 24.0 16:07.26 radvd
>
> After a bounce it looks better:
> 1030 radvd 20 02444 1616 1476 S 0.0 0.9 0:00.01 radvd
>
>
> I cannot find anything about radvd having memory leaks. Does anyone know
> if this large memory footprint is expected (I'm running it on a VM with
> not much memory and I can increase that if necessary)?
>
> I can obviously restart it to avoid this issue. I wonder if it could be
> related to VPN interfaces that are constantly being created and removed.
>
Well its open source, so in theory you could diagnose the leak yourself.
clang has a very useful "-fsanitize=address" option.
It allows the program to run pretty much at full speed, and then
reports memory leaks.
--
GLLUG mailing list
GLLUG@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/gllug
