업데이트 후 Jellyfin이 CPU를 많이 사용하는 이유는 무엇인가요?

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

업데이트 후 Jellyfin의 CPU 사용량이 높아지는 원인은 보통 네 가지 중 하나입니다. 시작 및 데이터베이스 작업, 예약된 라이브러리 작업, 소프트웨어 또는 부분 트랜스코딩, 새 버전에서 동작이 달라진 플러그인이나 백그라운드 작업이 원인일 수 있습니다. 어떤 프로세스와 작업이 CPU를 사용하고 있는지 확인하기 전에는 업데이트로 인해 Jellyfin이 영구적으로 더 무거워졌다고 단정하지 마세요.

가장 빠른 진단 방법은 시간과 작업량을 비교하는 것입니다. 시작 후 몇 분 동안만 CPU 사용량이 높다면 시작 및 작업 로그를 확인하세요. 재생 중에만 상승한다면 현재 스트림과 FFmpeg 경로를 살펴보세요. 아무도 시청하지 않을 때도 계속 높다면 예약된 작업과 플러그인을 확인하세요. 한 번에 하나의 변수만 변경한 다음 같은 조건을 재현해야 일시적인 업데이트 후 작업인지 지속적인 회귀 문제인지 구분할 수 있습니다.

시작 작업과 안정 상태의 CPU 사용량을 구분하세요

사용량이 적은 시간에 Jellyfin을 한 번 재시작하고 CPU 사용량이 얼마나 오래 높은 상태로 유지되는지 기록하세요. 서버 로그에서 마이그레이션, 데이터베이스 최적화, 플러그인 로드 또는 라이브러리 관련 메시지를 확인한 다음, 새 기준을 판단하기 전에 웹 인터페이스와 예약된 작업이 안정될 때까지 기다리세요.

Jellyfin의 기본 예약 및 시작 작업에는 라이브러리 스캔, 키 프레임 추출, 데이터베이스 최적화, 캐시 정리 및 플러그인 업데이트가 포함됩니다. 일부 작업은 시작할 때도 실행되므로 업데이트 후의 CPU 급증은 지속적인 성능 변화가 아니라 유지 관리 작업일 수 있습니다.

작업이 완료된 후 CPU 사용량이 이전의 유휴 범위로 돌아온다면 트랜스코딩을 조정하거나 하드웨어를 교체하지 마세요. 이 경우 일시적인 백그라운드 작업이 원인이라는 결론을 이미 내릴 수 있습니다. 대신 재생에 방해가 된다면 사용 시간이 아닌 시간대로 무거운 작업을 예약하세요.

이제 재생에 CPU가 사용되는지 확인하세요

특정 클라이언트가 재생을 시작할 때만 CPU가 급증한다면 Jellyfin 대시보드를 열고 세션이 Direct Play, 리먹싱, 오디오 트랜스코딩 또는 비디오 트랜스코딩 중 무엇인지 확인하세요. 클라이언트나 코덱이 변경되면서 이전에는 사용되지 않던 소프트웨어 경로가 활성화될 수 있습니다.

자막을 끈 상태에서 같은 클라이언트로 같은 미디어를 강제로 재생한 다음 CPU 사용량을 비교하세요. 사용량이 크게 줄어든다면 자막 또는 트랜스코딩 경로가 구분 요인입니다. Direct Play 중에도 사용량이 높다면 인코더를 탓하기보다 스토리지, 플러그인 또는 다른 프로세스를 살펴보세요.

재생을 더 자세히 확인하려면 하드웨어 트랜스코딩 확인에 설명된 방법을 사용하세요. 설정에서 하드웨어 가속이 활성화되어 있다고 믿는 대신 실제 GPU/FFmpeg 경로가 사용 중인지 확인해야 합니다.

호스트 부하를 추측하지 말고 컨테이너 프로세스를 측정하세요

공유 홈 서버에서는 실제로 CPU를 사용하고 있는 프로세스가 Jellyfin인지 확인하세요. 백업, 미디어 인덱서, 다운로드 클라이언트, 썸네일 생성기 및 파일 시스템 유지 관리 작업이 같은 재부팅 또는 업데이트 시점에 시작되었을 수 있습니다.

컨테이너 런타임은 컨테이너별 사용량을 확인할 수 있는 화면을 제공합니다. Docker의 stats 명령은 실행 중인 컨테이너의 실시간 리소스 사용량을 표시하도록 설계되었습니다. 문제를 재현하는 동안 컨테이너별 리소스 사용량 또는 플랫폼에 해당하는 기능을 사용하세요.

다른 컨테이너가 CPU를 사용하고 있다면 해당 작업을 일시 중지하고 원래 테스트를 다시 재생하세요. Jellyfin이 CPU를 사용한다면 Jellyfin 작업과 재생을 계속 확인하세요. 그렇지 않다면 업데이트는 호스트 부하와 시간적으로 연관되었을 뿐 원인은 아닙니다.

백그라운드 원인을 한 번에 하나씩 비활성화하거나 일정을 변경하세요

Jellyfin의 예약 작업 페이지에서 현재 실행 중이거나 반복적으로 다시 시작되는 작업을 확인하세요. 또한 자체 예약 작업, 메타데이터 제공자, 인트로 감지, 자막 처리 또는 기타 라이브러리 자동화를 추가하는 플러그인도 살펴보세요.

모든 플러그인과 작업을 한 번에 영구적으로 비활성화하지 마세요. 비용이 많이 드는 후보 하나를 일시 중지하고 CPU 사용량이 안정될 때까지 기다린 다음 동일한 유휴 또는 스캔 조건을 재현하세요. CPU 사용량이 명확히 감소하면 해당 원인 경로를 확인한 것입니다. 변화가 없다면 원래대로 복원하고 다음 후보를 테스트하세요.

작업 자체는 정상이지만 실행 시간이 적절하지 않다면 결함으로 간주하기보다 일정을 변경하세요. 업데이트 후 작업이 반복되거나 실패하거나 즉시 다시 시작된다면 데이터베이스 파일을 변경하거나 서버를 재구축하기 전에 로그와 플러그인/버전 정보를 보존하세요.

업데이트 후의 원래 부하에서 수정 사항을 확인하세요

원인을 파악한 후 그에 맞는 해결 방법을 적용하세요. 마이그레이션이 완료되도록 기다리거나, 작업 일정을 변경하거나, 하드웨어 가속을 복원하거나, 문제가 있는 플러그인을 업데이트 또는 비활성화하거나, 클라이언트/트랜스코딩 조건을 수정할 수 있습니다. 그런 다음 한 번 재시작하고 이전에 CPU 사용량을 높였던 동일한 테스트를 반복하세요.

성공적인 해결은 CPU 동작이 다시 작업량에 맞는 상태가 되는 것입니다. 시작 후 유휴 상태가 안정되고, Direct Play는 가볍게 유지되며, 필요한 트랜스코딩은 예상한 가속 경로를 사용해야 합니다. 트리거를 재현하지 않은 채 1분 동안 조용했다는 사실만으로는 충분하지 않습니다.

실행 중인 작업도 없고, 트랜스코딩도 없으며, 경쟁하는 컨테이너도 없고, 플러그인 기본 상태도 깨끗한데 CPU 사용량이 계속 높다면 추가 조사를 진행하세요. 이때 Jellyfin 버전, OS/아키텍처, 작업 상태 및 짧은 로그 구간을 수집하면 바쁜 시작 작업 하나만으로 일반화하지 않고 버전별 회귀 문제를 조사할 수 있습니다.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.