¿Por qué Home Assistant genera cargas diferentes durante las lecturas y escrituras?

Home Assistant genera diferentes cargas de lectura y escritura porque las consultas reutilizan páginas en caché, mientras que la persistencia del estado modifica diarios, índices y almacenamiento persistente.

Abrir un gráfico del historial puede recorrer muchas filas almacenadas sin modificarlas, mientras que un solo sensor ruidoso puede crear pequeñas transacciones a lo largo del día. El primer patrón favorece las lecturas secuenciales, la caché de la base de datos y los índices de consulta; el segundo añade sincronización, actualizaciones del diario, metadatos del sistema de archivos y amplificación de escritura de la memoria flash. Por eso sus gráficos difieren, aunque ambas operaciones impliquen la misma base de datos de Recorder.

Los cambios de estado en tiempo real generan más de una escritura

Recorder convierte determinados cambios de estado y eventos en transacciones de base de datos. La inserción de una fila lógica también puede actualizar índices y un diario o registro de escritura anticipada antes de que el sistema de archivos y la caché del dispositivo confirmen que la operación se ha completado de forma persistente.

Un análisis de la base de datos y las estadísticas separa el almacenamiento del estado a corto plazo de las estadísticas a largo plazo, y aclara por qué las estructuras de datos de Recorder pueden afectar a varias estructuras relacionadas en lugar de a un único archivo de solo anexado.

Las entidades de alta frecuencia crean muchos cambios lógicos pequeños que pueden confirmarse en grupos. Esto puede aparecer como ráfagas periódicas; los bytes escritos físicamente pueden superar la carga útil porque las capas de la base de datos y del almacenamiento preservan la coherencia.

Las lecturas del historial dependen del rango, la selectividad y la caché

Una consulta del estado actual es pequeña, pero un gráfico del historial de varias entidades puede recorrer un rango temporal amplio, descodificar atributos, agregar resultados y enviarlos al cliente. Los índices adecuados y las páginas de la base de datos en caché pueden mantener muchas de esas operaciones alejadas del almacenamiento físico.

Un caso de rendimiento prolongado encontró que el acceso al historial era extremadamente lento a pesar del uso normal en tiempo real, lo que demuestra que la carga de trabajo de las consultas del historial puede revelar un problema en la ruta de consulta que el control del estado actual no provoca.

Las lecturas repetidas suelen volverse más rápidas cuando las páginas relevantes permanecen en la memoria. Esa ventaja desaparece después de reiniciar, bajo presión de memoria o al consultar un rango de fechas diferente, por lo que una sola consulta con la caché caliente no es una medida fiable de la capacidad de almacenamiento.

El coste de escritura aumenta con el registro y los servicios vecinos

Home Assistant Core no es el único proceso que escribe en un servidor doméstico típico. Los registros de depuración, las bases de datos de los complementos, las copias de seguridad, las instantáneas de las cámaras y los registros de los contenedores pueden compartir el mismo dispositivo y provocar colas justo cuando Recorder intenta confirmar una transacción.

Usuarios que redujeron el desgaste de la memoria flash observaron que los registros y los componentes relacionados añaden ciclos de escritura, por lo que la actividad de escritura del volumen completo debe incluir todo el volumen, no solo el proceso principal de la base de datos.

La atribución por proceso separa el comportamiento de la aplicación de la contención del almacenamiento compartido. Si Recorder está inactivo mientras otro contenedor realiza las escrituras, cambiar las exclusiones de entidades no resolverá la carga observada.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

El mantenimiento puede invertir el patrón habitual

Eliminar filas caducadas, reconstruir índices, ejecutar vacuum o reempaquetar puede leer y reescribir grandes partes de una base de datos. Durante ese periodo, una tarea descrita como limpieza puede generar más lecturas y escrituras de lo habitual en la ingesta normal de estados.

Los debates sobre la configuración de Recorder relacionan la retención y el comportamiento de purgado con el mantenimiento de la base de datos, por lo que el comportamiento de retención y purgado es esencial cuando aparece un pico de carga habitual a la misma hora cada día.

La explicación basada en lecturas frente a escrituras deja de ser aplicable cuando el cuello de botella está en la evaluación de plantillas en la CPU, la representación del cliente o la entrega por red. Los contadores de almacenamiento deben aumentar junto con el síntoma; de lo contrario, la base de datos solo está relacionada indirectamente con el retraso.

Compara una ruta de lectura y una de escritura

Elige una consulta fija del historial y una acción inocua que cambie el estado. Para cada una, registra la latencia de la solicitud, la CPU, el tiempo de la base de datos, el rendimiento del disco, las IOPS, la profundidad de la cola y la latencia del dispositivo desde un inicio en frío y después en una ejecución repetida con la caché caliente.

El artículo relacionado sobre el crecimiento de los datos retenidos explica por qué el crecimiento de los metadatos y del historial cambia la carga de trabajo, y basa la comparación en los datos retenidos en lugar de en un tráfico de prueba arbitrario.

Clasifica el límite según la covariación: una primera lectura lenta seguida de una repetición rápida sugiere localidad de caché; un tiempo de consulta creciente a medida que aumenta el rango sugiere un coste de recorrido; un retraso de escritura junto con una mayor profundidad de cola sugiere contención del almacenamiento persistente; la ausencia de ambos patrones apunta a otra capa. Optimiza únicamente la ruta que reproduzca dos veces el retraso visible para el usuario.