Plex 읽기와 쓰기가 서버에 서로 다른 부하를 발생시키는 이유

Plex는 대용량 미디어 전송과 소규모 상태 업데이트의 I/O 패턴이 매우 다르기 때문에 홈 서버의 서로 다른 부분에 부하를 줍니다.

스트리밍 중에는 대용량 파일을 순차적으로 읽는 동시에 Plex가 데이터베이스, 로그, 메타데이터 또는 임시 데이터를 더 작은 작업 단위로 업데이트할 수 있습니다. 이러한 경로는 하나의 장치를 공유하면서도 부하에 다르게 반응할 수 있습니다. “디스크 사용량”이 원인이라고 판단하기 전에 미디어 처리량과 앱 데이터 지연 시간을 별도로 측정하세요.

미디어 읽기는 대개 처리량 중심입니다

직접 재생은 연속된 대용량 미디어 데이터를 읽으므로, 여러 스트림을 동시에 처리할 수 있는 여유를 갖춘 지속적인 처리량이 주로 필요합니다. 작은 레코드가 가득한 데이터베이스만큼 탐색 지연 시간이 중요하지는 않습니다.

더 빠른 스토리지는 지연 시간, 용량, 트랜잭션 특성이 워크로드에 맞을 때만 도움이 됩니다. 활성 데이터 스토리지의 트레이드오프를 고려하면 장치의 명목상 속도만 보는 것보다 액세스 패턴을 파악하는 편이 더 유용합니다.

가장 많은 스트림이 재생되는 동안 전체 미디어 읽기 처리량을 측정하세요. 처리량이 장치와 네트워크 용량보다 훨씬 낮게 유지된다면, 미디어만 더 빠른 플래시 스토리지로 옮겨도 메타데이터나 데이터베이스 지연이 해결될 가능성은 낮습니다.

앱 데이터 쓰기는 지연 시간에 더 민감합니다

데이터베이스 트랜잭션, 아트워크 업데이트, 로그, 메타데이터는 동기화, 저널링 또는 경쟁하는 랜덤 I/O 때문에 대기할 수 있는 소규모 쓰기를 발생시킵니다. 총 MB/s가 낮더라도 이러한 작업의 체감 비용은 클 수 있습니다.

Linux는 더티 페이지를 모아 한꺼번에 플러시할 수 있으므로 지연된 쓰기백으로 인해 Plex가 쓰는 시점과 장치에 스파이크가 나타나는 시점이 달라질 수 있습니다.

미디어 장치와 앱 데이터 장치를 분리해 지연 시간, 큐 깊이, 더티 메모리, 앱 데이터 장치의 상태를 추적하세요. 지연 시간이 높은 소규모 쓰기 워크로드는 포화된 순차 미디어 읽기와는 다른 문제입니다.

동시 읽기와 쓰기는 서로 간섭할 수 있습니다

데이터베이스 상태, 미디어, 백업, 다운로드 작업을 하나의 장치에 배치하면 서로 관련 없는 액세스 패턴이 동일한 큐를 두고 경쟁하게 됩니다. 단독으로는 빠른 드라이브도 이러한 작업이 겹치면 성능이 불안정하게 느껴질 수 있습니다.

데이터베이스 성능은 스토리지 속도와 워크로드 구성 모두에 따라 달라집니다. I/O에 민감한 데이터베이스 동작 때문에 단일 파일 복사 벤치마크에서 성능을 추정하기보다 결합된 워크로드를 테스트해야 합니다.

백업과 미디어 관리 쓰기 작업을 일시 중지한 상태에서 느린 Plex 작업을 다시 실행하세요. 지연 시간이 급격히 줄어든다면 전체 서버를 교체하기 전에 작업 시점이나 스토리지 역할을 분리하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

역할을 분리하면 병목이 드러납니다

깔끔한 토폴로지는 일부 역할이 물리적 하드웨어를 공유하더라도 Plex의 영구 상태, 대용량 미디어, 임시 작업, 백업에 서로 다른 성능 및 복구 역할을 부여합니다. 덕분에 이후 테스트 결과를 해석하기 쉬워집니다.

역할을 분리하면 리소스 포화가 스토리지 전체가 아닌 실제 작업을 담당하는 장치나 경로의 문제인지 더 쉽게 파악할 수 있습니다.

역할을 변경할 때마다 다시 테스트하고, 측정된 병목을 개선하는 변경만 유지하세요. 홈 미디어 서버 토폴로지에서는 상태, 미디어, 임시 작업, 백업을 서로 구분할 수 있을 만큼 분리해 독립적으로 측정할 수 있어야 합니다.