대용량 NAS 파일 복사가 인터랙티브 셀프호스팅 앱을 지연시키는 이유는 무엇인가요?

대용량 NAS 파일 복사는 지속적인 대량 전송이 데이터베이스, 미디어 서비스, 대시보드, 검색 인덱스, 자동화 컨테이너에서 사용하는 동일한 디스크 큐, 캐시, 메모리 대역폭, CPU 시간, 네트워크 경로 및 쓰기 백 파이프라인을 점유할 수 있기 때문에 인터랙티브 셀프호스팅 앱을 지연시킵니다.

복사 작업은 우수한 순차 처리량을 보고할 수 있지만 해당 앱들은 느리거나 일관성이 없게 됩니다. 대량 전송 속도는 NAS가 시간당 얼마나 많은 데이터를 이동하는지를 측정하는 반면, 인터랙티브 성능은 대량 작업이 활성화된 상태에서 작은 동기 요청이 얼마나 빨리 완료되는지에 달려 있습니다.

빠른 순차 복사도 왜 인터랙티브 지연 시간을 악화시킬 수 있나요?

순차 전송은 비교적 적은 탐색 및 요청 오버헤드로 인접한 큰 영역을 이동하기 때문에 효율적입니다. 그러나 대량 처리량과 인터랙티브 지연 시간은 서로 다른 목표입니다. 장치는 MB/s 단위로 생산성을 유지하면서도 작은 데이터베이스나 메타데이터 작업은 더 오래 대기할 수 있습니다.

복사 도구는 보통 여러 개의 읽기 및 쓰기 작업을 동시에 진행하여 스토리지와 네트워크가 계속 바쁘게 유지됩니다. 반면 인터랙티브 앱은 대역폭을 적게 사용하는 작은 요청을 보내지만 특정 읽기, 로그 쓰기 또는 트랜잭션 커밋이 완료될 때까지 사용자 응답을 차단하는 경우가 많습니다.

따라서 평균 복사 처리량은 원활하게 유지될 수 있지만 앱의 꼬리 지연 시간은 급격히 증가합니다. NAS는 복사 작업 사이에 짧은 시간도 유휴 상태가 아니어서 작은 요청을 즉시 처리할 수 없습니다.

긴 복사 작업이 스토리지 큐를 어떻게 점유하나요?

대용량 파일이나 디렉터리 트리는 수분 또는 수시간 동안 지속적으로 I/O를 제출할 수 있습니다. 대용량 전송은 스토리지 큐를 지속적으로 바쁘게 유지할 수 있습니다, 이로 인해 지연에 민감한 요청이 이미 대량 작업이 있는 큐에 들어가게 됩니다.

HDD 풀에서는 작은 랜덤 앱 I/O와 순차 복사를 교차시키면 액추에이터 이동을 강제하여 두 패턴 모두 효율을 떨어뜨릴 수 있습니다. SSD에서는 컨트롤러가 더 많은 작업을 병렬 처리할 수 있지만, 유한한 큐, NAND 채널, 가비지 컬렉션, 펌웨어 스케줄링이 여전히 지연 한계를 부과합니다.

깊은 큐는 장치 활용도를 극대화하지만 체류 시간을 증가시킵니다. 4킬로바이트 데이터베이스 읽기는 선택되면 서비스 시간은 짧지만 대부분의 시간은 메가바이트 단위 복사 트래픽 뒤에서 대기하는 데 소비됩니다.

왜 복사 트래픽이 유용한 캐시 데이터를 내쫓을 수 있습니까?

운영체제와 스토리지 스택은 느린 장치 읽기를 피하기 위해 최근에 접근한 데이터를 캐시합니다. 긴 스캔이나 복사는 넓은 주소 범위를 건드리므로 대량 읽기는 캐시가 일시적 스트리밍 데이터와 활성 애플리케이션 작업 세트를 구분하지 못할 때 지연에 민감한 캐시 항목을 내쫓을 수 있습니다.

데이터베이스, 사진 인덱스, 미디어 카탈로그 또는 웹 애플리케이션은 RAM에 남아 있는 핫 메타데이터와 인덱스에 의존했을 수 있습니다. 복사가 해당 페이지를 교체한 후 다음 인터랙티브 요청은 느린 스토리지에서 데이터를 가져와야 합니다.

복사 속도가 눈에 띄게 떨어진 후에도 유용한 작업 세트를 다시 워밍업해야 하므로 지연이 지속될 수 있습니다. 복사는 완료되었지만 캐시 영역이 변경되어 어떤 데이터가 저지연 접근을 받는지가 달라졌습니다.

파일을 읽고 쓰는 것 외에 어떤 추가 작업이 발생합니까?

NAS는 최종 디스크에 기록을 커밋하기 전에 메모리나 플래시에 기록을 인정할 수 있습니다. 쓰기-백은 작업을 나중 플러시로 이동시키므로 빠른 초기 복사가 지속적인 더티 데이터 쓰기 백으로 이어질 수 있습니다.

파일시스템은 할당 맵, 디렉터리, 타임스탬프, 체크섬, 저널, 그리고 카피 온 라이트 메타데이터도 업데이트합니다. RAID나 이레이저 코딩은 패리티 작업을 추가할 수 있으며, 스냅샷은 그렇지 않으면 해제될 오래된 블록을 보존할 수 있습니다.

동일한 NAS 내에서 복사는 데이터가 같은 풀에서 읽히고 다시 쓰여질 때 진행 표시줄이 나타내는 것보다 더 비용이 많이 들 수 있습니다. 서버 측 복사 또는 reflink 지원은 물리적 이동을 피할 수 있지만, 프로토콜, 파일 시스템, 복사 도구가 해당 기능을 사용할 때만 가능합니다.

네트워크 및 메모리 압력이 컨테이너 앱에 어떻게 도달하나요?

고처리량 도구는 종종 파이프라인을 가득 채우기 위해 동시성을 사용하며, 병렬 전송은 공유 자원에 대한 압력을 증가시킵니다. 홈 서버에서는 동일한 방법이 더 많은 소켓 버퍼, 페이지 캐시, 메모리 복사, CPU 사이클, SMB 또는 NFS 요청 슬롯을 소비할 수 있습니다.

더러운 페이지는 커널이 전경 또는 백그라운드 쓰기 작업을 시작할 때까지 증가할 수 있습니다. 그 시점에서 관련 없는 컨테이너들이 메모리 회수, 파일 시스템 잠금, I/O 스케줄링, 그리고 자신의 요청을 처리하는 데 필요한 CPU 시간을 놓고 경쟁할 수 있습니다.

앱 캐시는 이미 내구성 저장소와 경쟁하고 있습니다. 대용량 복사는 로그, 썸네일, 데이터베이스, 컨테이너 상태를 이미 제공하고 있을 수 있는 I/O 경로에 지속적인 용량 중심 작업 부하를 추가합니다.

홈 NAS가 대화형 작업 부하를 어떻게 보호할 수 있나요?

가장 강력한 보호는 애플리케이션의 활성 작업 집합을 더 낮은 대기 시간 계층에 유지하는 것입니다. 저지연 캐시는 활성 작업 집합을 보호합니다 캐시가 반응성을 유지해야 하는 데이터에 맞게 크기 조정되고 배치될 때.

기타 제어 방법으로는 복사 속도 제한, I/O 우선순위, cgroup 가중치, 데이터셋별 제한, 예약된 마이그레이션 창, 별도의 SSD 및 HDD 풀, NAS를 용량 및 백업용으로 사용하는 로컬 애플리케이션 데이터베이스가 있습니다.

복사 속도(MB/s)뿐 아니라 복사 실행 중 앱 지연 시간을 측정하세요. 목표는 모든 전송을 느리게 하는 것이 아니라, 사용자가 즉시 응답하기를 기대하는 셀프 호스팅 서비스에 충분한 대기열, 캐시, CPU 및 쓰기 여유를 남기는 것입니다.

자주 묻는 질문

복사가 빠른데 왜 앱이 느려지나요?

복사는 지속적인 처리량에 최적화되어 있지만, 앱은 소규모 요청의 완료 시간에 의존합니다. 높은 처리량과 낮은 지연 시간은 관련 있지만 다른 성능 목표입니다.

NVMe가 이 문제를 해결할까요?

서비스 시간을 줄이고 더 큰 병렬성을 지원하지만, NVMe는 여전히 유한한 대기열, 컨트롤러 대역폭, NAND 자원, 캐시, CPU 및 열 한계가 있습니다.

하나의 대용량 파일이 많은 소규모 파일보다 덜 해로운가요?

단일 대용량 파일은 보통 더 순차적이고 메타데이터 효율적입니다. 많은 소규모 파일은 디렉터리, 할당, 권한, 열기, 닫기 및 메타데이터 작업을 추가하지만, 어느 작업도 지속적인 대기열 및 캐시 압박을 만들 수 있습니다.

셀프 호스팅 앱 데이터베이스는 NAS에 두어야 할까요?

그럴 수 있지만, 지연 시간에 민감한 데이터베이스는 예측 가능한 소규모 I/O 성능을 가진 스토리지에서 이점을 얻습니다. 별도의 SSD 풀이나 로컬 애플리케이션 스토리지가 대용량 복사와 더 명확한 경계를 제공할 수 있습니다.

최종 요점

대용량 NAS 파일 복사는 용량 중심 작업이 공유 대기열, 캐시, 메모리, 네트워크 및 쓰기 경로를 점유할 때 대화형 앱의 지연을 초래합니다. 복사는 처리량으로 측정되기 때문에 빠르게 유지될 수 있지만, 사용자 대상 요청은 완료 지연 시간으로 측정되어 느려집니다. 티어링, 속도 제한, I/O 우선순위, 별도 풀, 비혼잡 시간 스케줄링은 모든 애플리케이션의 응답 시간을 희생하지 않고 대용량 전송 용량을 보존합니다.