Groupcache: problemas con los límites superiores de los límites de memoria

Hola,

Gracias por el caché de grupo, lo estamos utilizando con casi gran éxito.

Una cosa que me gustaría entender más es cómo estimar / conocer los límites superiores de las necesidades de memoria de una aplicación, cuya funcionalidad principal es simplemente servir cosas desde la caché de grupo.

Así que tenemos un caché de grupo en ejecución de vm de 6GB, y nuestra primera inclinación fue establecer el tamaño de caché disponible en 5gb, dejando 1gb libre para el sistema operativo y otras cosas.

De inmediato, esto se bloqueó bajo la carga de producción debido a que se invocó el asesino de OOM. Así que terminamos reduciendo este número a poco menos de 2 GB para que la memoria que usa el proceso permanezca por debajo de los 6 GB antes de que OOM Killer se active.

Entonces, el siguiente paso fue perfilar la memoria, y el tamaño del montón no supera con creces los 2 GB que hemos configurado en la caché de grupo. Pero el proceso termina usando 4-6 GB de RAM.

Entonces, el último intento fue llamar manualmente a debug.FreeOSMemory () cada dos minutos, y cuando se ejecuta, poco después, la cantidad de memoria que el proceso requiere caídas, se devuelve mucho al sistema operativo.

Sin embargo, todavía tenemos bloqueos ocasionales debido al asesino de OOM. Agregamos SSD swap para amortiguar este caso, pero después de 48 horas sin problemas, hubo un problema (aumento sustancial) en el tráfico hacia estas máquinas, lo que provocó que una sola matara a OOM, que luego se convirtió en una bola de nieve en varias otras que hicieron que esto sucediera.

Entonces, para que esto funcione, podríamos eliminar la configuración de caché de 2GB (también conocido como segundo parámetro en groupcache.NewGroup) a 1GB aún más bajo, pero parece un poco tonto tener una máquina virtual de 6GB que solo puede usar 1gb para caché.

¿Es esto solo una desventaja de usar el enfoque de go para la administración de memoria para el almacenamiento en caché?

No estoy seguro de si es importante, pero nuestro caso de uso es muy similar a dl.google.com. Estamos brindando descargas de archivos de tamaño mediano (50 MB-1 GB, almacenados en caché en fragmentos de 100 MB), y la caché de grupo se usa para enfrentar una API más lenta y costosa que tiene los archivos que necesitamos para servir. Entonces, naturalmente, al encontrar esto, parece una gran solución al problema.

Estaríamos muy agradecidos por cualquier consejo que pudiera compartir para gestionar este tipo de problemas. Sigo pensando que hay algo que me estoy perdiendo.

Gracias por cualquier información que pueda compartir.

• Scott