smbsrv workers run at excessively high priority
I noticed while working on other things that smbsrv starts its "worker" thread
(via a taskq) with priority 99. That's crazy. Should be closer to minclsyspri,
as NFS and most other things use.
This might (at least in part) explain why smbsrv does not "gracefully" degrade
it's performance under extremely heavy workloads. (Will re-test that.)
On a light-to-medium loaded system, it essentially doesn't matter. All the
threads in smbsrv spend most of their time blocked on something.
Updated by David Anderson almost 9 years ago
If I were to suspect that I am running in this issue is there any workarounds? I have a NFS/SMB server with ~1000 windows clients/260 linux (NFS) clients and I have a ton of write IO that I am expecting might be from windows clients, as it doesnt show up from NFS provider dtraces. Also NFS performance seems to become sluggish as load avgs climb > 1 to about 4 or so.
Is there anything that I could look at on this system which might help with this issue or in general with SMB load problems?
Updated by Gordon Ross almost 9 years ago
The failure mode I expect with the current priorities is a memory shortfall. The worker and receiver threads both run at priority 99. The worker threads will generally end up blocked in zfs waiting for I/O completion. The receiver threads will continue to read and buffer more requests until something causes that to throttle, i.e. memory shortfall.
Updated by Electric Monk over 5 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 08344b293eab865a57e4629b178f2003dced397e Author: Gordon Ross <email@example.com> Date: 2015-04-12T17:10:23.000Z 1517 smbsrv workers run at excessively high priority Reviewed by: Eric Schrock <firstname.lastname@example.org> Reviewed by: Dan McDonald <email@example.com> Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Approved by: Garrett D'Amore <email@example.com>