CIFS inducing absurdly high CPU load

whenever i am reading or writing to my CIFS folder, smbd uses 100% of my server’s CPU. and whatever task is doing the write on the client uses absurdly more CPU than it has any reason to.

running dd if=/dev/zero of=file.txt count=10 bs=1G from the client seems to be a good way to induce this. dd uses 12% CPU on the client and smbd uses 100% of the server during this operation.

my client is a 4-core VM running on the server. the server’s CPU is a ThreadRipper 1950x.
the CIFS share is a RAID 5 array using 4 of the HItachi/HGST H7280A520SUN8.0T HDD’s.
my RAID card is the Dell PERC H830

i understand that tasks using the array have to deal with i/o wait, but this CPU usage is affecting other tasks on the system that dont use the array at all.

Nature of the beast I believe. I notice very high CPU usage from SMBD when copying large amounts to or from my Fedora server

Usually it’s only a single thread that’s pegged, not really a big deal for my 2950x.

This sounds about right. I saw this when I had NTFS mounts in Linux. I could be incorrect, but from my brief research, it has to do with those processes (smbd) are running in user space. So you’re seeing the CPU usage for those processes as they are churning through the I/O, as opposed to writing directly to ext4 or something, those things happening in the kernel space.

is there anyway around this?
NFS isnt an option because i cant find a way to use it securely.

You can check the io wait percentage in top, cpu usage is probably looking worse than it really is.

In regards to the responsiveness of the system while this is happening - what io scheduler are you using?

1 Like

So, is the entire CPU pegged, or just one thread, or a few threads? Your 1950x should enjoy having something to do.

You could move smbd into a container like Docker, and use that to restrain resource usage.

Is encryption and/or signing enabled?

yes. thats why i chose CIFS, i could find a way to password protect NFS.

im using whatever scheduler is default on Debian 10 Buster.

Password ≠ encryption

if it helps you understand my situation better, here is my smbd configuration file. smb.conf.txt (8.8 KB)

This is probably the cause:

smb encrypt = required

So change required to off. Also add in

server signing = disabled

Don’t forget to run testparm

Is this gigabit or 10gb?

my network infrastructure is currently 1Gb/s Ethernet. however my server communicates to its VM’s with an international virtual bridge.

1 Like

Ok cool. Did turning off encryption help your cpu? At some point, Samba introduced aes-ni support but I am not sure if that completely offloads server encryption Or what. Possible that the Debian package predates the feature as well.

Note that authentication is still secure and encrypted, it’s just the file sharing data that is unencrypted. If this is a concern for you, isolating the traffic on your lan with a vlan/pvlan/firewall is the best security solution if you need performant file sharing. Encrypting on the fly is inherently computationally expensive.

disabling encryption seems to have addressed the issue.

2 Likes

NFSv4

with kerberos/keytabs

1 Like