On Mon, Apr 10, 2017 at 11:31:59AM +0200, luis gil wrote:
> ¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2?
Lo que dije sobre 1:2 era solamente un ejemplo.
Mientras las aplicaciones hagan overcommit, se debe poner swap para compensar.
> Mi RAM es de 32 G. Me parece excesivo una swap de ese tamaño.
Todo depende de las aplicaciones que estés usando. Si tus aplicaciones
"piden" 64 GB de memoria pero solamente usan 32 GB "normalmente", más
vale que tengas esos 32 GB adicionales en swap para el día en que
realmente quieran usar la memoria que han pedido.
> Según había leído por ahí en varios sitios (no he encontrado mucha
> información sobre este tema), cuando pones el overcommit_memory a 2, se
> fija un nivel de memoria RAM a partir del cual se empiezan a matar
> procesos.
No es exacto. Se fija un nivel de memoria comprometida *total* a
partir del cual se empiezan a matar procesos.
Si este nivel es inferior a la cantidad de swap más la cantidad de
RAM, entonces los procesos morirán antes de que comprometas toda la
memoria disponible (swap + RAM) lo cual es un desperdicio.
Por este motivo el valor del porcentaje, para que tenga sentido,
debería ser >= 100.
Estamos hablando de la memoria "comprometida", esa que a menudo supera
con creces la memoria realmente utilizada.
> Este nivel se calcula realizando la siguiente operación Cantidad
> SWAT + Cantidad RAM * ratio / 100. Poniendo el ratio a 75 el nivel se queda
> un poco por debajo de la RAM, de esta forma se consigue que el sistema no
> empiece a swapear.
Tampoco es exacto. Para que el swap se utilice lo menos posible
hay otro parámetro llamado swappiness.
Lo que quieres no es que no utilice el swap, sino que los procesos no
mueran por falta de memoria "total".
> [...]
De nada sirve monitorizar la memoria usada por Apache cada 5 minutos
si un atacante externo puede lanzar en dos o tres minutos tantas
peticiones http que el sistema se quede sin memoria entre una
observación y la siguiente.
En mi caso, empecé a interesarme por este tema el día que alguien
lanzó 2000 peticiones http a páginas PHP inexistentes en menos de tres
minutos a un servidor que tenía con Apache en modo prefork.
El servidor hizo "cataplof".
Debería ser imposible, por *diseño* (no solamente tomando mediciones
experimentales y monitorizaciones varias), que la memoria necesaria
pueda crecer indefinidamente porque así lo provoque algo externo.
Por eso recomiendo PHP-FPM + nginx.
Por cierto, el incidente de United Airlines de ayer me ha recordado
esta analogía de Andries Brouwer sobre lo absurdo que es el OOM killer:
https://lwn.net/Articles/104179/
A veces la realidad supera la ficción.