라이브러리가 커질수록 Jellyfin 시작이 느려지는 이유

라이브러리가 커질수록 더 많은 영속 레코드, 데이터베이스 페이지, 메타데이터와 캐시 상태를 다시 열거나 처리해야 하므로 Jellyfin 시작 시간이 길어질 수 있습니다.

미디어 컬렉션이 커진다고 해서 모든 시작 단계가 선형적으로 증가하는 것은 아니며, 테라바이트 수는 항목 수, 메타데이터 관계, 데이터베이스 크기, 대기 중인 유지 관리 작업보다 중요하지 않은 경우가 많습니다. 유용한 질문은 어떤 시작 단계가 증가하는지입니다. 영속 상태 열기, 마이그레이션 실행, 라이브러리 검증, 캐시 예열, 스토리지와 종속 서비스가 응답 가능해질 때까지 대기 중 어느 단계일까요?

라이브러리 증가는 단순한 미디어 용량이 아니라 영속 상태를 확장합니다

Jellyfin은 일반적인 시작 때마다 비디오 바이트에서 전체 미디어 라이브러리를 다시 구축하지 않습니다. 하지만 카탈로그가 커지면 데이터베이스 행, 제공자 ID, 인물 정보, 아트워크 참조, 사용자 상태 관계, 파일 시스템 경로가 늘어나는 것이 일반적입니다. 이러한 구조는 열고 조회해야 하는 영속 상태를 확장하므로, 미디어 디스크에 충분한 순차 처리량이 있어도 시작 동작이 달라질 수 있습니다.

카탈로그 크기와 미디어 용량의 차이는 Jellyfin 10.11의 마이그레이션 설계에서 확인할 수 있습니다. 이 설계에서는 미디어 파일 자체를 복사하는 대신 데이터베이스 구조 내부에서 라이브러리 데이터를 이동하고 중복 제거했습니다. 라이브러리 데이터베이스 변환은 NAS에 저장된 전체 테라바이트 수보다 레코드 수와 스키마 작업이 시작 시간에 더 큰 영향을 줄 수 있는 이유를 보여 줍니다.

다만 라이브러리 증가만으로 원인을 단정할 수는 없습니다. 작은 데이터베이스라도 연결이 끊긴 네트워크 마운트나 손상된 플러그인을 기다리면 시작이 느릴 수 있고, 매우 큰 데이터베이스라도 빠른 로컬 스토리지에서 유지 관리 작업이 없다면 시작 시간이 예측 가능하게 유지될 수 있습니다. 원시 미디어 용량과 데이터베이스 및 메타데이터 상태를 따로 측정하세요.

데이터베이스 페이지와 인덱스는 콜드 작업 집합을 늘립니다

데이터베이스가 커지면 시작 쿼리와 초기 라이브러리 요청을 처리하는 데 더 많은 페이지가 필요할 수 있습니다. 콜드 프로세스에는 해당 페이지가 자체 메모리에 없고, 콜드 호스트에는 파일 시스템 캐시에도 없을 수 있습니다. 따라서 자주 사용하는 카탈로그 일부가 메모리에 상주하고 이후 조회에서 재사용될 때까지 서버는 더 많은 물리적 읽기를 수행합니다.

웜 캐시 동작은 이 효과를 확인하는 기준을 제공합니다. 메타데이터와 페이지를 가져와야 하므로 첫 접근은 느릴 수 있지만, CPU, 디스크 또는 네트워크 하드웨어의 변화가 없어도 반복 접근은 더 빨라집니다. 따라서 콜드 시작 시간과 웜 상태의 안정적인 성능은 하나의 안정적인 수치를 측정한 두 표본이 아니라 별개의 측정값으로 봐야 합니다.

활성 작업 집합이 메모리에 계속 상주할 수 없을 때 문제가 나타납니다. 메모리 압박, 엄격한 컨테이너 제한, 경쟁 서비스로 인해 유용한 페이지가 반복적으로 축출되면 모든 탐색이 콜드 시작처럼 보일 수 있습니다. 이 경우 라이브러리 크기가 영향을 주는 방식은 Jellyfin이 시작 때 모든 항목을 의도적으로 다시 스캔해서가 아니라 메모리 압박을 통해서입니다.

주요 업데이트는 라이브러리 크기를 마이그레이션 시간으로 바꿀 수 있습니다

대부분의 일반적인 재시작에는 스키마를 다시 작성할 필요가 없지만, 주요 릴리스에서는 기존 상태의 양에 따라 비용이 달라지는 일회성 변환이 추가될 수 있습니다. 따라서 대규모 카탈로그에서는 업데이트 직후의 시작이 이후 열 번의 시작보다 훨씬 느릴 수 있습니다. 이 한 번의 마이그레이션을 영구적인 시작 시간의 기준으로 삼으면 라이브러리 증가의 장기적인 영향을 과대평가하게 됩니다.

Jellyfin은 10.11 초기 업그레이드에서 라이브러리 크기와 상태에 따라 마이그레이션이 몇 시간까지 걸릴 수 있다고 명시적으로 경고했습니다. 이 크기에 따라 달라지는 마이그레이션 시간은 업그레이드 시작과 일반 시작을 구분해야 한다는 강력한 증거입니다. 새로운 영속 상태가 성공적으로 커밋된 후에는 동일한 서버가 전체 변환을 반복해서 수행해서는 안 되기 때문입니다.

판단 기준은 반복성입니다. 모든 재시작이 동일하게 긴 마이그레이션으로 시작되는 것처럼 보인다면 로그를 보존하고, 서비스가 의도한 영속 디렉터리를 다시 열고 있는지 확인하세요. 지연을 정상적인 확장 현상으로 간주해서는 안 됩니다. 유한한 일회성 작업은 예상할 수 있지만, 동일한 마이그레이션 작업이 반복된다면 영속성, 롤백 또는 오류 상태에 문제가 있을 가능성이 큽니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

작은 작업이 늘어날수록 스토리지 지연 시간이 중요해집니다

라이브러리가 커지면 소규모 데이터베이스 및 메타데이터 작업의 양이 증가하는 경향이 있어 액세스 지연 시간이 더 뚜렷해집니다. HDD는 대규모 순차 미디어 읽기에 여전히 적합하지만, 애플리케이션 상태는 더 작고 비순차적인 작업으로 구성됩니다. 따라서 시작 중 접근하는 페이지나 파일 수가 조금만 늘어나도 지연 시간이 짧은 로컬 스토리지와 느린 기계식 또는 원격 경로의 차이가 커질 수 있습니다.

Jellyfin 자체의 스토리지 모델은 Jellyfin 파일에 SSD를 사용할 것을 권장합니다. 해당 파일은 무작위 액세스가 많기 때문이며, 미디어 스토리지는 주로 순차 속도의 제약을 받습니다. 애플리케이션 상태 스토리지 지침은 데이터베이스와 메타데이터만 지연 시간이 낮은 계층으로 옮겨도 대규모 미디어 라이브러리 전체를 이동하지 않고 시작 및 탐색 성능을 바꿀 수 있는 이유를 설명합니다.

판단 기준은 드라이브 종류가 아니라 측정된 대기열입니다. 지속적으로 쓰기 작업을 수행하는 다른 서비스와 SSD를 공유하면 SSD도 멈출 수 있고, 작고 웜 상태인 애플리케이션 데이터라면 HDD로 충분할 수 있습니다. 용량 증가에 따라 스토리지 기술을 자동으로 바꾸기 전에 동일한 라이브러리에서 시작 I/O 지연 시간과 대기열 깊이를 비교하세요.

서버가 너무 작다고 판단하기 전에 시작을 단계별로 측정하세요

다섯 개의 시점을 기록하세요. 프로세스 시작, 영속 데이터베이스 열기, 마이그레이션 또는 유지 관리 완료, 사용 가능한 웹 인터페이스 표시, 대표적인 첫 라이브러리 요청입니다. 업그레이드가 예정되지 않은 상태에서 한 번은 콜드 상태로, 한 번은 정상적인 재시작 후에 테스트를 반복하세요. 데이터베이스 크기, 여유 메모리, 스토리지 지연 시간도 함께 기록하면 증가한 단계와 리소스의 관계를 라이브러리 크기라는 추상적인 표현이 아니라 구체적인 자원으로 연결할 수 있습니다.

리소스 포화 프레임워크는 결과를 해석하는 데 도움이 됩니다. CPU 실행 대기열, 메모리 압박, 스토리지 지연 시간 또는 네트워크 대기는 자신이 제한하는 단계와 함께 증가해야 합니다. 모든 로컬 리소스가 정상인데 시작 시간만 증가한다면 하드웨어를 구매하거나 라이브러리를 이전하기 전에 종속 서비스의 준비 상태와 애플리케이션 로그를 확인하세요.

일반적인 시작이 안정적이고, 마이그레이션이 한 번 완료되며, 첫 번째 웜 요청이 예상 기준 시간으로 돌아온다면 현재 호스트를 계속 사용해도 됩니다. 반복 측정에서 동일한 단계가 증가하고 해당 리소스가 지속적으로 포화될 때 스토리지 위치나 용량을 재검토하세요. 반대로 시작 과정에서 무결성 오류, 누락된 마운트 또는 새 서버처럼 보이는 상태가 보고된다면 데이터를 변경하기 전에 중단하세요.