--- title: "Gobernadores de CPU y ahorro de energía en Ubuntu 24.04" description: "Identifica el controlador de frecuencia de la CPU, cambia el gobernador con cpupower, controla turbo y C-states y fija un perfil con tuned en Ubuntu 24.04." category: "Rendimiento y Benchmarking" language: es source: https://cubepath.com/es/docs/rendimiento-y-benchmarking/escalado-de-frecuencia-de-cpu-y-gestion-de-energia updated: 2026-09-25 --- # Gobernadores de CPU y ahorro de energía en Ubuntu 24.04 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`. > Nota: en 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: ```bash 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: ```bash cpupower frequency-info ``` ```output 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_pstate` y `amd-pstate-epp` en modo activo, **`powersave` no 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. `performance` le pide mantener frecuencias altas. - Con los controladores genéricos, `schedutil` es el gobernador dinámico recomendado: usa la información del planificador del kernel para decidir la frecuencia. `ondemand` y `conservative` son alternativas más antiguas. Puedes consultar el modo de los controladores de Intel y AMD en estos archivos (solo existe el de tu fabricante): ```bash cat /sys/devices/system/cpu/intel_pstate/status cat /sys/devices/system/cpu/amd_pstate/status ``` ```output 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: ```bash sudo turbostat --quiet --show Busy%,Avg_MHz,Bzy_MHz,PkgWatt --interval 5 ``` ```output 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: ```bash sudo cpupower frequency-set -g performance ``` ```output 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: ```bash cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort | uniq -c ``` ```output 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: ```bash 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: ```bash cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference ``` ```output 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: ```bash 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: ```bash # 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: ```bash 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: ```bash cpupower idle-info ``` ```output 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: ```bash 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: ```bash 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: ```bash sudo apt install tuned sudo systemctl enable --now tuned ``` Lista los perfiles disponibles y el que el propio `tuned` recomienda para tu sistema: ```bash 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: ```bash sudo tuned-adm profile latency-performance ``` Comprueba el perfil activo y que los ajustes se han aplicado correctamente: ```bash tuned-adm active sudo tuned-adm verify ``` ```output 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: ```bash 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. > Importante: no combines `tuned` con otros servicios que también cambian el gobernador (scripts propios en systemd o `cpufrequtils`). 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.