단일 호스트에서 Jellyfin 라이브러리는 얼마나 커질 수 있나요?

한 호스트가 “가득 찼는지”를 알려 주는 유용한 Jellyfin 항목 수의 보편적인 상한선은 없습니다. 실제 한계는 데이터베이스, 메모리, 스토리지, 예약 작업 또는 동시 재생이 더 이상 목표 응답 시간을 충족하지 못하는 지점입니다.

영화 수가 같은 두 라이브러리라도 메타데이터 밀도, 챕터 이미지, 트릭플레이 데이터, 네트워크 스토리지, 클라이언트 구성, 트랜스코딩 요구 사항이 다르기 때문에 서버에 가하는 부하는 크게 다를 수 있습니다. 실제 워크로드에서 호스트를 측정하고, 라이브러리를 크게 확장할 때마다 반복 측정할 수 있는 경계를 정하세요.

미디어 파일 수가 아니라 데이터베이스 용량부터 확인하세요

Jellyfin은 라이브러리 상태를 데이터베이스에 저장하고 미디어 파일은 파일 시스템에 그대로 둡니다. 카탈로그가 커질수록 가장 먼저 확인할 지표는 영화 파일의 총 테라바이트 용량이 아니라 Jellyfin 데이터 세트의 크기와 동작입니다.

Jellyfin의 스토리지 문서에 따르면 중간 규모 라이브러리의 데이터베이스는 약 10~100GB까지 커질 수 있으며, 데이터베이스는 네트워크 공유가 아닌 로컬 스토리지에 보관하는 것이 좋습니다. 데이터베이스 스토리지 안내

데이터베이스 크기, 데이터 볼륨의 여유 공간, 캐시가 예열된 후 대규모 라이브러리 화면을 열거나 검색하는 데 걸리는 시간을 기록하세요. 미디어 용량이 늘어나는 동안에도 이 값들이 안정적이라면, 미디어의 원시 용량만으로 단일 호스트의 한계를 넘은 것은 아닙니다.

데이터베이스가 예열된 후 메모리 여유를 측정하세요

현재 Jellyfin 릴리스에서는 디스크 읽기를 줄이기 위해 서버가 많은 양의 데이터베이스 정보를 메모리에 보관할 수 있으므로 메모리 동작이 더욱 중요합니다. 따라서 더 작은 카탈로그에서는 여유로워 보였던 호스트도 라이브러리가 커진 후 더 높은 정상 상태 RAM 사용량을 보일 수 있습니다.

Jellyfin 10.11 릴리스 노트에 따르면 데이터베이스 엔진은 메타데이터를 메모리에 적극적으로 캐시하며, 라이브러리 데이터베이스 크기만큼 메모리를 사용할 수 있고 다른 프로세스가 메모리를 필요로 하면 메모리를 반환합니다. 메모리 내 데이터베이스 캐싱

일상적인 탐색으로 캐시를 예열한 후 사용 가능한 메모리와 스왑 활동을 확인하세요. 캐시 사용량 자체가 높은 것은 경고 신호가 아닙니다. 지속적인 메모리 압박, 스와핑, 또는 Jellyfin이 다른 컨테이너와 경쟁할 때 나타났다가 경쟁이 사라지면 없어지는 지연 시간이 실제 경고 신호입니다.

라이브러리와 함께 늘어나는 백그라운드 작업 시간을 측정하세요

재생이 원활하더라도 라이브러리 스캔, 메타데이터 새로 고침, 이미지 추출, 자막 작업 및 기타 예약 작업이 가장 먼저 확장성의 한계가 될 수 있습니다. 이러한 작업이 얼마나 오래 실행되는지, 그리고 실제 사용 시간과 겹치는지 측정하세요.

챕터 이미지 추출은 Jellyfin이 직접적인 확장 비용을 설명하는 한 가지 사례입니다. 라이브러리 스캔 중 추출을 활성화하면 특히 대규모 라이브러리에서 스캔 속도가 크게 느려질 수 있습니다. 챕터 이미지 스캔 비용

전체 스캔이 이제 유지 관리 시간의 대부분을 차지한다면 먼저 불필요한 작업을 줄이거나 비용이 큰 작업을 사용량이 많은 시간대 외부로 옮기세요. 스캔 시간이 길어졌다고 해서 호스트의 성능이 자동으로 부족한 것은 아닙니다. 유지 관리 작업이 대화형 사용과 반복적으로 충돌하거나 안정적으로 완료되지 않을 때 용량 문제가 됩니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

라이브러리 규모와 트랜스코딩 규모를 분리해서 판단하세요

대규모 카탈로그라고 해서 직접 재생 스트림에 반드시 큰 비용이 드는 것은 아니며, 반대로 작은 카탈로그라도 호환되지 않는 클라이언트 여러 대가 비디오 트랜스코딩을 요청하면 CPU에 과부하가 걸릴 수 있습니다. 카탈로그 규모와 재생 변환을 별도의 용량 테스트로 다루세요.

실제로 사용하는 클라이언트 구성으로 반복 가능한 재생 벤치마크를 실행하세요. 직접 재생 스트림 하나, 일반적인 트랜스코딩 하나, 그리고 예상되는 동시 접속 최대치 순으로 테스트합니다. 카탈로그가 커져도 이러한 재생 테스트 결과가 변하지 않는다면 라이브러리 크기 때문에 트랜스코딩 한계에 도달한 것은 아닙니다.

트랜스코딩 중에만 CPU 포화가 나타난다면 데이터베이스를 탓하기 전에 코덱, 하드웨어 가속 또는 클라이언트 호환성을 조정하세요. 건강한 메타데이터 데이터베이스를 두 번째 서버로 옮기는 것보다 하드웨어 가속 안내를 먼저 확인하는 편이 더 적절합니다.

스캔 부하가 걸린 상태에서 스토리지 지연 시간과 미디어 접근성을 확인하세요

대규모 라이브러리는 여러 디스크나 NAS에 분산되는 경우가 많으므로 미디어에 접근하는 경로가 제한 요소가 될 수 있습니다. 라이브러리 스캔을 실행할 때와 실행하지 않을 때의 대화형 탐색 및 재생을 비교하고, 미디어 경로의 디스크 대기열 또는 네트워크 공유 지연 시간을 확인하세요.

Jellyfin은 Samba 또는 NFS 스토리지를 운영 체제에 직접 마운트할 것을 권장하며, 예약된 유지 관리 작업이 실행될 때 스토리지를 사용할 수 없으면 라이브러리 항목이 삭제될 수 있다고 경고합니다. 네트워크 스토리지 및 유지 관리 주의 사항

데이터베이스는 빠르지만 미디어 디렉터리가 간헐적으로 사라지거나 느린 공유 스토리지 때문에 메타데이터 스캔이 멈춘다면 CPU를 추가해도 실제 병목은 해결되지 않습니다. 먼저 마운트 안정성, 스토리지 지연 시간 또는 작업 일정을 개선한 다음 동일한 벤치마크를 다시 실행하세요.

반복 가능한 벤치마크로 나만의 단일 호스트 한계를 정하세요

다음 라이브러리 확장 전에 간단한 평가표를 만드세요. 캐시 예열 후 검색 지연 시간, 대규모 컬렉션을 여는 데 걸리는 시간, 전체 스캔 시간, 데이터베이스 크기, 사용 가능한 RAM, 스토리지 지연 시간 최대치, 대표적인 동시 재생 테스트 하나를 포함합니다. 매번 동일한 측정값을 사용하세요.

실용적인 홈 미디어 센터 워크플로에서는 이미 미디어 스토리지와 Jellyfin 애플리케이션 계층을 분리합니다. 벤치마크에서도 이 분리를 유지해야 속도 저하가 호스트, 스토리지 경로, 클라이언트 중 어디에서 발생했는지 파악할 수 있습니다.

낮은 위험도의 튜닝을 적용한 뒤에도 측정한 목표를 반복적으로 충족하지 못할 때만 단일 호스트의 규모가 한계에 도달했다고 판단하세요. 대화형 요청이 계속 느리거나, 유지 관리 시간 내에 스캔을 완료할 수 없거나, 메모리 압박으로 스와핑이 발생하거나, 스토리지 지연 시간을 분리해 해결할 수 없거나, 필요한 트랜스코딩이 사용 가능한 컴퓨팅 성능을 초과하는 경우가 이에 해당합니다. 그 시점에는 임의의 항목 수 기준을 정하기보다 어떤 리소스를 확장해야 하는지 측정 결과가 알려 줍니다.