tuning(7) – FreeBSD performance tuning manual

There are many sysctl settings which can be usefull and are not in the man page.
E.g. zfs tuning,
vfs.zfs.txg.timeout=5 # sync zfs every 5 seconds
vfs.zfs.arc_min= 1500000000
vfs.zfs.arc_max= 2500000000

net tuning,
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.tcp.drop_synfin=1
 
Thanks,

Alain De Vos said:
… Which ones are a good idea to tune in which circumstances …
Click to expand...

This question applies much more broadly than networking.

For sysctl(8) variable descriptions: I feel that there should be a dedicated guide article (not as long as a chapter, or book), comparable to what's seen with sysctl -atd | sort, that disambiguates things in as few words as possible. An occasionally updated, concise article.

Then maybe an Appendix E to the FreeBSD Handbook, to offer more detailed guidance – where concise disambiguation alone is not enough for the reader to know, or guess, what value to choose for a variable with sysctl. (Things at and around 12.9 seem to be not particularly well-organised.) This guidance can refer to the article.

In any case: I'm wary of bloating the manual page for tuning.
 
kern.sched.preempt_thresh: Maximal (lowest) priority for preemption
I'm not a specialist in these things. But it think how higher you make this value how more "context switching" is done by the O.S. and such more time is wasted doing nothing usefull.
It was said it could make your desktop more resposive , i think handling of events and interrupts. I had it previously but i removed it as it was no longer advised.
From 12 to 13 the ULE scheduler improved alot.
 
From the 2017 topic begun by poorandunlucky:

Beastie said:
Preemptive scheduling is a type of process management algorithm. It simply means that the kernel allocates execution time to each process and interrupts the execution of the currently-running process when its time's up. How that is done depends on the kernel type and the specific algorithm chosen for its process manager.

This sysctl tunable is just a parameter that tweaks the behavior of the scheduler.
Click to expand...


Alain De Vos said:
?… I had it previously but i removed it as it was no longer advised.
Click to expand...

I wondered whether it was in a previous edition of the Handbook. Apparently not; a cgit search of doc, ports and src repos for kern.sched.preempt_thresh found only one commit (2007), relating to ULE:

<https://cgit.freebsd.org/src/commit/?id=02e2d6b44594cda2a1436e48662fbca23953eb7d>

From 12 to 13 the ULE scheduler improved alot.
Click to expand...

OK, I'll experiment without the 224 override (I've been using it for I don't know how long).

Can you recall where you advised to go without it?

<https://cgit.freebsd.org/src/log/?qt=grep&q=sched_ule>

sched_ule(4)
 
Alain De Vos said:
… From 12 to 13 the ULE scheduler …
Click to expand...

<https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000558.html> Stefan Esser (se@) wrote:

The "new" ULE scheduler has a number of well-known issues, which leads to the "old" BSD scheduler giving better performance on many systems and loads, but is based on concepts that made sense in pre-SMP times.

…

There have been minor changes to SCHED_ULE, recently, but I'd think that a completely new design will be required, based on knowledge gained in the last 1 or 2 decades and able to deal with architectural changes that have occurred in that time frame.
Click to expand...
 
You must log in or register to reply here.
Back
Top