Hello,2.8 gigs for 8.4M prefixes seems inline with expectation. Assuming it was not reloading when you took this snapshot, 38M fragments means it does approx. 4 allocations per row -- which again, seems reasonable. You could argue we could optimize it a little to hold each row in one chunk of mem, which will cut down into those 38M fragments - perhaps down to 10-15M maybe?
Looking at fragments is not really helpful, as it's just metadata. Instead, I'd look at the diff "real_used_size" and "used_size". Here, it's saying 2G / 4.8G is effectively "wasted" using fragment metadata. So that's a 41% loss, mainly because each allocation is somewhat small, so it's comparable to the fragment metadata size itself.
TL;DR: unless we do some serious reworking to the drouting module (e.g. chunking multiple rows/prefixes to be allocated in one go, if that's even possible given the trie structure), that 41% mem wasted ratio will have to do.
Best regards, Liviu Chircu www.opensips-solutions.com |www.siphub.com On 30/01/2026 14:14, [email protected] wrote:
"shmem:used_size": 2771791520, "shmem:real_used_size": 4885528760, "shmem:fragments": 37744704,
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
