대용량 홈 NAS 쓰기 시에만 패킷 손실이 발생하는 원인은 무엇인가요?

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

대용량 NAS 쓰기 중 패킷 손실은 일반적으로 디스크 자체가 아니라 클라이언트와 NAS 간 네트워크 경로의 지속 부하 약점을 드러냅니다.

짧은 핑이나 디렉터리 탐색은 트래픽이 적어 문제가 없을 수 있지만, 수 기가바이트 규모의 SMB 쓰기는 클라이언트가 계속 전송하고 스위치 큐를 가득 채우며 케이블을 라인 속도로 사용하고 NAS NIC와 CPU가 지속적으로 수신하도록 강제합니다. 따라서 진단은 유휴 상태와 부하 상태 측정을 비교하고, 쓰기 방향을 홉별로 따라가며, 케이블, 포트, 드라이버 기능 또는 송신 조건을 한 번에 하나씩 변경해야 합니다.

손실이 쓰기 부하에서만 발생하는지 증명하기

복사 전, 지속적인 대용량 파일 쓰기 중, 복사 후에 쓰기 클라이언트에서 NAS로 지속적인 소형 핑을 실행하세요. 동시에 양쪽 끝점에서 SMB 처리량, 부하 시 지연, 재전송, 인터페이스 오류 카운터를 기록합니다.

패킷 손실 테스트는 핑, iperf, 인터페이스 통계를 결합해야 합니다. 단일 4패킷 핑은 짧은 부하 유발 실패를 놓칠 수 있기 때문입니다. 유용한 패턴은 손실이나 오류가 쓰기 시작과 함께 나타나고 쓰기 중단 시 사라지는지 여부입니다.

패킷이 결국 돌아오면서 지연만 증가한다면, 패킷 손실로 판단하기 전에 큐잉과 버퍼블로트를 조사하세요. NAS 저장소가 일시 중지되지만 핑과 인터페이스 카운터가 깨끗하다면 병목은 이더넷 전달보다는 쓰기 경로, 파일 시스템, 캐시 플러시, 패리티 또는 애플리케이션일 가능성이 높습니다.

하드웨어 교체 전 쓰기 방향을 따라가세요

클라이언트에서 NAS로 쓰기 중에는 클라이언트 NIC가 송신기, 스위치는 NAS 포트 방향으로 전달자, NAS NIC가 수신기입니다. 이 방향은 어떤 카운터와 교체가 실제로 결함을 분리할 수 있는지 알려줍니다.

NAS 송신 카운터가 깨끗하다고 해서 NAS 수신 측이 깨끗한 것은 아니며, 클라이언트 수신 카운터가 깨끗하다고 해서 클라이언트에서 나가는 프레임에 대해 많은 정보를 주지 않습니다. 클라이언트 TX 오류 및 드롭, 스위치 입출력 카운터, NAS RX 오류 및 드롭, TCP 재전송을 동일한 테스트 간격 동안 비교하세요.

각 실행 전에 카운터를 초기화하거나 기록하고, 동일한 대용량 파일을 전송한 후 실패 시에만 증가하는 카운터를 계산하세요. 물리적 오류, 큐 폐기, 누락된 패킷 또는 수신 드롭을 처음 기록하는 장치가 다음 테스트 지점이 됩니다.

지속적인 라인 속도에서 물리적 오류가 증가하는지 확인하세요

불량 케이블, 커넥터, 트랜시버 또는 스위치 포트는 가벼운 트래픽은 통과시키면서도 긴 쓰기 동안 CRC, 프레임, 캐리어 또는 심볼 오류를 누적할 수 있습니다. 대용량 전송은 올바르게 협상된 케이블을 “과부하”시키지 않으며, 단지 약한 물리 경로를 빠르게 드러낼 만큼 충분한 프레임을 생성합니다.

실제 파일 전송 문제 해결 사례는 대용량 복사 중 인터페이스 오류가 파일 크기 자체보다는 케이블, NIC, 포트 또는 중간 장비 문제를 가리킨다는 것을 보여줍니다.

한 번에 한 부품만 교체하세요: 먼저 패치 케이블, 그다음 스위치 포트, 가능하면 클라이언트 어댑터 또는 NAS 포트 순입니다. 오류 증가가 한 부품에 따라 발생하거나 해당 부품 교체 후 사라지면 물리 계층 진단이 확실해집니다.

SMB가 처리하기 전에 NAS 수신기가 프레임을 드롭하는지 확인하세요

네트워크가 전기적으로 깨끗해도 수신 호스트가 NIC 큐, 드라이버, 인터럽트 처리, CPU 또는 가상 스위치가 도착률을 처리하지 못해 패킷을 잃을 수 있습니다. 특히 쓰기 중 암호화, 컨테이너, 인덱싱 또는 패리티 작업을 수행하는 소형 NAS에서 그럴 수 있습니다.

직접 고속 이더넷 사례는 혼잡하지 않은 다중 홉 네트워크 없이도 호스트 패킷 처리 과부하를 설명합니다. 핵심 차이는 호스트 RX 드롭 또는 누락된 패킷 카운터가 증가하는 동안 케이블 CRC 카운터는 깨끗하다는 점입니다.

필수 NAS 서비스를 일시 중지한 상태에서 쓰기를 반복하고, 디스크 쓰기를 제거한 메모리 간 네트워크 작업을 테스트하세요. 저장소 I/O 없이도 수신 드롭이 지속되면 파일 시스템보다는 NIC 드라이버, 큐 깊이, 인터럽트 분배, 가상 스위치, 호스트 CPU에 집중하세요.

느리거나 공유되는 송신 포트에서 마이크로버스트를 찾아보세요

더 빠른 클라이언트가 느린 NAS 포트로 전송하거나 여러 클라이언트가 동시에 쓰거나 여러 입력 포트의 트래픽이 하나의 송신 큐로 모일 때 스위치 내부에서 패킷 손실이 발생할 수 있습니다. 평균 사용률은 안전해 보여도 짧은 버스트가 큐 용량을 초과할 수 있습니다.

마이크로버스트 패킷 손실 저장소 쓰기 예시는 두 개의 고속 송신자가 목적지 포트가 제공하는 송신 대역폭과 버퍼 공간을 잠시 초과할 수 있음을 보여줍니다.

한 송신자를 한 스위치로 테스트한 후 직접 연결 또는 동일 링크 속도 경로와 비교하세요. 경쟁 송신자, 느린 업링크 또는 중간 스위치를 제거했을 때 손실이 사라지면 NAS 디스크 교체 대신 송신 폐기 및 큐 동작을 점검하세요.

문제가 국한된 후에만 EEE 및 오프로드를 테스트하세요

에너지 효율 이더넷, 체크섬 오프로드, 대용량 전송 오프로드, 플로우 컨트롤, 인터럽트 조절은 특정 NIC 및 드라이버 조합에 영향을 줄 수 있지만 모든 기능을 한꺼번에 비활성화하면 실제 원인을 찾는 데 필요한 증거가 사라집니다.

문서화된 Raspberry Pi 이더넷 문제는 에너지 효율 이더넷 비활성화가 해당 컨트롤러와 링크 파트너에서 심각한 패킷 손실을 멈추게 했습니다. 이는 카운터나 교체가 케이블이나 스위치 큐가 아닌 끝점으로 지목한 후에만 유용한 A/B 테스트입니다.

한 기능씩 변경하고 동일한 대용량 쓰기를 반복하며 결과가 변하지 않으면 원래 설정으로 복원하세요. 드라이버 기능 우회법은 어댑터 모델, 드라이버 버전, 스위치 포트, 정확한 증상과 함께 문서화하여 나중에 업데이트로 테스트할 수 있도록 해야 하며, 설명되지 않은 조정을 그대로 두지 마세요.

결과 패턴을 사용해 다음 수리를 선택하세요

최종 진단은 왜 소량 트래픽은 깨끗하고 지속적인 쓰기는 실패하는지 설명해야 합니다. 물리적 오류는 신호 경로 문제를 나타내고, 스위치 송신 폐기는 큐 압력을, NAS RX 드롭은 수신기 과부하를, 깨끗한 네트워크 카운터와 멈춘 복사는 저장소 또는 애플리케이션 동작 문제를 가리킵니다.

ZimaSpace의 패킷 손실이 유용한 홈 서버 처리량을 감소시키는 방식 설명은 협상된 링크가 최대 속도를 유지하면서 SMB 쓰기가 느려지거나 일시 중지되거나 반복 재전송되는 이유를 해석하는 데 도움을 줍니다.

같은 대용량 쓰기가 안정적인 지연, 새로운 물리적 오류 없음, 수신 드롭 또는 송신 폐기 증가 없음, 무결한 목적지 체크섬과 함께 반복 완료될 때까지 문제를 해결했다고 선언하지 마세요. 증거가 네트워크와 저장소 경로를 구분하지 못하면 설정 변경을 중단하고 디스크 I/O를 제거한 상태에서 테스트를 다시 실행하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.