Por qué las lecturas y escrituras de Plex generan cargas de servidor diferentes

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Why Plex Reads and Writes Create Different Server Loads - Zima Store Online

Plex lee y escribe en partes diferentes de un servidor doméstico porque las transferencias grandes de contenido multimedia y las pequeñas actualizaciones de estado tienen patrones de E/S muy distintos.

Una transmisión puede leer secuencialmente un archivo grande mientras Plex actualiza simultáneamente bases de datos, registros, metadatos o datos temporales mediante operaciones más pequeñas. Estas rutas pueden compartir un dispositivo y, aun así, responder de forma diferente a la carga. Mide por separado el rendimiento de lectura de contenido multimedia y la latencia de los datos de la aplicación antes de decidir que el «uso del disco» es la causa.

Las lecturas de contenido multimedia suelen estar orientadas al rendimiento

La reproducción directa extrae grandes cantidades contiguas de datos multimedia y necesita principalmente un rendimiento sostenido con suficiente margen para las transmisiones simultáneas. La latencia de búsqueda es menos importante que en una base de datos llena de registros pequeños.

Un almacenamiento más rápido solo ayuda cuando su latencia, capacidad y perfil de transacciones se ajustan a la carga de trabajo; los compromisos del almacenamiento de datos activos hacen que el patrón de acceso sea más útil que la velocidad nominal del dispositivo por sí sola.

Mide el rendimiento de lectura agregado del contenido multimedia durante la combinación de transmisiones más exigente. Si se mantiene muy por debajo de la capacidad del dispositivo y de la red, trasladar únicamente el contenido multimedia a una memoria flash más rápida probablemente no resolverá un retraso de metadatos o de la base de datos.

Las escrituras de datos de la aplicación son más sensibles a la latencia

Las transacciones de la base de datos, las actualizaciones de ilustraciones, los registros y los metadatos generan escrituras más pequeñas que pueden quedar a la espera de la sincronización, el journaling o las E/S aleatorias en competencia. Su coste visible puede ser elevado aunque el total de MB/s sea bajo.

Linux puede acumular y vaciar páginas modificadas en ráfagas, por lo que la escritura diferida puede separar el momento en que Plex escribe del momento en que el dispositivo muestra un pico.

Controla de forma independiente la latencia, la profundidad de cola, la memoria modificada y el dispositivo de datos de la aplicación respecto al dispositivo de contenido multimedia. Una carga de trabajo de escrituras pequeñas con alta latencia es un problema distinto de una lectura secuencial de contenido multimedia que satura el dispositivo.

Las lecturas y escrituras simultáneas pueden interferir

Colocar el estado de la base de datos, el contenido multimedia, las copias de seguridad y los descargadores en un solo dispositivo permite que patrones de acceso no relacionados compitan por la misma cola. Una unidad rápida de forma aislada puede parecer inestable cuando estas tareas se superponen.

El rendimiento de la base de datos cambia tanto con la velocidad del almacenamiento como con la combinación de cargas de trabajo, y el comportamiento de las bases de datos sensible a las E/S es una de las razones para probar la carga combinada en lugar de extrapolar a partir de una única prueba de copia de archivos.

Repite una acción lenta de Plex con las copias de seguridad y los procesos de escritura de gestión de contenido multimedia en pausa. Si la latencia se desploma, separa las funciones de temporización o almacenamiento antes de reemplazar todo el servidor.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

La separación de funciones hace visible el cuello de botella

Una topología bien definida asigna al estado persistente de Plex, al contenido multimedia masivo, al trabajo temporal y a las copias de seguridad funciones distintas de rendimiento y recuperación, incluso cuando algunos comparten hardware físico. Esto hace que las pruebas posteriores sean interpretables.

Separar las funciones también facilita atribuir la saturación de recursos al dispositivo o la ruta que realmente realiza el trabajo, en lugar de atribuirla al almacenamiento como un conjunto indiferenciado.

Vuelve a realizar las pruebas después de cada cambio de función y conserva únicamente los cambios que desplacen el cuello de botella medido. En una topología de servidor multimedia doméstico, el estado, el contenido multimedia, el trabajo temporal y las copias de seguridad deben mantenerse lo bastante separados como para poder medirlos de forma independiente.