我注意到，当我从 Windows 访问我的 Samba 共享时，smbd守护进程将始终使用大约 10-20% 的 CPU - 无论共享是否从 Windows 使用。即使我关闭共享/窗口，smbd也会继续使用 CPU，只有重新启动/关闭我的 Windows 才能使 CPU 使用率降至正常水平。
这是我刚刚重新启动/启动 Windows 时的情况 - 共享已映射但尚未访问。在我访问它之前，它在 Windows 中将处于“红色”状态：
在我做任何其他事情之前，我会检查我的 Linux 上的smbstatus和top：
到目前为止还没有问题——CPU 使用率根本不明显，top所以一切都还好。
但是...当我从 Windows 访问共享时，Linux CPU 立即上升到 10-20%：
并且smbstatus总是显示一些锁定的（？）文件，这些文件肯定（？）不能从我的Windows访问：
显示testparm了我的smb.conf配置：
我可以“解决此问题”的唯一方法是重新启动 Windows 或取消映射驱动器/共享。
另一件奇怪的事情 - 当我取消映射共享/驱动器时，我当然仍然可以通过 UNC 访问共享...并且当通过 UNC 访问它时，它根本不会提高 CPU 性能！？诡异的！
我的硬件是最新/最新的：
服务器：Core i5 1.5-2.9GHz 双核/HT 16GB RAM Samsung 850 Pro (512GB)
客户端：Windows 8.1
我在 CentOS 6 安装上使用了相同的配置，没有任何问题。我还尝试禁用任何我认为可以与我的 Windows 计算机上的网络共享进行通信的软件（防病毒软件和备份软件）。
任何人都可以帮助解决这个问题吗？
答案1
可能有点晚了，但我发现了这一点，同时遇到了类似的问题。
我有一个 Raspberry Pi B+，将 samba 配置为驱动器存储，并通过以太网直接连接到我的笔记本电脑。
我的设置如下：
- 几个外部硬盘驱动器连接到树莓派。
- Raspberry pi 使用直接以太网连接到我的笔记本电脑。
我已经发现：
- 从外部读取时 smbd 的 CPU 使用率较高 (45%)
- 写入外部时 mount.ntfs 的 CPU 使用率较高 (46%)
考虑到 B+ 的规格，这似乎有点可信，因为简单的 apt 更新需要一分钟，所以如果只是刷新列表......
这可能会带来一些好的阅读效果