Ejecutamos una pequeña réplica de mongodb configurada en tres servidores bare metal (sin virtualización, sin docker/kubernetes) con Debian 11 y mongodb 5.0.6:
máquinaA: 128 GB de RAM, disco de 1 TB, PRIMARIA máquina B: 128 GB de RAM, disco de 1 TB, máquina SECUNDARIA C: 8 GB de RAM, disco de 20 GB, ARBITER
De repente, experimentamos interrupciones con errores en el registro de nuestra aplicación como "NotWritablePrimary"/"MongoNotPrimaryException"; estábamos asumiendo que nuestra cadena de conexión se aseguraría de que no se produjera ninguna interrupción:
mongodb://machineA:27017,machineB:27017/?replicaSet=MyRepl&waitQueueMultiple=10&readPreference=primaryPreferred
Resultó que la instancia PRIMARIA de mongodb fue eliminada por el kernel de Linux, ya que consumía demasiada RAM. El conjunto de réplicas estuvo funcionando durante 3 meses sin ningún problema. Pero de repente veo un consumo de RAM así:
De repente, mongodb hizo un uso masivo de RAM:
Inmediatamente después de que el kernel eliminó el proceso mongod, SystemD lo reinició mientras se ejecuta como un servicio. Pero justo después del reinicio, consume nuevamente la cantidad máxima de RAM hasta que se apaga nuevamente.
De repente, este comportamiento cesó esta mañana. No cambiamos nada en nuestra aplicación, por lo que la pregunta ahora es: ¿qué consume tanta RAM en el proceso mongodb?
Hasta donde yo sé, el motor WireTiger está usando ~50% de la RAM disponible, pero eso no explicaría el uso máximo de la RAM total de la máquina. También tengo algunas métricas de Percona mongodb_exporter, que muestran que mongodb usa RAM y ningún otro proceso en el sistema:
Curiosamente, el uso de memoria del SECUNDARIO no se movía en absoluto en ese momento:
¿Alguien tiene alguna idea o pista de lo que está pasando aquí?
Respuesta1
Descubrimos que uno de nuestros servicios de aplicación se estaba volviendo loco en ciertas circunstancias y era un poco difícil de ver para nosotros.
Cuando se ataca constantemente a MongoDb, parece que el uso de la memoria es cada vez mayor, en lugar de que se utilicen más recursos de CPU como era de esperar. En cierto punto, el kernel de Linux eliminó el proceso mongod.
Después de solucionar el problema en nuestra aplicación, la situación desapareció.