Jellyfin이 CPU, 메모리, 네트워크 또는 스토리지 중 무엇에 의해 병목되는지 어떻게 알 수 있나요?

에바 왕

IceWhale author

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

How Can You Tell Whether Jellyfin Is CPU-, Memory-, Network-, or Storage-Bound? - Zima Store Online

하나의 작업을 반복하고, 사용자가 보는 증상을 오류 또는 대기와 함께 포화되는 리소스에 대응시키면 Jellyfin의 병목을 식별할 수 있습니다.

CPU 그래프가 높다고 해서 CPU가 한계라는 뜻은 아니며, 스토리지가 활발하게 사용된다고 해서 스토리지가 원인이라는 뜻도 아닙니다. 동일한 파일, 클라이언트, 화질, 세션 수를 유지하면서 한 번에 하나의 조건만 변경하세요. 이렇게 하면 실제 의존성 한계와 클라이언트가 선택한 더 무거운 재생 경로를 구분할 수 있습니다.

재생 조건을 일정하게 유지하세요

미디어 파일 하나, 클라이언트 하나, 화질 정책 하나, 동시성 수준 하나를 선택하세요. 리소스 그래프를 확인하기 전에 세션이 다이렉트 재생, 리먹스 또는 트랜스코딩 중 어떤 방식으로 재생되는지 기록하세요. 재생 모드에 따라 사용량이 높아져야 하는 리소스가 달라지기 때문입니다.

리소스 동작을 비교하기 전에 서버 경로를 파악할 수 있도록 다이렉트 재생에서 트랜스코딩으로 전환되는 경우부터 시작하세요.

통제된 기준선을 사용하면 브라우저 트랜스코딩 세션과 네이티브 다이렉트 재생 세션을 비교한 뒤 그 차이를 하드웨어 병목이라고 잘못 판단하는 일을 막을 수 있습니다.

CPU와 메모리는 서로 다른 패턴을 보입니다

CPU 병목 작업은 일반적으로 소프트웨어 디코딩, 필터, 자막 합성 또는 인코딩과 함께 증가합니다. 반면 메모리 압박은 회수, 스와핑, 작업자 정체 또는 페이징으로 인한 스토리지 활동 증가로 나타납니다. 증상은 겹칠 수 있지만 카운터는 서로 다릅니다.

평균 CPU 또는 RAM 사용량만으로 결론을 내리지 말고 사용률과 포화도를 사용해 사용률, 포화도, 오류를 함께 확인하세요.

스토리지나 네트워크를 변경하지 않고 필터를 일시 중지하거나 하드웨어 디코딩으로 전환했을 때 실시간 속도가 회복된다면 CPU 작업이 원인일 가능성이 높습니다. 다른 컨테이너를 중지했을 때 회수 또는 스왑이 사라진다면 메모리 압박이 더 유력한 설명입니다.

네트워크와 스토리지는 경로별로 테스트해야 합니다

업로드가 포화되면 호스트 CPU에 여유가 있어도 원격 재생에서 버퍼링이 발생할 수 있습니다. 순차 처리량이 충분해 보여도 스토리지 지연 시간은 시작, 탐색, 메타데이터 처리 및 트랜스코딩 임시 작업을 지연시킬 수 있습니다. 클라이언트가 실제로 사용하는 경로를 테스트하세요.

처리량과 별도로 스토리지 지연 시간과 처리량을 측정하고, 경쟁 전송을 일시 중지한 상태에서 동일한 스트림을 비교하세요.

증상이 대기열 깊이 또는 업로드 사용률에 따라 나타난다면 CPU나 RAM을 변경해도 문제가 해결되지 않습니다. 경로가 유휴 상태가 된 뒤에도 증상이 지속된다면 클라이언트 호환성 또는 연산 리소스를 확인하세요.

-15% OFF