That 30k addresses alone need roughly 30MB non-swappable memory, ~10% of
all of the physical RAM. Depending on what else's running on that machine,
the required memory can be significant.
The system, when it boots, has more than 150MiB of RAM available (that
excludes about 80MiB of "cached" memory), so RAM is clearly not an issue
I don't think. I forgot to mention that I executed the whole sequence
(which triggered the bug) as soon as I booted up, so no other
applications were loaded (yet).
I have never tested iptree(map) with so many elements, so it's surprising
for me that it takes so many time.
It is the single most frustrating issue I've always had with ipset - I
am more than pleased with everything else, apart from the initial
loading, which, as I already pointed out even on a fast machine with
lots of RAM (Core2 with 4GiB RAM) takes about 20 or so seconds for these
ipsets to load. That goes to about 5 minutes on less-powerful, but
equally well-equipped P4 (3.3MHz) with 1GiB RAM.
But if the 30k addresses are quite
different then the iptreemap has to build up a four-level tree with 30k
branches from the second level down.
So, do you have an idea what is causing this bug and how could it be
avoided/fixed?
I have tried the new version of ipset, but didn't have luck with it
either - see my other post on this list with regards to that particular
set of problems.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
