SMB 속도 저하가 서명 때문인지 스토리지 때문인지 확인하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Tell Whether SMB Slowness Comes From Signing or Storage - Zima Store Online

로컬 디스크와 원시 네트워크 한계를 측정한 후에만 서명된 테스트 경로와 서명되지 않은 테스트 경로를 비교하세요. 서명이 기본적인 원인인 것은 아닙니다.

저전력 NAS에서 신뢰할 수 있는 LAN이 예상보다 낮은 SMB 처리량에 도달할 때 이 결정이 중요합니다. 서로 경쟁하는 상태는 서명 또는 암호화의 CPU 비용과 디스크, 메타데이터, 네트워크 또는 단일 스트림 한계입니다. 저장된 구성과 폐기 가능한 데이터로 시작하고, 한 번에 한 분기만 관찰하며, 테스트로 인해 데이터 손실, 권한 또는 가용성 위험이 확대되면 중단하세요.

서명 또는 암호화의 CPU 비용을 디스크, 메타데이터, 네트워크 또는 단일 스트림 한계와 분리하기

무엇이든 변경하기 전에 환경을 기록하세요. 소프트웨어 및 펌웨어 버전, 장치 ID, 마운트 또는 네트워크 경로, 여유 공간, 권한, 관찰된 증상을 포함해야 합니다. 기준선에는 신뢰할 수 있는 LAN이 저전력 NAS에서 예상보다 낮은 SMB 처리량에 도달하는 상황을 재현할 수 있을 만큼 충분한 세부 정보가 있어야 합니다.

첫 번째 후보는 서명 또는 암호화의 CPU 비용입니다. 두 번째는 디스크, 메타데이터, 네트워크 또는 단일 스트림 한계입니다. 현재 SMB 서명 동작은 테스트에 사용되는 메커니즘 또는 명령 경계를 정의하지만, 이 특정 홈 서버에서 직접 관찰한 결과를 대신하지는 않습니다.

판별 테스트를 실행하기 전에 통과 조건과 중단 조건을 작성하세요. 통과는 한 분기가 예측한 증거를 변경하면서 관련 없는 서비스는 변경하지 않아야 하며, 실패 시에는 추측성 수정 작업을 연쇄적으로 실행하는 대신 시스템을 저장된 상태로 되돌려야 합니다.

하나의 통제된 판별 테스트 실행

다음 판별 테스트를 사용하세요. 로컬 순차 및 소형 파일 스토리지, iperf, 협상된 SMB 보안, CPU를 측정한 다음, 하나의 통제된 SMB 전송을 반복합니다. 결과가 변경된 변수에 기인하도록 작업량, 클라이언트, 경로, 파일 세트 및 타이밍을 일정하게 유지하세요.

Samba 서명 설정을 사용하여 실제로 두 분기를 구분할 수 있는 필드를 선택한 다음, 타임스탬프, 종료 상태, 오류 텍스트, 장치 또는 스냅샷 ID, 지연 시간, 전송된 바이트 수, 권한 및 복구 상태를 수집하세요. ID, 지속성 또는 애플리케이션 상태가 테스트 중인 주장이라면 명령이 정상적으로 종료된 것만으로는 충분하지 않습니다.

첫 번째 실행 후 재시작, 재연결, 재마운트 또는 콜드 캐시가 원래 조건의 일부인 경우 해당 이벤트 후 테스트를 한 번 반복하세요. 첫 번째 실행이 파괴적이거나 환경을 복원할 수 없다면 중단하고 폐기 가능한 복사본에서 대신 재현하세요.

Get-SmbConnection | Select ServerName,Dialect,Signed
# NAS CPU, 디스크 지연 시간 및 iperf와 비교

증거가 어느 분기를 뒷받침하는지 해석하기

통과: 서명을 사용할 때만 CPU가 포화되고 디스크와 네트워크에 여유가 있거나, 서명 여부와 관계없이 스토리지 지연 시간이 높게 유지됩니다. 결론이 보편적인 주장이 되지 않도록 통과한 정확한 버전, ID 및 작업량을 기록하여 조건부 결론으로 유지하세요.

실패: 성능이 보안 상태가 아니라 파일 크기, 디스크 큐, Wi-Fi 또는 네트워크 경로를 따릅니다. 네트워크, 메모리, 권한 또는 소스 일관성이 양쪽 모두에 영향을 줄 수 있으므로 실패가 자동으로 반대 분기를 입증하는 것은 아닙니다. 에스컬레이션하기 전에 이러한 공유 종속성을 분리하세요.

예외 또는 모호한 결과: 필수 서명을 복원하고 무결성을 약화하기 전에 확인된 하위 계층을 최적화하세요. 복구 가능한 복사본이 생길 때까지 로그를 보존하고 복구, 정리, 삭제, 파티션 재설정 또는 재귀적 소유권 변경 명령을 실행하지 마세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

일치하는 조치를 적용하고 원래 장애를 재현하기

관찰된 분기에 맞는 조치를 적용한 다음 축소된 대체 조건이 아니라 원래 조건을 반복하세요. 이 결정은 서명을 사용할 때만 CPU가 포화되고 디스크와 네트워크에 여유가 있거나, 서명 여부와 관계없이 스토리지 지연 시간이 두 사이클 또는 관련 재부팅, 절전, 중단 또는 부하 전환에 걸쳐 높게 유지될 때만 유효합니다.

SMB 영속 핸들을 사용하여 가장 가까운 종속 워크플로를 확인하되, 원래 트리거는 변경하지 마세요. 관련 없는 데이터 세트, 공유, 컨테이너, 사용자 및 복구 지점은 이전의 접근성과 타이밍을 유지해야 합니다.

중단 기준은 명확합니다. 성능이 보안 상태가 아니라 파일 크기, 디스크 큐, Wi-Fi 또는 네트워크 경로를 따른다면 마지막으로 검증된 구성으로 돌아가 증거를 보존하고, 해당 분기가 반복적으로 재현될 때만 더 심층적인 플랫폼 또는 하드웨어 테스트로 에스컬레이션하세요.

목표 결과가 유지된 후에는 Wi-Fi 전송 테스트와 비교하여 수정으로 인해 인접 서비스에 위험이 전가되지 않는지 확인하세요. 새로운 백업, ID, 시간 초과 또는 가용성 문제가 발생한 성공적인 목표 테스트는 여전히 실패한 변경입니다.

FAQ

SMB 서명과 스토리지 병목 현상에 관해서는 벤치마크를 위해 서명을 비활성화해야 하는지, 작은 파일이 하나의 큰 파일보다 느린 이유가 무엇인지, 멀티채널이 서명 병목 현상을 숨길 수 있는지에 대한 추가 검색이 일반적입니다. 아래 답변은 이러한 예외 사례를 주요 결정과 분리합니다.

통과 기준은 바뀌지 않습니다. 서명을 사용할 때만 CPU가 포화되고 디스크와 네트워크에 여유가 있거나, 서명 여부와 관계없이 스토리지 지연 시간이 높게 유지되어야 합니다. 후속 조건에서 파일 시스템, ID, 네트워크 경로 또는 애플리케이션 버전이 변경되면 해당 변경의 영향을 받은 판별 테스트만 반복하세요.

성능이 보안 상태가 아니라 파일 크기, 디스크 큐, Wi-Fi 또는 네트워크 경로를 따를 때는 실험을 확대하지 마세요. 이 시점에서는 필수 서명을 복원하고 무결성을 약화하기 전에 확인된 하위 계층을 최적화하세요. 플랫폼, 스토리지 또는 하드웨어 담당자에게 에스컬레이션하기 전에 증거를 보존하세요.

벤치마크를 위해 서명을 비활성화해야 하나요?

격리된 신뢰할 수 있는 테스트 경로에서, 그리고 정책이 허용하는 경우에만 비활성화하세요. 이후 즉시 복원해야 합니다.

작은 파일이 하나의 큰 파일보다 느린 이유는 무엇인가요?

메타데이터 왕복과 스토리지 지연 시간이 지배적이므로 서명은 전체 시간에서 작은 부분만 차지할 수 있습니다.

멀티채널이 서명 병목 현상을 숨길 수 있나요?

멀티채널은 여러 연결과 CPU에 작업을 분산할 수 있지만, 협상된 보안 설정과 실제 서버 한계를 확인해야 합니다.

동일한 작업량에서 증거가 서명 또는 암호화의 CPU 비용이나 디스크, 메타데이터, 네트워크 또는 단일 스트림 한계를 따르고, 일치하는 조치가 새로운 문제를 만들지 않고 원래 증상을 제거하면 진단이 완료됩니다. 어느 분기도 반복적으로 유지되지 않는다면 로그와 저장된 상태를 그대로 보존하세요. 불확실성은 더 많은 수정 작업을 쌓을 이유가 아니라 에스컬레이션할 이유입니다.