Hi Marek, On Mon, Jul 13, 2026 at 03:23:26PM +0200, Marek Zarychta via Bird-users wrote:
I was also skeptical about the memory usage of BIRD 3.x compared to BIRD 2.x. In my case, memory consumption roughly doubled. I raised this several times on this mailing list as well as in private messages, but the issue was either ignored or attributed to FreeBSD.
Regarding possible memory leaks, after about one month of uptime, BIRD 3.3.1 with four (2 x dual-stack) BGP full-view sessions and one OSPFv3 session currently shows:
[...]
Cold free pages: 1173.5 MB Hot page cache depleted while in RCU: 1266139
These two lines tell me that there have been over a million times where BIRD had to map a new memory page in situations where part of the allocator was unavailable due to deadlock prevention. That is way more than I expected when adding this check, and now I have an empirical reason to touch the allocator again.
Could someone explain what the continuously increasing "Cold free pages" value represents, and why there is such a large difference (around 710 MB after one month) in the memory reported by |show memory|and the |SIZE|/|RES|values reported by |top(1)|on FreeBSD as well?
There is a problem of address space fragmentation when we return memory pages randomly, leading to nasty errors. Instead of that, we decided to keep the pages and only mark them via madvise() as free so that kernel can actually unmap them whenever needed.
Is this expected behavior, or could it indicate that memory is being retained but not released back to the operating system?
All of that indicate that: - maybe at FreeBSD we don't use the right madvise() arguments, or the kernel behaves differently - we should look again into the hot page cache depletion problem, and implement some smarter scheduling and memory management algorithms, because this slow virtual memory creep will sooner or later become a problem even at linux machines where we are sure that the pages are freed correctly - there may be some other memory leak (e.g. that one we already know about in CLI) causing another part of the consumed memory growth Thank you for the heads-up. We'll look at it. -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.