-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unbound: num-threads max 2 #26086
Comments
Try the shell maths yourself: |
The problem is not doing the math. The problem is that UCI is accepting (translating) only:
If I want anything over Are you implying that |
Some of memory is allocated per-thread, some per-pool. |
The other options need to match up with number of threads. No more than two threads should share a "slab" of DNS cache. Adding slabs makes Unbound grow quickly. Some other tuning options also get entangled. UCI is about simplicity. If you want to use Unbound at this level, then it might be time to switch to manual mode and edit the Unbound configuration directly. |
Understood. The only option was to manually edit. But still. I understand its hard to calculate and waste time to make everything simple when simple isnt anywhere to start with... This limit(ation) is maybe too simple (my personal opinion). Its like either red pill or blue pill and nothing else for something that can get quite complex. Should I close this? |
I kind of dropped ref to official documentation mentioning options vs memories if anyone is goid at shell maths... |
packages/net/unbound/files/unbound.sh
Line 709 in 7ce67fb
Why does a system specify what would be the sane limit for the user?
option num-threads
is where we specify how much threads we as users want the system to use. As it is, the only possible outcomes (over-ruled by the system/UCI init.d script) are 1 (single core) and 2.A Redmi AX6000 has 4 cores and the init.d scripts over rules how much I can use.
2 was multi-core maybe 6 years ago, but not in 2025. In my opinion, even 6 years ago any over-ruled by the system limit was dumb.
The text was updated successfully, but these errors were encountered: