Cómo saber si Plex está limitado por la CPU, la RAM, el almacenamiento o la red

Puedes saber qué limita Plex reproduciendo una carga de trabajo conocida y buscando el recurso cuya presión aumenta al mismo tiempo que la transmisión se ralentiza. No actualices primero el componente que parezca más ocupado; una utilización alta solo importa cuando coincide con el fallo de reproducción.

Empieza con un archivo, un cliente, un modo de reproducción y un intervalo de tiempo. Después, separa el trabajo de conversión de Plex de las señales del sistema operativo para la CPU, la memoria, el almacenamiento y la red. La prueba solo estará completa cuando cambiar un recurso sospechoso modifique el síntoma original de Plex mientras las demás condiciones permanecen estables.

Reproduce una carga de trabajo de Plex antes de leer las métricas del sistema

Elige un archivo y un cliente que reproduzcan el problema de forma fiable. Registra si el síntoma es un inicio lento, almacenamiento en búfer repetido, una transcodificación que se queda atrás, un análisis que provoca retrasos durante la reproducción o un fallo que solo ocurre de forma remota, ya que cada síntoma apunta a una ruta de espera diferente.

Un flujo de resolución de problemas específico de Plex debe comenzar con la sesión activa, no con un gráfico genérico de la CPU. Una comprobación centrada en el panel separa las ramas de reproducción directa, transcodificación, red y almacenamiento antes de que empieces a cambiar el servidor.

Mantén sin cambios el archivo, las pistas seleccionadas, la calidad del cliente y la carga de trabajo simultánea mientras recopilas las métricas del sistema. Si el síntoma cambia entre pruebas, simplifica la carga de trabajo hasta que el mismo fallo se repita; de lo contrario, un pico posterior de CPU o disco podría pertenecer a otro trabajo.

Usa la sesión de Plex para separar la entrega de la conversión

Lee la sesión de Plex mientras ocurre el problema. La reproducción directa significa que el servidor se dedica principalmente a entregar los archivos multimedia almacenados, mientras que una transcodificación de vídeo añade una ruta de conversión en tiempo real que puede desplazar el cuello de botella hacia la CPU o los motores de vídeo por hardware.

Usa ese modo como una bifurcación, no como una conclusión. Una transcodificación que se queda atrás convierte al procesamiento en un candidato importante, pero una reproducción directa que almacena en búfer todavía deja el almacenamiento y la red dentro del alcance. Si el mismo archivo cambia de modo cuando modificas los subtítulos, el audio o la calidad, reproduce de nuevo el problema con la solicitud original antes de comparar las métricas del sistema.

El resultado de esta sección debe ser un modo de reproducción fijo vinculado al síntoma. Si no puedes indicar si la prueba fallida usa reproducción directa o transcodificación, detente aquí; comparar los datos de RAM, disco y red antes de estabilizar la ruta multimedia dificulta la interpretación de las métricas restantes.

Prueba conjuntamente la presión de la CPU y la RAM

Observa la utilización de la CPU, la cola de ejecución o la carga, la memoria disponible y la actividad de intercambio durante la prueba fija de Plex. La presión de la CPU es más evidente cuando el proceso de Plex o su transcodificador consume capacidad de procesamiento de forma sostenida mientras la salida se retrasa; la presión de memoria es más importante cuando el sistema empieza a recuperar memoria o a usar el área de intercambio y el tiempo de respuesta empeora, aunque la CPU no sea el único recurso ocupado.

Un flujo general de rendimiento en Linux utiliza herramientas como top, vmstat, iostat y sar para separar la presión de los recursos. En particular, la CPU, la memoria, el disco y la red necesitan señales de saturación diferentes, en lugar de un único número de utilización general.

Si la CPU se mantiene cerca de su límite solo durante la transcodificación fallida y la transmisión se recupera al eliminar o acelerar la conversión, considera el procesamiento como el principal cuello de botella. Si aumenta el uso del área de intercambio o la recuperación de memoria, reduce los trabajos simultáneos que consumen mucha memoria o añade memoria; después, repite la misma carga de trabajo de Plex antes de modificar la configuración del almacenamiento o la red.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prueba el almacenamiento con la misma ruta multimedia

Para probar el almacenamiento, lee el mismo contenido multimedia desde el mismo sistema de archivos mientras se reproduce el síntoma y observa la latencia del dispositivo, la cola y la espera de E/S. La capacidad y el rendimiento son aspectos distintos: un disco puede tener espacio libre y aun así responder lentamente porque otro trabajo está generando E/S aleatorias o porque la ruta multimedia pasa por un grupo de almacenamiento o un montaje de red ocupado.

Las herramientas de Linux, como iostat e iotop, son útiles porque la espera de E/S del disco y el rendimiento del dispositivo muestran un modo de fallo diferente al de una CPU elevada o la actividad del área de intercambio. Compara esos valores con el intervalo exacto en que ocurre el almacenamiento en búfer, no con un promedio en reposo.

Si el archivo se lee correctamente mientras Plex almacena en búfer, es menos probable que el almacenamiento sea la causa. Si la latencia y la cola aumentan junto con el síntoma, pausa el trabajo que compite por el disco o mueve el archivo de prueba a una ruta local conocida por su rapidez; si Plex se recupera inmediatamente con el mismo modo de reproducción, el almacenamiento habrá pasado de ser una sospecha a convertirse en una evidencia.

Prueba el rendimiento de red en la ruta real

Prueba por separado la ruta entre el servidor y el cliente. Un cliente local conectado por cable puede distinguir un problema de la ruta remota de un problema de recursos general del servidor, mientras que una prueba de rendimiento de extremo a extremo puede mostrar si la ruta admite la tasa multimedia sin depender de la aplicación Plex.

Usa una herramienta como iperf3 cuando controles ambos extremos. Una prueba de red debe comprobar el rendimiento, la pérdida de paquetes y la latencia, porque la velocidad nominal del enlace no demuestra que la ruta real entregue tráfico estable a las aplicaciones.

Si la prueba de red independiente se degrada mientras la CPU, la memoria y el almacenamiento se mantienen saludables, corrige la ruta antes de ajustar el transcodificador. Si la red tiene suficiente margen sostenido y el síntoma de Plex persiste en una prueba local por cable, vuelve a la rama de recursos del servidor en lugar de comprar un router más rápido.

Cambia únicamente el recurso que falló en la prueba

Elige el primer recurso que haya fallado en una prueba discriminatoria y realiza un cambio que debería afectar únicamente a esa rama. Algunos ejemplos son activar una transcodificación por hardware verificada para una transmisión limitada por el procesamiento, reducir un trabajo en segundo plano que consuma mucha memoria, reprogramar una tarea intensiva para el disco o evitar un tramo débil de la red.

Para continuar con la resolución específica de Plex, la ruta de diagnóstico del almacenamiento en búfer de ZimaSpace ofrece una continuación más profunda una vez que sepas si la rama que debes cambiar es el modo de reproducción, la carga de conversión, la estabilidad de la red o la capacidad de respuesta del almacenamiento.

Repite el archivo, el cliente y el modo de reproducción originales después del cambio. Considera que un componente es el cuello de botella solo cuando el síntoma original mejora y la señal de presión correspondiente disminuye o adquiere más margen. Si el síntoma no cambia, restaura la configuración de referencia y prueba la siguiente rama en lugar de acumular actualizaciones hasta que la causa real desaparezca por accidente.