Un vistazo en 33 segundos
- Overcommit = asignar a las VMs, en total, más CPU o RAM de la que el servidor tiene físicamente. Es lo que permite densidad.
- La CPU se sobreasigna con tranquilidad: las vCPU se turnan en los núcleos reales; mientras nadie exija todo a la vez, va bien.
- La RAM se sobreasigna con mucho cuidado: la memoria no se «turna» igual. Si todas las VMs reclaman la suya a la vez y no hay, algo muere.
- Herramientas para la RAM: ballooning (recuperar memoria no usada) y KSM (fusionar páginas idénticas). Ayudan, pero no son magia.
- La regla de oro: CPU se puede overcommittear; la RAM crítica, no. Y siempre con monitorización delante para ver la presión real.
Compras un servidor con 32 núcleos y 256 GB de RAM, y descubres que si asignas los recursos «a lo justo» —sin pasarte del total físico— te caben muchas menos VMs de las que el hardware podría sostener en la práctica. La razón es que casi ninguna VM usa todo lo que tiene asignado todo el tiempo: la mayoría están la mayor parte del rato ociosas o a media capacidad. El overcommit aprovecha ese hueco: asignar en total más de lo que hay físicamente, apostando a que no todas lo reclamarán a la vez.
Es una técnica potente y, bien hecha, la que hace rentable un cloud privado denso. Mal hecha, es la causa de un servidor que un día, sin previo aviso, se arrastra o se cae de golpe. Y la diferencia entre lo uno y lo otro está en entender una asimetría fundamental: la CPU y la RAM no se sobreasignan igual. Con una puedes ser generoso; con la otra, prudente. Este artículo explica por qué, y cómo hacerlo con cabeza en Proxmox.
La CPU: sobreasígnala con tranquilidad
Empecemos por la buena noticia. La CPU es muy tolerante al overcommit, y la razón es cómo funciona: los núcleos físicos se turnan entre las vCPU de las VMs, decenas de miles de veces por segundo. Una vCPU no «posee» un núcleo; lo usa cuando tiene trabajo y lo cede cuando no. Como la mayoría de las VMs están ociosas la mayor parte del tiempo, un núcleo real puede servir a varias vCPU sin que ninguna lo note.
Esto significa que puedes asignar en total bastantes más vCPU que núcleos físicos tienes. Ratios de 2:1, 3:1 o más son habituales y sanos en cargas mixtas normales. El límite lo pone la contención: si demasiadas VMs quieren CPU a la vez, empiezan a esperar su turno, y esa espera se llama steal time —tiempo que la VM está lista para ejecutar pero esperando un núcleo libre—. Mientras el steal time sea bajo, tu overcommit de CPU es sano; cuando sube, es la señal de que te has pasado.
La regla práctica: sé generoso con las vCPU, vigila el steal time. Es una de las métricas clave a tener en tu monitorización. Mientras se mantenga bajo, sigue metiendo VMs; cuando empiece a subir de forma sostenida, has encontrado el techo de ese nodo.
La RAM: aquí es donde la gente se estrella
Y ahora la parte peligrosa. La memoria no se comporta como la CPU, y tratarla igual es cómo se cae un servidor. La diferencia es fundamental: una vCPU que no tiene trabajo cede el núcleo al instante, pero una VM que tiene datos en su RAM no la suelta —esos datos tienen que estar en algún sitio—. La memoria no se «turna»; se ocupa.
¿Qué pasa si sobreasignas RAM —prometes 300 GB entre todas las VMs en un servidor de 256— y en un mal momento todas reclaman de verdad la suya? No hay de dónde sacarla. El sistema recurre entonces a medidas de emergencia: tira de swap (memoria en disco, órdenes de magnitud más lenta, que hunde el rendimiento), y si eso no basta, el mecanismo OOM killer del kernel empieza a matar procesos —o VMs enteras— para liberar memoria. Un servidor que estaba bien de repente se arrastra o pierde máquinas, sin aviso. Ese es el desastre del overcommit de RAM hecho a la ligera.
Por eso la regla con la memoria es la opuesta a la de la CPU: prudencia. No prometas RAM crítica que no puedas respaldar. Pero eso no significa que no haya margen: hay herramientas para exprimir la memoria con seguridad.
Las herramientas para overcommittear RAM con red
Ballooning: recuperar lo que no se usa
El memory ballooning permite a Proxmox recuperar RAM que una VM tiene asignada pero no está usando, para dársela a otra que la necesita. Un driver dentro de la VM (el balloon) «infla» ocupando memoria ociosa que devuelve al host, y se «desinfla» cuando la VM la vuelve a necesitar. Configuras un mínimo y un máximo por VM, y Proxmox reparte lo disponible de forma dinámica dentro de esos márgenes.
Es útil, pero con un límite que hay que respetar: el ballooning recupera memoria ociosa, no memoria en uso. Si una VM de verdad necesita toda su RAM, el balloon no puede quitársela sin dañarla. Y en cargas sensibles a memoria, quitarle RAM a una VM en un pico la hace ir mal. Da a las VMs importantes un mínimo generoso.
KSM: fusionar páginas idénticas
KSM (Kernel Same-page Merging) hace algo ingenioso: detecta páginas de memoria con contenido idéntico entre distintas VMs y las fusiona en una sola copia compartida, liberando el resto. Funciona especialmente bien cuando corres muchas VMs parecidas —el mismo sistema operativo, las mismas bibliotecas cargadas— porque comparten mucha memoria idéntica. Puede recuperar una cantidad notable de RAM «gratis».
Sus matices: consume algo de CPU escaneando páginas, y tiene una consideración de seguridad —al compartir memoria entre VMs se han descrito ataques de canal lateral—, por lo que en entornos multitenant muy sensibles conviene sopesarlo. Para un parque de VMs propias y homogéneas, suele ser una ganancia clara.
La tabla mental del overcommit
| Recurso | ¿Overcommit? | Por qué | Vigila |
|---|
| CPU (vCPU) | Sí, con generosidad | Los núcleos se turnan; las VMs suelen estar ociosas | Steal time |
| RAM | Con prudencia | La memoria se ocupa, no se turna; sobrepasar = swap u OOM | Uso real, swap, presión de memoria |
| RAM crítica (bases de datos, cargas sensibles) | No | Un pico sin RAM las mata o las ralentiza | Darles mínimo garantizado |
La síntesis: la CPU perdona, la RAM no. Sé denso en vCPU, conservador en memoria, usa ballooning y KSM para ganar margen seguro, y nunca sobreasignes la memoria de una carga crítica.
Cómo hacerlo sin sustos
- Overcommit de CPU generoso en cargas mixtas: asigna vCPU con holgura y vigila el steal time. Cuando suba sostenidamente, has encontrado el techo.
- RAM conservadora: no prometas más memoria de la que puedas respaldar en un mal momento. Deja margen para el propio host.
- Ballooning activado con mínimos generosos para las VMs importantes, para recuperar solo lo ocioso.
- KSM si corres muchas VMs homogéneas y no es un entorno multitenant ultrasensible.
- Mínimo garantizado para las cargas críticas (bases de datos): esas no se overcommittean.
- Monitorización delante siempre: steal time, uso real de RAM, actividad de swap. El overcommit sin medir la presión real es apostar a ciegas. Y recuerda la capacidad para HA: si un nodo cae, sus VMs se reparten; tu overcommit debe dejar sitio para eso.
Con esta disciplina, exprimes el hardware —que es de lo que va tener un cloud privado eficiente— sin firmar cheques de memoria que no puedes pagar.
Preguntas frecuentes
¿Qué es el overcommit de recursos?
Asignar a las VMs, en conjunto, más CPU o RAM de la que el servidor tiene físicamente, apostando a que no todas usarán todo lo suyo a la vez. Es lo que permite meter más máquinas en el mismo hardware. Funciona porque la mayoría de las VMs están ociosas o a media capacidad la mayor parte del tiempo.
¿Puedo asignar más vCPU que núcleos físicos tengo?
Sí, y es lo normal. Los núcleos reales se turnan entre las vCPU miles de veces por segundo, y como las VMs suelen estar ociosas, un núcleo sirve a varias sin problema. Ratios de 2:1 o 3:1 son habituales en cargas mixtas. El límite lo marca el steal time: mientras sea bajo, el overcommit de CPU es sano.
¿Es peligroso sobreasignar RAM?
Hecho a la ligera, sí. La memoria no se turna como la CPU: se ocupa. Si prometes más RAM de la que hay y todas las VMs la reclaman a la vez, el sistema tira de swap (lentísimo) y, si no basta, el OOM killer mata procesos o VMs para liberar memoria. Por eso la RAM se sobreasigna con prudencia, y la de cargas críticas no se sobreasigna.
¿Qué son el ballooning y KSM?
El ballooning permite a Proxmox recuperar de una VM la RAM que tiene asignada pero no usa, para dársela a otra, dentro de un mínimo y un máximo. KSM (Kernel Same-page Merging) detecta páginas de memoria idénticas entre VMs y las fusiona en una sola, liberando el resto; funciona muy bien con muchas VMs parecidas. Ambas dan margen seguro para densificar, con sus matices.
¿Cómo sé si me he pasado con el overcommit?
Monitorizando. Para CPU, el steal time sostenido y alto indica que hay demasiada contención. Para RAM, un uso real cercano al total, actividad de swap creciente o presión de memoria son las señales de que estás al límite. Sin monitorización, el overcommit es apostar a ciegas; con ella, ajustas con datos.
Fuentes
¿Quieres meter más VMs en tu hardware sin arriesgarte a que un día se caiga todo por falta de memoria? Te ayudamos a dimensionar el overcommit de tu cloud privado sobre Proxmox —denso donde se puede, prudente donde toca—. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
