Windowsを介してマップされたドライブにアクセスすると、Samba 4のCPU使用率が高くなる
WindowsからSamba共有にアクセスすると、smbdデーモンは、共有がWindowsから使用されているかどうかに関係なく、常に約10〜20％のCPUを使用することに気づきました。共有/ウィンドウを閉じても、smbdは引き続きCPUを使用し、Windowsの再起動/シャットダウンだけでCPU使用率を通常に戻すことができます。
これは、Windowsを再起動または起動した直後です。共有はマップされていますが、まだアクセスされていません。私がそれにアクセスするまで、それはWindowsでこの「赤」のステータスになります。
他に何かする前に、Linuxでsmbstatusとtopを確認します。
これまでのところ問題はありません-topのCPU使用率はまったく目立たないため、すべて良好です。
しかし...その後Windowsから共有にアクセスすると、Linux CPUはすぐに10〜20％に上昇します。
そしてsmbstatusは常にいくつかのロックされた（？）ファイルを表示しますが、私のWindowsからは確かに（？）にアクセスできません。
testparmは私のsmb.conf構成を示しています。
私がこれを「修正」できる唯一の方法は、Windowsを再起動するか、ドライブ/共有をマップ解除することです。
もう1つの奇妙なこと-共有/ドライブのマップを解除しても、もちろんUNCを介して共有にアクセスできます...そして、UNCを介してアクセスしても、CPUはまったく上昇しません！？おかしい！
私のハードウェアはかなり最近/最新です：
サーバー：Core i5 1.5-2.9GHzデュアルコア/ HT 16GB RAM Samsung 850 Pro（512GB）
クライアント：Windows 8.1
CentOS 6のインストールで同じ構成を問題なく使用しました。また、自分のWindowsコンピューターのネットワーク共有と通信できると思われるものすべてを無効にしてみました（ウイルス対策ソフトウェアとバックアップソフトウェア）。
誰でもこの問題を解決する手助けはできますか？
おそらく少し遅れますが、同様の問題を抱えながら、私はこれを見つけました。
ドライブストアとして構成されたsambaを備えたRaspberry Pi B +を持ち、イーサネット経由でラップトップに直接接続しています。
私のセットアップは次のとおりです：
- raspberry Piに接続されたいくつかの外付けハードドライブ。
- ラズベリーパイは私のラップトップへの直接イーサネット接続を使用しています。
見つけた：
- 外部からの読み取り時のsmbdによるCPU使用率が高い（45％）
- 外部への書き込み時のmount.ntfsによるCPU使用率が高い（46％）
B +の仕様を考えると、単純なaptの更新はリストを更新するだけで1分かかるので、ある程度信じられそうです...
これ は良い読書になるかもしれません