SMB 또는 네트워크 설정을 변경하기 전에 파일 수가 아닌 링크 속도가 원인인지 테스트하세요.
가정용 NAS에서는 수천 개의 작은 파일이 클라이언트와 서버가 경로 조회, 권한 확인, 열기, 생성, 메타데이터 업데이트, 닫기, 애플리케이션 측 스캔을 각 객체마다 반복하도록 만듭니다. 기가비트 또는 2.5GbE 링크는 복사가 느리게 진행되는 동안 대부분 유휴 상태일 수 있으므로, 유용한 첫 단계는 총 바이트 수는 비슷하게 유지하되 객체 수를 변경하는 A/B 테스트를 수행한 후 고정된 순서로 스토리지, 클라이언트, 복사 도구 테스트를 진행하는 것입니다.
동일한 바이트 수의 큰 파일과 작은 파일 비교
동일한 소스 스토리지에 두 가지 테스트 세트를 만드세요: 하나는 큰 파일, 다른 하나는 총 크기가 대략 같은 수천 개의 작은 파일이 들어있는 폴더입니다. 동일한 클라이언트, SMB 경로, 시간대에 두 세트를 동일한 NAS 공유로 복사하세요.
TrueNAS 사용자 보고서는 작은 파일 SMB 속도 저하의 특징적인 패턴을 보여주며, 큰 파일은 정상에 가까운 네트워크 속도를 유지했습니다. 이 대비는 단일 속도 수치보다 유용한데, 작업 부하 형태가 병목 현상을 바꾼다는 것을 증명하기 때문입니다.
경과 시간, 총 파일 수, 총 바이트, 초당 파일 수, 평균 MB/s, 속도 저하가 즉시 시작되는지 또는 캐시가 채워진 후 시작되는지 기록하세요. 두 세트 모두 느리면 일반 네트워크 또는 스토리지 경로를 먼저 조사하고, 작은 파일 세트만 느리면 메타데이터 중심 테스트를 계속 진행하세요.
네트워크 용량과 파일당 작업 분리
동일한 클라이언트와 NAS 간에 메모리-대-메모리 네트워크 테스트를 실행한 후 큰 파일 SMB 결과와 비교하세요. 깨끗한 네트워크 테스트와 빠른 큰 파일 복사는 작은 파일 작업 부하가 링크를 가득 채우지 못해도 링크가 데이터를 전송할 수 있음을 보여줍니다.
작은 파일은 복사를 반복적인 요청-응답 작업으로 전환합니다. Eclectic Light는 SMB 메타데이터 중심 백업이 적은 페이로드 데이터 이동에도 예상보다 오래 걸릴 수 있음을 문서화했습니다.
이 결과에 MTU, 듀플렉스, 링크 집계를 먼저 변경하는 것으로 대응하지 마세요. 대신 초당 파일 수와 부하 지연 시간을 추적하세요. 다음 유용한 질문은 반복 작업이 소스, NAS 대상, 또는 클라이언트 측 검사 중 어디에서 대기하는지입니다.
소스와 대상 메타데이터 지연 시간 별도 테스트
작은 파일 세트를 소스에서 클라이언트의 다른 로컬 폴더로 복사한 다음, 동일한 세트를 NAS에서 로컬로 생성하거나 추출하세요. 이 두 테스트는 SMB가 개입하지 않은 상태에서 소스 읽기와 NAS 생성 작업을 분리합니다.
Unraid 토론에서는 큰 파일 전송 중에는 보이지 않던 느린 파일당 작업을 측정했습니다. 중요한 신호는 네트워크가 개입하기 전에 로컬 대상 생성이 이미 느린지 여부입니다.
클라이언트 로컬 복사가 느리면 소스 디스크, 파일 시스템, 암호화, 파일 배치를 점검하세요. NAS 로컬 생성이 느리면 대상 풀, 캐시 계층, 패리티 경로, 여유 공간 단편화, 메타데이터 장치, 동기 쓰기 동작을 점검한 후 SMB 조정을 고려하세요.
양쪽 끝점에서 보안 스캔 및 인덱싱 측정
안티바이러스, 엔드포인트 보호, 썸네일 생성, 콘텐츠 인덱싱, 동기화 감시자, 미디어 스캐너는 모든 새 파일을 검사할 수 있습니다. 이들의 고정된 객체당 비용은 수천 개 항목을 빠르게 생성하는 작업 부하를 지배할 수 있습니다.
전용 테스트 폴더에 대해서만 실시간 스캔과 인덱싱을 일시적으로 제외하는 제어된 테스트를 실행한 후 즉시 보호를 복원하세요. 목적은 보안을 비활성화하는 것이 아니라 속도 저하가 파일당 검사와 연관되는지 확인하는 것입니다.
초당 파일 수가 급격히 증가하면 신뢰할 수 있는 백업 스테이징 또는 생성된 캐시 데이터에 대해서만 더 안전한 장기 제외를 만들거나 전송 후 스캔을 예약하세요. 결과가 변하지 않으면 원래 설정을 복원하고 설명되지 않은 예외 누적 대신 복사 도구 동작으로 넘어가세요.
데이터 세트를 변경하지 않고 복사 도구와 동시성 비교
파일 탐색기, Finder, Robocopy, rsync, 백업 클라이언트, 아카이브 도구는 서로 다른 큐 깊이, 메타데이터 호출, 재시도 규칙, 병렬성을 사용할 수 있습니다. 관련 없는 작업 부하를 비교하지 말고 동일한 소스 트리와 대상에 대해 두 도구를 비교하세요.
Resilio의 대용량 파일 수 스캔 논의는 내용 변경이 적어도 작업이 메타데이터에 묶일 수 있는 이유를 설명합니다. 더 많은 스레드는 일부 지연을 숨길 수 있지만 NAS에 동시 생성 과부하를 줄 수도 있습니다.
동시성을 한 단계씩 늘리고 초당 파일 수가 더 이상 개선되지 않거나 지연이 급격히 증가하거나 NAS가 쓰기 대기열을 시작하면 중지하세요. 도구가 허용하는 최고 값이 아니라 실제 작업 부하를 일관되게 개선하는 설정을 유지하세요.
결과 패턴을 사용해 가장 작은 수정 선택
진단은 네트워크 용량, 소스 읽기, NAS 생성, 끝점 스캔, SMB 요청 동작, 복사 도구 중 하나의 주요 단계를 가리켜야 합니다. 모든 가능한 조정을 한 실험에 결합하지 마세요. 최종 속도 변화가 원인을 설명하지 못하게 됩니다.
ZimaSpace의 파일 수가 NAS 작업을 증가시키는 이유 설명은 이 작업 부하에서 초당 파일 수가 MB/s보다 더 중요할 수 있는 근본 이유를 제공합니다.
같은 작은 파일 세트가 반복 실행에서 큰 파일 속도, 권한, 복원 동작, NAS 반응성을 해치지 않고 개선될 때만 수정을 수용하세요. 개별 복구가 필요 없으면 변경 불가능한 작은 파일을 아카이브로 묶어 객체 오버헤드를 줄일 수 있지만, 이는 보편적인 SMB 수리가 아니라 작업 흐름 결정입니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

