Ajuste de rendimiento

Triage por síntoma

Síntoma

Primeros checks

Siguiente acción probable

Throughput menor al esperado

distribución de colas/CPU, profundidad de estrategia, salud del scheduler

reducir profundidad o usar promote_to_root y volver a medir

CPU alta en un solo núcleo

desbalance IRQ/colas, cuello en nodo raíz

rebalancear afinidad y/o promover sitios pesados a raíz

Cambio de rendimiento tras cambios de integración

cambio no intencional de estrategia/profundidad

confirmar estrategia (flat/ap_only/ap_site/full) y validar árbol/flujo

Base de CPU e IRQ

LibreQoS ahora intenta configurar automáticamente el governor de CPU en modo performance durante el ajuste de arranque en hosts bare metal e hipervisor.

Este comportamiento está habilitado por defecto mediante [tuning].set_cpu_governor_performance = true. Desactívelo solo si su plataforma requiere otra política de governor.

Si necesita verificar manualmente el governor actual:

cpupower frequency-info | grep 'current policy'

Confirme que el conteo de colas NIC y la distribución por CPU sean razonables:

ethtool -l <interfaz>
grep -E 'CPU\\(|IRQ' /proc/interrupts | head -n 50

Si un solo núcleo/cola está saturado y los demás están ociosos, rebalancee afinidad IRQ/colas y revise la configuración de colas en /etc/lqos.conf.

Presión por topología/colas

Cuando modele jerarquías grandes:

  • Prefiera estrategias de menor profundidad (ap_only/ap_site) salvo que necesite jerarquía completa.

  • Use promote_to_root en topologías multi-sitio para evitar cuellos de botella de un solo núcleo.

  • Valide CPU Tree/CPU Weights en WebUI después de cambios topológicos importantes.

Consulte también Escalado y diseño de topología.

Frecuencia del scheduler y carga

La cadencia de lqos_scheduler afecta carga del plano de control y velocidad de cambios.

  • Comience con queue_refresh_interval_mins conservador.

  • Reduzca intervalo solo si su integración/API y host soportan ese churn.

  • Tras cambiar intervalo, monitoree:

    • journalctl -u lqos_scheduler --since "30 minutes ago"

    • estado del scheduler en WebUI

Despliegue de StormGuard

Si usa StormGuard:

  1. Inicie con dry_run = true.

  2. Observe al menos un periodo de alto tráfico.

  3. Pase a modo activo solo tras revisar estado/depuración.

Vea StormGuard.

Arranque lento / dependencias de red

Si Ubuntu arranca lento por dependencias de network-online, inspeccione:

systemctl show -p WantedBy network-online.target

En algunos entornos Ubuntu, deshabilitar servicios no usados de cloud/iSCSI puede ayudar:

sudo systemctl disable cloud-config iscsid cloud-final

Valide esta acción contra su entorno antes de aplicarla.

Convergencia de ruteo (OSPF)

Para despliegues enrutados, ajuste timers OSPF entre core y edge para reducir ventanas de indisponibilidad en reinicios:

  • hello interval

  • dead interval

Páginas relacionadas de optimización y resiliencia