pi-hole GUI is perfect with great statistics.
but, love to use it with unbound or pdns-recursor for heavy duty use.
when there is more than 18K user devices using for a week, the pihole-ftl start occupying 99~104 % of CPU high load usage for resizing its DB, and not reach to successful service reply.
if this is totally due to dnsmasq, why cant' we let run unbound or recursor at port :53 and let pihole keep processing unbound/recursor logs for its perfect reporting?
it is ok that we can add/block all ads and naughty zones in unbound or recursor exactly like dnsmasq + pihole does.
but, need to process that FTL will process those logs and keep showing its lovely pretty UI.
any clue to let any future versions comes with unbound or recursor instead of dnamasq?
PS: sorry, as my English is too poor and quite odd request.
Most likely the issue isn't FTL/dnsmasq, it's the web interface.
Trying to push 18k clients through the DNS is easy and doesn't really put much load. Assuming you aren't trying to run your business on a Rasbperry Pi Zero.
Trying to use the web interface to monitor client behavior or see graphs will not work at that scale. I think you'll find that if you run htop or top or another system monitoring tool then you will see what is generating that huge CPU load. It's going to be lighttpd or php or fast-cgi.
The plan is to remove lighttpd and use a much better webserver daemon that will not crumble under high client loads. There will never be a change that removes FTL/dnsmasq.
with over 22K users with around 900qps make the FTL really slow and occupy the CPU resources and no DNS respond is resolved, with above logs, the FTL optimization never finish. repeating those messages and system crush, DNS cant be started,. i am sure.., nobody is using or launching the UI nor doing log analysis that time.
thanks help checking ,
or how do we make performance of dnsmasq better
or FTL wont get lost with these processes? Thanks.
There is nothing odd about this. FTL merely logs that it needs more memory for storing the query data but doing this is very quick. The only reason we log this so verbosely is that it will give you a hint why FTL crashed when it reaches the end of the available memory (the end does not necessarily have to coincide with the actual memory size, some systems put more restrict limits). We can likely silence this warning.
The fact that the allocation is happening is so small steps is that we want to use the memory as efficient as possible. Allocating too much memory ahead can cause issues in low-memory devices (thinking about docker, embedded devices, etc.). That's why allocation isn't proportional to anything but always progressing is small steps.
When does this happen? Does it also happen when you don't have any web interface open? The issue with slow browsers, slow PHP drills down directly into FTL which can send the data only synchronously to PHP at this time. This will be changed with Pi-hole v6.0 which is under active development as we speak.
It would be handy if you could monitor pihole-FTL in tree-view (F5) with custom-thread-names (F2 -> display options -> Show custom thread names) enabled in htop.