Kernel tuning in FreeBSD

Hi Team

I am doing kernel tuning in FreeBSD, I need your support on leveraging kernel tuning parameters from NetBSD. Below are the parameters from NetBSD we already have in our environment.

< maxusers 256 # estimated number of users
---
> maxusers 64 # estimated number of users
56c56
< #options INSECURE # disable kernel security levels - X needs this
---
> options INSECURE # disable kernel security levels - X needs this
108,113d107
< options KMEMSTATS
< options MAXUPRC=4800
< options SHMMAXPGS=2097152
< options SEMMNI=256
< options SEMMNS=2048
< options SEMMAP=4096
227c221
< options GATEWAY # packet forwarding
---
> #options GATEWAY # packet forwarding
268d261
< pseudo-device ipfilter # IP filter (firewall) and NAT

I want to leverage similar parameters in FreeBSD. So Far I created cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/VAULTS.
I am trying to find similar type of parameters in FreeBSD. If anyone can help and guide me for this would be highly appreciated.

If I run with the above options in FreeBSD, it says unknown option "INSECURE" May be FreeBSD different options similar to this.

Help will be highly appreciated.
1728319964884.png


Thanks,
Fateh
 
I need your support on leveraging kernel tuning parameters from NetBSD.
I hope you realize the FreeBSD and NetBSD kernels have diverged quite a lot over the years? Why are you trying to apply the same "tuning"?

maxusers can be dynamically changed, no need for compile-time kernel settings. It's set at a specific number based on the amount of memory the machine has.
Code:
root@chibacity:~ # sysctl -d kern.maxusers
kern.maxusers: Hint for kernel tuning

INSECURE is not an option you can set, just don't set a securelevel(7).
Code:
kern_securelevel="-1"   # range: -1..3 ; `-1' is the most insecure
                        # Note that setting securelevel to 0 will result
                        # in the system booting with securelevel set to 1, as

The various shared memory options are all dynamically changeable. They're not compile-time kernel options.
Code:
kern.ipc.shmall: 131072
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 536870912

GATEWAY doesn't need to be compiled in. Just add gateway_enable="YES" to rc.conf to turn it on. For IPv6 it's ipv6_gateway_enable="YES"

PF can be loaded as a module, pf(4), no need to bake it in. It will be loaded automatically when you enable the firewall in rc.conf; pf_enable="YES".

I want to leverage similar parameters in FreeBSD.
Don't "tune" for the sake of tuning. Tune because you need to tweak some settings. FreeBSD does an excellent job tuning itself for most situations. I suggest you simply start with the GENERIC kernel and see what that gets you.
 
I hope you realize the FreeBSD and NetBSD kernels have diverged quite a lot over the years? Why are you trying to apply the same "tuning"?

maxusers can be dynamically changed, no need for compile-time kernel settings. It's set at a specific number based on the amount of memory the machine has.
Code:
root@chibacity:~ # sysctl -d kern.maxusers
kern.maxusers: Hint for kernel tuning

INSECURE is not an option you can set, just don't set a securelevel(7).
Code:
kern_securelevel="-1"   # range: -1..3 ; `-1' is the most insecure
                        # Note that setting securelevel to 0 will result
                        # in the system booting with securelevel set to 1, as

The various shared memory options are all dynamically changeable. They're not compile-time kernel options.
Code:
kern.ipc.shmall: 131072
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 536870912

GATEWAY doesn't need to be compiled in. Just add gateway_enable="YES" to rc.conf to turn it on. For IPv6 it's ipv6_gateway_enable="YES"

PF can be loaded as a module, pf(4), no need to bake it in. It will be loaded automatically when you enable the firewall in rc.conf; pf_enable="YES".


Don't "tune" for the sake of tuning. Tune because you need to tweak some settings. FreeBSD does an excellent job tuning itself for most situations. I suggest you simply start with the GENERIC kernel and see what that gets you.
Thanks for your overall evaluation on, now it make sense what we can do and what we can't.

We can apply these changes dynamically through command line or we can specify this sysctl.conf and reboot?
 
Back
Top