Los procesadores modernos cambian de frecuencia y voltaje cientos de veces por segundo para ahorrar energía cuando están poco cargados. Esa gestión la reparten el firmware, el controlador de frecuencia del kernel y el gobernador, que es la política que decide a qué velocidad debe ir cada núcleo. En este tutorial identificarás qué controlador usa tu servidor Ubuntu 24.04, cambiarás el gobernador con cpupower, medirás el efecto con turbostat, controlarás el turbo y los estados de reposo (C-states) y dejarás la configuración persistente con tuned.
Requisitos previos
- Un servidor físico con Ubuntu 24.04 LTS y procesador Intel o AMD, por ejemplo un servidor bare metal de CubePath.
- Un usuario no root con privilegios
sudo.
Notaen un VPS, el hipervisor gestiona la frecuencia de las CPU físicas y la máquina virtual no tiene acceso a ella. Si
/sys/devices/system/cpu/cpu0/cpufreq/no existe en tu servidor, esta guía no aplica: la frecuencia la decide el host.
Paso 1: Instalar las herramientas e identificar el controlador
cpupower y turbostat se distribuyen con las herramientas del kernel, en un paquete ligado a la versión exacta del kernel en ejecución:
sudo apt update
sudo apt install linux-tools-common linux-tools-generic linux-tools-$(uname -r)
linux-tools-generic hace que el paquete se actualice junto con el kernel, para que las herramientas sigan funcionando tras la próxima actualización. Consulta la información de frecuencia:
cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3.90 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.90 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: 1.20 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
Las líneas que importan son driver, available cpufreq governors y el gobernador actual. En un VPS, en cambio, verás no or unknown cpufreq driver is active on this CPU.
Paso 2: Entender controladores y gobernadores
El controlador determina qué gobernadores existen y cómo se comportan. Los habituales en Ubuntu 24.04 son:
Controlador (driver) | Procesadores | Gobernadores |
|---|---|---|
intel_pstate (modo activo) | Intel desde Sandy Bridge | performance, powersave |
intel_cpufreq | Intel con intel_pstate en modo pasivo | performance, powersave, schedutil, ondemand, conservative, userspace |
amd-pstate-epp | AMD Zen 2 o posterior con CPPC | performance, powersave |
amd-pstate | AMD Zen 2 o posterior, modo pasivo o guiado | Los mismos que intel_cpufreq |
acpi-cpufreq | Procesadores sin los anteriores, o si la BIOS no expone CPPC | Los mismos que intel_cpufreq |
Dos cosas que suelen confundirse:
- Con
intel_pstateyamd-pstate-eppen modo activo,powersaveno significa ir a la frecuencia mínima. Es un gobernador dinámico: el propio procesador sube y baja la frecuencia según la carga, guiado por la preferencia de energía (EPP) que verás en el paso 4.performancele pide mantener frecuencias altas. - Con los controladores genéricos,
schedutiles el gobernador dinámico recomendado: usa la información del planificador del kernel para decidir la frecuencia.ondemandyconservativeson alternativas más antiguas.
Puedes consultar el modo de los controladores de Intel y AMD en estos archivos (solo existe el de tu fabricante):
cat /sys/devices/system/cpu/intel_pstate/status
cat /sys/devices/system/cpu/amd_pstate/status
active
Paso 3: Cambiar el gobernador y medir
Antes de cambiar nada, observa cómo se comporta la CPU con carga real. turbostat muestra la frecuencia efectiva y el consumo del paquete a partir de los contadores del procesador:
sudo turbostat --quiet --show Busy%,Avg_MHz,Bzy_MHz,PkgWatt --interval 5
Avg_MHz Busy% Bzy_MHz PkgWatt
112 4.21 2661 38.47
98 3.86 2539 37.90
Busy%: porcentaje del tiempo en que los núcleos estuvieron ejecutando.Bzy_MHz: frecuencia media mientras estaban ocupados. Es la cifra que te dice si el gobernador sube la frecuencia cuando hay trabajo.PkgWatt: consumo del procesador en vatios, cuando el hardware lo expone (RAPL).
Pulsa Ctrl+C para salir. Ahora cambia el gobernador a performance en todas las CPU:
sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
...
Verifica el cambio en todas las CPU a la vez. La salida debe mostrar una sola línea con el número total de CPU:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort | uniq -c
32 performance
Vuelve a lanzar turbostat con la misma carga y compara Bzy_MHz y PkgWatt. Con performance, la frecuencia sube antes y se mantiene más alta, lo que reduce la latencia de las peticiones cortas, a cambio de más consumo en reposo. Si tu servicio es sensible a latencia (bases de datos, APIs, trading, juegos), la diferencia se nota en los percentiles altos; si es un servidor de copias o de procesamiento por lotes, a menudo no merece la pena.
Para volver al comportamiento por defecto:
sudo cpupower frequency-set -g powersave
Con los controladores genéricos (acpi-cpufreq, amd-pstate pasivo), usa schedutil en lugar de powersave para el modo dinámico.
Paso 4: Ajustar la preferencia de energía y el turbo
Energy Performance Preference (EPP)
Con los controladores en modo activo y el gobernador powersave, el procesador decide la frecuencia guiado por la EPP. Consulta los valores posibles y el actual:
cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences
cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
default performance balance_performance balance_power power
balance_performance
Un buen término medio para servidores es mantener powersave con balance_performance: la CPU baja la frecuencia en reposo pero responde rápido a la carga. Para cambiarla en todas las CPU:
echo balance_performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
Con el gobernador performance en intel_pstate, la EPP queda fijada en performance y el kernel rechaza otros valores.
Turbo
El turbo permite superar la frecuencia base cuando hay margen térmico y de consumo. Desactivarlo reduce el rendimiento máximo, pero da una frecuencia más estable y predecible, algo útil para comparar benchmarks o en servidores con problemas térmicos. El control depende del controlador:
# intel_pstate: 0 = turbo activo, 1 = desactivado
cat /sys/devices/system/cpu/intel_pstate/no_turbo
# acpi-cpufreq y otros: 1 = turbo activo, 0 = desactivado
cat /sys/devices/system/cpu/cpufreq/boost
Para desactivarlo temporalmente en un servidor Intel:
echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
Comprueba el efecto con turbostat: Bzy_MHz no debería superar la frecuencia base del procesador. Vuelve a escribir 0 para reactivarlo. En la mayoría de servidores conviene dejar el turbo activo.
Paso 5: Controlar los C-states
Cuando un núcleo no tiene trabajo entra en un estado de reposo (C-state). Cuanto más profundo es el estado, más energía ahorra y más tarda en despertar: desde unos pocos microsegundos en C1 hasta más de 100 µs en los más profundos. Para servicios que responden a peticiones esporádicas con latencias de microsegundos, ese tiempo de despertar se nota.
Lista los estados disponibles y su latencia de salida:
cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
Number of idle states: 4
Available idle states: POLL C1 C1E C6
...
C6:
Flags/Description: MWAIT 0x20
Latency: 133
Usage: 1843201
Duration: 918273645
Latency está en microsegundos. Para probar el efecto, desactiva temporalmente los estados con una latencia de salida superior a 10 µs:
sudo cpupower idle-set -D 10
Mide la latencia de tu aplicación y el consumo con turbostat. Para volver a activar todos los estados:
sudo cpupower idle-set -E
Desactivar C-states profundos aumenta el consumo en reposo y puede reducir el turbo disponible, porque los núcleos inactivos ya no ceden margen térmico a los activos. Hazlo solo si has medido una mejora real de latencia.
Paso 6: Hacer la configuración persistente con tuned
Todo lo anterior se pierde al reiniciar. En lugar de escribir scripts propios, usa tuned, un demonio que aplica perfiles de rendimiento completos (gobernador, EPP, límites de latencia de C-states y parámetros del kernel) en cada arranque:
sudo apt install tuned
sudo systemctl enable --now tuned
Lista los perfiles disponibles y el que el propio tuned recomienda para tu sistema:
tuned-adm list
tuned-adm recommend
Los perfiles más útiles en servidores son:
| Perfil | Qué hace |
|---|---|
balanced | Gobernador dinámico y EPP equilibrada. Buen valor por defecto. |
throughput-performance | Gobernador performance y ajustes de disco y memoria orientados a rendimiento sostenido. |
latency-performance | Como el anterior, y además limita los C-states profundos para reducir la latencia de despertar. |
network-latency | Basado en latency-performance, con ajustes adicionales de red para baja latencia. |
powersave | Prioriza el ahorro de energía. |
Activa el perfil que encaje con tu carga, por ejemplo para una base de datos sensible a latencia:
sudo tuned-adm profile latency-performance
Comprueba el perfil activo y que los ajustes se han aplicado correctamente:
tuned-adm active
sudo tuned-adm verify
Current active profile: latency-performance
Verification succeeded, current system settings match the preset profile.
See TuneD log file ('/var/log/tuned/tuned.log') for details.
Confirma también el gobernador resultante:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort | uniq -c
Reinicia el servidor en una ventana de mantenimiento y repite estas comprobaciones para asegurarte de que el perfil se aplica al arrancar.
Importanteno combines
tunedcon otros servicios que también cambian el gobernador (scripts propios en systemd ocpufrequtils). Cada uno sobrescribiría los ajustes del otro.
Solución de problemas
WARNING: cpupower not found for kernel X: falta el paquete de herramientas del kernel en ejecución. Instala linux-tools-$(uname -r); si acabas de actualizar el kernel, reinicia primero para que ambas versiones coincidan.
cpupower frequency-set -g schedutil falla: el controlador está en modo activo (intel_pstate o amd-pstate-epp) y solo admite performance y powersave. Es el comportamiento esperado; usa powersave con la EPP adecuada.
La frecuencia no pasa de la base aunque el turbo esté activo: revisa en la BIOS el perfil de energía del sistema. Muchos fabricantes tienen un modo "OS Control" o "Performance per Watt (OS)" que es necesario para que Linux gestione la frecuencia; con perfiles controlados por el firmware, los cambios del sistema operativo tienen efecto limitado.
Conclusión
Has identificado el controlador de frecuencia de tu servidor, comparado los gobernadores con datos reales de turbostat, ajustado la EPP, el turbo y los C-states, y dejado un perfil persistente con tuned. Para la mayoría de servidores, balanced o throughput-performance son suficientes; reserva latency-performance para servicios donde has medido que la latencia de despertar importa.
Como siguientes pasos, puedes combinar el perfil con la afinidad NUMA de tus servicios, ajustar los parámetros de red del kernel para tu servidor web o registrar el consumo de PkgWatt en tu sistema de monitorización para cuantificar el coste energético de cada perfil.