Cómo afecta la ubicación de la base de datos a la fiabilidad y la recuperación de Plex

La fiabilidad de Plex suele mejorar cuando su base de datos activa y sus metadatos permanecen en un almacenamiento local de baja latencia, mientras que los archivos multimedia principales pueden estar en otro lugar.

Un servidor Plex puede transmitir películas desde discos duros grandes o almacenamiento en red, mientras sus datos de aplicación realizan muchas lecturas y escrituras pequeñas por una ruta diferente. Esta distinción es importante porque un archivo multimedia contiene principalmente datos secuenciales, mientras que la base de datos de la biblioteca, los metadatos, las miniaturas y los registros se comportan más como el estado de una aplicación. Piensa en la ubicación de la base de datos como una decisión de latencia y recuperación, no de capacidad.

Por qué la base de datos de Plex se comporta de forma diferente a los archivos multimedia

El directorio de datos de Plex contiene la base de datos de la biblioteca, además de metadatos, ilustraciones, cachés y otros datos del estado del servidor. Estos archivos se utilizan durante la navegación, los análisis, las tareas de metadatos, las actualizaciones del estado de reproducción y el mantenimiento, por lo que los picos de latencia en la ruta de datos de la aplicación pueden hacer que todo el servidor parezca poco fiable, incluso cuando los archivos de vídeo se leen rápidamente.

Plex mantiene el estado de la biblioteca al que se accede con frecuencia en una base de datos SQLite, por lo que la latencia y la integridad de la base de datos deben evaluarse por separado del rendimiento de la transferencia de archivos multimedia; ese es el punto de partida para establecer la ubicación y la recuperación de la base de datos.

El patrón observable es sencillo: si la navegación, las actualizaciones de la biblioteca y el inicio son lentos mientras la reproducción directa de un archivo ya abierto funciona correctamente, conviene prestar atención primero a la ruta de datos de la aplicación, antes que a los discos multimedia.

Mide la latencia y la recuperación, no solo el rendimiento

Las variables importantes son la latencia de E/S aleatoria, la estabilidad del sistema de archivos, el espacio libre, la durabilidad de las escrituras y el comportamiento de las copias de seguridad. El rendimiento secuencial máximo es secundario porque la base de datos no se comporta como una transmisión de vídeo grande.

Al medir la ubicación y la recuperación de la base de datos, una comprobación de cuellos de botella recurso por recurso debe revisar la utilización, la saturación y los errores de la CPU, la memoria, la red y el almacenamiento, en lugar de depender de una sola métrica promedio.

Si mover los datos de la aplicación reduce las pausas de inicio y de análisis sin cambiar el rendimiento de reproducción, has aislado un cuello de botella de metadatos/base de datos, no uno del almacenamiento multimedia.

Cuándo el almacenamiento más rápido deja de ayudar

Un SSD local no resuelve una transcodificación limitada por la CPU, un ancho de banda de subida saturado, códecs no compatibles con el cliente ni un disco multimedia que está fallando. Cuando la latencia de la base de datos es lo bastante baja como para que dominen estas otras etapas, añadir más IOPS al dispositivo de datos de la aplicación ofrece rendimientos decrecientes.

En el límite de fallo de la ubicación y la recuperación de la base de datos, cuando la corrupción es real, la recuperación es más segura si crea una base de datos SQLite nueva y limpia a partir de los datos recuperables, en lugar de modificar repetidamente el original dañado.

La prueba de este límite consiste en comparar la integridad y el espacio libre de la base de datos con el momento en que aparece el síntoma. Si la integridad es correcta y la latencia de los datos de la aplicación es baja, dirige la investigación a la CPU, la red, la compatibilidad del cliente o la ruta multimedia, en lugar de actualizar de nuevo el almacenamiento.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Usa una prueba de ubicación en cuatro pasos

Mantén la ruta de datos de la aplicación de Plex en un sistema de archivos local persistente, conserva una copia de seguridad actualizada y trata los archivos multimedia principales como un nivel de capacidad independiente. Después, compara una acción repetible de la biblioteca antes y después de cualquier cambio de ubicación. Un diseño de almacenamiento para un servidor multimedia doméstico es más fácil de evaluar cuando las funciones de procesamiento, datos de la aplicación, almacenamiento multimedia y red se documentan por separado.

Antes de aceptar un cambio en la ubicación y la recuperación de la base de datos, una copia de seguridad coherente de SQLite debe proceder de un flujo de copias de seguridad o instantáneas seguro, no de una copia sin control de los archivos activos de la base de datos mientras se están realizando escrituras.

Deja de optimizar el dispositivo de la base de datos cuando la prueba repetida ya no cambie el comportamiento del inicio, la navegación ni los análisis. En ese momento, la siguiente medición útil es la etapa que todavía consume tiempo con la misma carga de trabajo.

1. Confirma que el directorio de datos de Plex es persistente y tiene espacio libre
2. Mide el inicio y un análisis de la biblioteca antes de cambiar el almacenamiento
3. Mueve solo los datos de la aplicación, no todos los archivos multimedia, para realizar la comparación
4. Verifica las rutas de copia de seguridad y restauración antes de retirar la ubicación anterior