Plex가 CPU, 메모리, 스토리지 또는 네트워크 병목인지 테스트하는 방법

Plex의 병목은 가장 바쁜 그래프가 아니라, 여유가 반복적으로 줄어들면서 동일한 재생 또는 인터페이스 증상을 계속 유발하는 리소스입니다.

정확한 테스트는 파일 하나, 클라이언트 하나, 재생 모드 하나, 시간 구간 하나로 시작한 다음, 조건을 바꾸지 않고 CPU, 메모리, 스토리지, 네트워크를 측정하는 방식입니다. 사용률이 높다는 사실만으로는 근거가 약합니다. 어떤 리소스의 부하가 증상과 함께 증가하고, 해당 리소스에 대한 통제된 변경으로 원래 요청이 개선될 때에만 그 리소스를 주요 병목으로 볼 수 있습니다.

재현 가능한 Plex 작업 하나를 고정하세요

문제를 재현하는 가장 작은 요청을 선택하세요. 버퍼링이 발생하는 Direct Play 파일 하나, 처리가 뒤처지는 트랜스코딩 하나, 또는 멈추는 라이브러리 작업 하나가 될 수 있습니다. 이후 측정값이 동일한 작업을 설명할 수 있도록 클라이언트, 선택한 트랙, 화질, 네트워크 경로, 동시에 실행되는 백그라운드 작업을 고정하세요.

유용한 조사는 증상에서 시작한 뒤 각 하위 시스템을 순서대로 확인합니다. 일반적인 Linux 작업 흐름도 마찬가지로, 사용률이 높은 수치 하나를 정답으로 간주하지 않고 리소스 부하를 구분합니다.

느려진 시점과 수집한 지표의 시점을 기록하세요. 실행할 때마다 증상이 나타나는 시점이 달라지거나 사라진다면, 반복될 때까지 작업을 단순화하세요. 그렇지 않으면 한 작업에서 발생한 디스크 급증을 다른 작업 때문에 발생한 Plex 지연과 잘못 연결할 수 있습니다.

CPU 부하와 메모리 부하를 구분하세요

CPU 부하는 Plex 프로세스 또는 트랜스코더가 지속적으로 연산을 수행하는 동안 작업이 뒤처질 때 가장 뚜렷하게 나타납니다. 메모리 부하는 다릅니다. 사용 가능한 메모리가 줄고, 회수 작업이 늘거나, 스와핑이 발생하면서 CPU가 완전히 포화되지 않았는데도 응답 시간이 악화될 수 있습니다.

top과 vmstat 같은 도구는 이러한 경로를 구분하는 데 도움이 됩니다. CPU와 메모리는 서로 다른 지표가 필요하기 때문입니다. 실행 대기열, CPU 시간, 여유 또는 가용 메모리, 페이징, 스왑 활동은 서로 고립된 스크린샷이 아니라 동일한 Plex 이벤트와 함께 해석해야 합니다.

한 가지 경로만 변경하세요. 선택적 소프트웨어 트랜스코딩을 제거하거나 검증된 가속 경로를 활성화해 연산 능력을 테스트하고, 메모리를 많이 사용하는 서비스를 일시 중지하거나 임시로 여유 공간을 늘려 메모리를 테스트할 수 있습니다. 원래 Plex 증상이 예상한 방향으로 변할 때에만 해당 리소스가 확인된 것입니다.

동일한 요청으로 스토리지 지연 시간과 처리량을 테스트하세요

스토리지 풀에 여유 용량이 충분해도 스토리지가 한계가 될 수 있습니다. Plex는 미디어 읽기, 메타데이터, 데이터베이스 작업 또는 트랜스코딩 임시 공간을 기다릴 수 있으며, 다른 작업이 대기열을 만들 수도 있습니다. 비교해야 할 대상은 정상 실행과 실패한 실행에서 동일한 미디어 경로를 사용하는 경우입니다.

디스크 진단에는 처리량뿐 아니라 지연 시간과 대기열 동작도 포함해야 합니다. 실용적인 I/O 모니터링은 장치 지연 시간, 사용률, 대기열 깊이를 확인해 초당 메가바이트 수치가 높지 않아도 요청이 대기 중인지 보여줍니다.

경쟁 중인 백업을 일시 중지하거나 클라이언트를 변경하지 않은 상태에서 테스트 파일을 속도가 검증된 로컬 경로로 복사하세요. CPU, 메모리, 네트워크가 비슷하게 유지되는 동안 동일한 Plex 요청이 복구된다면, 스토리지는 단순한 의심 대상에서 통제된 결과로 바뀝니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

서버와 네트워크를 독립적으로 테스트하세요

CPU와 스토리지가 정상이어도 실제 경로가 미디어 전송률을 감당하지 못하면 Direct Play 세션에서 버퍼링이 발생할 수 있습니다. 가능하면 원격 전송보다 먼저 로컬 유선 전송을 테스트한 다음, Plex가 작업과 측정 도구를 동시에 맡지 않도록 경로를 독립적으로 측정하세요.

처리량이 떨어지고, 손실 또는 재전송이 증가하거나, 서버 리소스에 여유가 남아 있는데 지연 시간이 불안정해질 때 네트워크 병목을 유력하게 볼 수 있습니다. 단일 사용률 스냅샷으로 판단하는 대신 부하가 영향과 상관관계를 보일 때 해당 리소스가 병목일 가능성이 더 높습니다.

독립적인 유선 경로에 충분한 여유가 있는데도 Plex가 계속 실패한다면 연산 또는 스토리지로 돌아가세요. 동일한 시간 구간에 경로 자체가 붕괴한다면 트랜스코더, 데이터베이스 또는 메모리 할당을 변경하기 전에 취약한 구간을 먼저 해결하세요.

의심되는 리소스 하나를 변경하고 반복하세요

마지막 단계는 대시보드를 다시 검토하는 것이 아니라 원인을 가려내는 테스트입니다. 가장 강력한 근거가 있는 리소스를 선택하고 해당 경로에만 영향을 줄 수 있는 되돌릴 수 있는 변경을 하나 수행하세요. 백업을 일시 중지하거나, 경쟁 중인 컨테이너의 리소스를 줄이거나, 로컬 유선 클라이언트를 사용하거나, 강제 변환을 제거하는 방법이 있습니다.

Plex의 재생 모드가 중요한 이유는 Direct Play, Direct Stream, 트랜스코딩이 서버에 서로 다른 부하를 주기 때문입니다. 호환성에 따라 미디어 경로가 달라지므로, 클라이언트나 화질을 변경하면 동일한 파일에서도 병목 지점이 바뀔 수 있습니다.

한 번의 변경 후 원래 작업을 반복하고 증상과 리소스 신호를 모두 비교하세요. Plex에 특화된 후속 내용이 필요하다면, CPU, 메모리, 스토리지, 네트워크 테스트를 통해 실제로 실패한 리소스에 수리 단계를 연결할 수 있습니다.