smbdWindows에서 Samba 공유에 액세스할 때 Windows에서 공유를 사용하는지 여부에 관계없이 데몬이 항상 CPU의 약 10-20%를 사용한다는 것을 알았습니다 . 공유/창을 닫아도 smbdCPU는 계속 사용되며, 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)
클라이언트: 윈도우 8.1
아무런 문제 없이 CentOS 6 설치에서 동일한 구성을 사용했습니다. 또한 내 Windows 컴퓨터의 네트워크 공유와 통신할 수 있다고 생각되는 모든 소프트웨어(바이러스 백신 및 백업 소프트웨어)를 비활성화해 보았습니다.
이 문제를 해결하는 데 도움을 줄 수 있는 사람이 있나요?
답변1
조금 늦었을지 모르지만 비슷한 문제에 직면하면서 이것을 발견했습니다.
저는 Samba를 드라이브 스토리지로 구성하고 이더넷을 통해 노트북에 직접 연결한 Raspberry Pi B+를 가지고 있습니다.
내 설정은 다음과 같습니다.
- 여러 개의 외장 하드 드라이브가 Raspberry Pi에 연결되어 있습니다.
- Raspberry pi는 직접 이더넷을 사용하여 노트북에 연결됩니다.
내가 발견했다:
- smbd는 외부에서 읽을 때 CPU 사용량(45%)이 높습니다.
- Mount.ntfs는 외부에 쓸 때 CPU 사용량(46%)이 높습니다.
B+ 사양을 고려하면 이는 간단한 적절한 업데이트에 1분 정도 걸리기 때문에 다소 그럴듯해 보입니다. 따라서 목록을 새로 고치는 것뿐이라면...
이것좋은 독서 효과를 가져올 수 있습니다.