I have some multithread apps on my server machine based on FreeBSD 7.2, so because of this I need to increase kern.threads.max_threads_per_proc to 4000 (default value is 1500). I changed it using "sysctl kern.threads.max_threads_per_proc=4096" and it looks like ok, but after reboot this option has default value again. I also tried to use /boot/loader.conf but it's still returning to default value.

This is what contains in loader.conf:


And even with this settings "sysctl kern.threads.max_threads_per_proc" shows defalut value (1500) after reboot.

Please, tell me how can I change this permanently?

  • kern.threads.max_threads_per_proc is read-write tunable so you should place it in /etc/sysctl.conf – SaveTheRbtz Feb 14 '14 at 3:33

There are two different methods to tune kernel parameters - loader tunables and sysctl.

  1. Loader tunables saved in the file /boot/loader.conf - they exported by loader to kernel environment and has effect at kernel boot time. After boot you can see this values via kenv command. This environment can be changed by kenv command, but this useful only for tanables readed by kernel modules. E. g. you can set kern.hwpmc.nbuffers=32 and than to kldunload/kldload hwpmc module. But in general you need to reboot after /boot/loader.conf change.

  2. sysctl varuables. Many sysctl values can be changes at runtime via sysctl command. To reapply sysctl changes after reboot the can be saved in the /etc/sysctl.conf file.

Many loader tunables (but not all) has corresponding read-only sysctls with same name. But in general there is no 1:1 mapping between loader tunables and sysctls. E. g. many sysctl has no loader tunable with same name, and can't be changed via loader.conf.

kern.threads.max_threads_per_proc is only sysctl and should be saved in /etc/sysctl.conf

Is your /boot/loader.conf honored? loader.conf(5) states that /boot/loader.rc needs to contain the following lines:

 include /boot/loader.4th

/boot/loader.4th in turn loads /boot/defaults/loader.conf which in turn might load /boot/loader.conf if something like this is included:

loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local"
  • I've just checked it, there are all like you said in loader.rc and loader_conf_files option. Obviously there is another reason, because another settings in loader.conf is ok, only thread limit is problem. Is it possible that threads limited anywhere else so it just rewrites value loaded from loader.conf? – Valeriy Maslov Feb 13 '14 at 6:39
  • That's certainly a possibility. Does 'grep -r` on /etc bring up anything useful? – ckujau Feb 13 '14 at 7:40
  • It shows only /etc/sysctl.conf. There is kern.threads.max_threads_per_proc=4096 in it. But looks like it doesn't change anything too. – Valeriy Maslov Feb 13 '14 at 8:36
up vote 0 down vote accepted

Well, first of all thank you for all your answers. They are all right of course, but the reason of my problem was a bit deeper, inside kernel source code :)

I try to eplain my solution step by step, what I found. So, like @citrin said kern.threads.max_threads_per_proc is needed to be set in sysctl.conf. But this doesn't help to change value more than 1500 (this is kernel max and defaul by the way). So, this is because there is another limit in system which overrides any of user defined values. I didn't know exactly where it is, so I tried to found something in kernel sources.

I found this value inside kernel sources: /usr/src/sys/kern/kern_thread.c. It contains code like this:

int max_threads_per_proc = 1500;
SYSCTL_INT(_kern_threads, OID_AUTO, max_threads_per_proc, CTLFLAG_RW,
&max_threads_per_proc, 0, "Limit on threads per proc");

I changed that value to 5000 and build new kernel with GENERIC configuration and installed it. There was a little surprise for me cause I had thread limit setted 4096 inside sysctl.conf, but the working value was 5000, like in sources. Although kernel values somehow overrides user defined, so, this still causes questions, but right now my problem is solved, thread limit was permanently increased.

Thanks for your answers again.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.