Jellyfin 호스트 하나에서 지원할 수 있는 사용자와 백그라운드 작업은 몇 명, 몇 개일까요?

에바 왕

IceWhale author

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

How Many Users and Background Jobs Should One Jellyfin Host Support? - Zima Store Online

Jellyfin 호스트는 등록된 사용자 수만으로 사양을 정해서는 안 됩니다. 계정이 8개인 한 가정이 백그라운드에서 라이브러리 스캔, 자막 작업, 백업을 실행하면서 4K 동영상을 트랜스코딩하는 원격 시청자 2명보다 부하를 적게 만들 수도 있습니다. 유용한 용량 판단 기준은 재생이나 관리 작업이 목표 수준을 충족하지 못하기 전에 호스트가 얼마나 많은 동시 포그라운드 및 백그라운드 작업을 처리할 수 있는지입니다.

재생 세션, 트랜스코딩, 예약 작업, 스토리지 활동, 함께 실행되는 서비스를 모두 포함하는 하나의 워크로드 예산을 세우세요. 그런 다음 일반적인 최대 동시 작업 상황을 테스트하고, 공유 리소스 중 처음으로 지속적인 대기열, 오류 또는 사용자가 체감할 수 있는 지연이 발생하는 리소스에서 부하 증가를 멈추세요.

사용자를 재생 워크로드로 변환하기

Direct Play, 리먹스, 오디오 변환, 비디오 트랜스코딩 세션을 각각 따로 집계하세요. Jellyfin 클라이언트는 지원 코덱, 해상도, 비트레이트, 제약 조건을 보고하므로, 같은 소스를 시청하는 두 사용자라도 서버에 매우 다른 작업을 요청할 수 있습니다.

Jellyfin 사용자 정책도 서버 부하를 바꿀 수 있습니다. 현재 사용자 관리 설정에서는 원격 액세스, 미디어 재생, 트랜스코딩, 스트림별 인터넷 비트레이트를 허용하거나 제한할 수 있습니다. 따라서 사용자 수는 같은 시간에 예상되는 재생 권한과 모드로 변환한 뒤에야 유용한 기준이 됩니다.

이론적인 최대 계정 수가 아니라 가장 부하가 큰 일반적인 저녁 상황부터 시작하세요. 가정에서 보통 로컬 Direct Play 세션 2개와 원격 변환 1개를 동시에 사용한다면, 호스트는 이 구성을 여유 있게 처리할 수 있어야 합니다.

예약 작업을 동일한 용량 예산에 포함하기

Jellyfin은 아무도 재생 버튼을 누르지 않을 때도 작업을 수행합니다. 라이브러리 스캔, 자막 다운로드, 캐시 정리, 플러그인 업데이트, 챕터 이미지 추출, 데이터베이스 최적화, 생성 미디어 작업은 시청과 겹칠 수 있습니다.

현재 예약 작업 목록을 보면 Jellyfin이 백그라운드에서 스캔, 이미지 추출, 플러그인 업데이트, 데이터베이스 유지 관리, 자막 작업, 캐시 정리 및 기타 작업을 실행할 수 있음을 알 수 있습니다. 플러그인이 추가 작업을 등록할 수도 있습니다.

조용한 재생 벤치마크만으로 서버 사양을 정한 뒤 모든 무거운 작업을 같은 피크 시간에 실행하지 마세요. 먼저 미뤄도 되는 작업을 시청 시간대 밖으로 옮기고, 겹칠 수밖에 없는 작업은 실제 운영 환경 테스트에 포함하세요.

여유가 먼저 사라지는 공유 리소스 찾기

호스트는 미디어 엔진 처리량, CPU, 메모리, SSD 지연 시간, HDD 탐색 부하, 네트워크 대역폭 또는 종속성 때문에 문제를 일으킬 수 있습니다. 원격 업로드 회선이 포화된 경우 CPU 코어를 늘려도 도움이 되지 않으며, 선택한 GPU가 트랜스코딩을 가속하지 못한다면 RAM을 늘려도 해결되지 않습니다.

ZimaSpace의 소형 홈 서버의 Jellyfin 용량 분석도 동일한 워크로드 우선 모델을 사용합니다. 계정 수의 상한선보다 동시 수요와 처음 포화되는 리소스가 더 중요합니다.

정확히 같은 작업이 겹치는 동안 트랜스코딩 속도, CPU 또는 미디어 엔진 포화도, 메모리 압박, 스토리지 지연 시간, 네트워크 처리량을 측정하세요. 장애와 함께 부하가 변하고 해당 부하를 제거했을 때 개선되는 리소스가 제한 리소스입니다.

-15% OFF

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

Single board computer zimaboard2

백그라운드 작업이 대화형 작업 여유를 소모하지 않게 하기

재생에는 기한이 있습니다. 클라이언트 버퍼가 비기 전에 다음 세그먼트가 도착해야 합니다. 반면 라이브러리 스캔은 대개 나중에 완료되어도 문제가 없습니다. 이러한 차이를 바탕으로 일정과 리소스 정책을 정해야 합니다.

필수 백그라운드 작업이 계속 실행되는 동안에도 일반적인 재생 시작이나 탐색이 즉시 반응할 수 있도록 충분한 여유를 확보하세요. 데이터베이스 최적화나 미디어 분석 작업 때문에 버퍼링이 발생한다면 더 큰 서버를 구입하기 전에 작업 일정을 바꾸거나 해당 작업을 제한하세요.

공유 호스트에서는 다른 컨테이너가 활성화된 상태로 테스트를 반복하세요. 다운로드 프로그램, 사진 인덱서, 백업 엔진 또는 로컬 AI 프로세스는 Jellyfin 자체의 워크로드가 변하지 않아도 Jellyfin의 처리 용량을 줄일 수 있습니다.

사용자 제한 대신 워크로드 매트릭스 사용하기

동시 작업	주요 모니터링 리소스	장애 신호
Direct Play 스트림	미디어 스토리지 + 네트워크	읽기 또는 네트워크 대기열 증가
비디오 트랜스코딩	미디어 엔진 / CPU + 임시 작업 공간	트랜스코딩 속도가 실시간보다 느려짐
라이브러리 스캔	CPU + 메타데이터 스토리지 + 미디어 디스크	탐색 또는 재생 지연 시간 증가
이미지 / 트릭플레이 생성	CPU/GPU + 스토리지 쓰기	대화형 작업의 여유 감소
백업 또는 가져오기	스토리지 + 네트워크	I/O 경합 또는 업로드 포화

용량은 “대표 스트림 3개와 예약 스캔 1개를 함께 실행해도 목표 범위 안에 있음”처럼 테스트한 워크로드로 제시하세요. “이 서버는 사용자 10명을 지원함”이라고 표현하지 마세요. 이렇게 하면 라이브러리, 클라이언트, 가정의 사용 방식이 바뀌어도 결과를 재현할 수 있습니다.