You are not logged in.
Hi,
some time ago (after a some recent update I, guess) I noticed that after mounting a ntfs share from a Windows 7 machine, cifsd process begins to take much CPU time: in the 'top' it steadily keeps consuming 15-17 % of CPU. Previously, such behavior of cifsd has not been observed.
The share is mounted like this:
mount.cifs //192.168.1.2/share /mnt/share -o username=User,rw,uid=User,gid=users
What can cause such cifsd's CPU consumption and how to fix it?
bing different
Offline
As nobody would have guessed, a short search for "cifsd high cpu" yields many results, not just recently but all over the place. This is a general problem with userspace file systems and neither limited to gfvs and fused based nor unixoid systems. I'd say you were lucky it worked.
What does "previously" mean? Can you retrace what you did since the last time it worked well? Are you sure it worked or did you just not notice the problem?
Offline
Actually the high loading of CPU begins only in some time after mounting. Before this, cifsd doesn't even appear on the first page of 'top'. I just checked the time interval: high load began exactly in 1 hour after mounting (timeout somewhere in the cifs stack?). 1 hour elapsed from 'mount' command; the last access to the share was maybe 10 or 15 minutes before the share became inaccessible.
After the high load begins, the share becomes inaccessible (or vice versa - high load begins due the inaccessible share?). ls produces the following:
$ ls /mnt/share
ls: cannot access '/mnt/share': Host is down
The 'top' output is as follows:
PID USER PR NI VIRT RES %CPU %MEM TIME+ nTH S COMMAND
20252 root 20 0 0.0m 0.0m 15.0 0.0 6:35.86 1 S cifsd
1097 root 20 0 396.9m 67.8m 7.2 3.4 37:45.49 2 S Xorg
1157 al 20 0 623.0m 29.7m 6.5 1.5 0:54.82 3 S xfce4-terminal
20922 root 20 0 0.0m 0.0m 4.6 0.0 0:04.15 1 S kworker/0:1
20926 al 20 0 43.7m 3.8m 2.0 0.2 0:00.78 1 R top
1069 al 9 -11 605.2m 6.7m 1.3 0.3 12:26.85 3 S pulseaudio
7 root 20 0 0.0m 0.0m 0.7 0.0 1:13.70 1 R rcu_preempt
9238 al 20 0 106.1m 20.4m 0.7 1.0 0:12.08 1 S ranger
1 root 20 0 132.4m 5.5m 0.0 0.3 1:51.59 1 S systemd
2 root 20 0 0.0m 0.0m 0.0 0.0 0:00.06 1 S kthreadd
4 root 0 -20 0.0m 0.0m 0.0 0.0 0:00.00 1 S kworker/0:0H
6 root 20 0 0.0m 0.0m 0.0 0.0 1:05.11 1 S ksoftirqd/0
8 root 20 0 0.0m 0.0m 0.0 0.0 0:00.00 1 S rcu_sched
9 root 20 0 0.0m 0.0m 0.0 0.0 0:00.00 1 S rcu_bh
On the Windows side there was no configuration changes or updates in the mentioned 1.5-2 months. So one might guess that some component in the cifs stack had some changes in the default configuration or working.
EDIT: I leaved it for some time with high load, and after 1 hour 10 minutes, the high load ended and the share became normally accessible without remounting. Some file indexer program causes it? updatedb is not seen in the 'top' list and also this share is in the PRUNEPATHS in /etc/updatedb.conf.
EDIT2: in 30 or 40 minutes after high load ended, it began again without any visible causes.
Last edited by nbd (2017-04-09 14:57:13)
bing different
Offline
Strange, but with Windows 8.1 shares this problem doesn't occur. They are mounted almost identically, but with one additional option: 'vers=2.0' (without this option Windows 8.1 shares don't work). I wonder does someone work with Windows 7 shares using the current cifs-utils without the aforementioned problem?
bing different
Offline