ApsaraDB for MongoDB:Solución de problemas de alto uso de memoria en ApsaraDB for MongoDB

• Analizar los gráficos de monitoreo

  Puede consultar el uso de memoria de ApsaraDB for MongoDB en la página Monitoring Information de la consola de ApsaraDB for MongoDB. La composición de nodos de las instancias de ApsaraDB for MongoDB varía según la arquitectura de la instancia. Seleccione un nodo para consultar su uso de memoria.

  • Arquitectura de conjunto de réplicas: incluye un nodo primario, uno o más nodos secundarios, un nodo oculto y, opcionalmente, uno o más nodos de solo lectura.

  • Arquitectura de clúster fragmentado: el uso de memoria de cada shard es similar al de un conjunto de réplicas. El Config Server almacena los metadatos de configuración. El uso de memoria de un nodo de enrutamiento mongos depende del tamaño de los conjuntos de resultados de agregación, la cantidad de conexiones y el tamaño de los metadatos.

• Usar la línea de comandos

  Connect to the instance mediante el shell de mongo y ejecute el comando db.serverStatus().mem para consultar y analizar el uso de memoria. El siguiente código muestra un ejemplo de salida:

{ "bits" : 64, "resident" : 13116, "virtual" : 20706, "supported" : true }
// resident indicates the physical memory used by the mongod process, in MB.
// virtual indicates the virtual memory used by the mongod process, in MB.

Compruebe el uso de memoria del motor con estos métodos:

Una gran cantidad de bases de datos, colecciones e índices en una instancia de ApsaraDB for MongoDB consume mucha memoria debido a los metadatos asociados. Las versiones anteriores de ApsaraDB for MongoDB pueden presentar los siguientes problemas:

• En versiones de ApsaraDB for MongoDB anteriores a la 4.0, una copia de seguridad lógica completa puede abrir una gran cantidad de manejadores de archivos. Si estos manejadores no se devuelven al sistema operativo rápidamente, el uso de memoria puede aumentar de forma acelerada.

• En ApsaraDB for MongoDB 4.0 y versiones anteriores, eliminar una gran cantidad de colecciones puede no quitar correctamente los manejadores de archivos correspondientes, lo que provoca una fuga de memoria.

Durante las escrituras normales de datos, un nodo secundario mantiene un búfer de hasta aproximadamente 256 MB para la aplicación del oplog. Sin embargo, replicar operaciones de creación de índices en un nodo secundario puede consumir más memoria.

• En versiones de ApsaraDB for MongoDB anteriores a la 4.2, la creación de índices admite la opción background. Cuando se especifica {background:true}, el índice se compila en segundo plano. La replicación de esta operación es serial y puede consumir hasta 500 MB de memoria.

• En ApsaraDB for MongoDB 4.2 y versiones posteriores, la opción background está obsoleta. Los nodos secundarios pueden replicar operaciones de creación de índices en paralelo, lo que consume más memoria. Crear varios índices al mismo tiempo puede provocar un error de falta de memoria (OOM).

En algunos escenarios, una sola consulta puede tener una gran cantidad de planes de ejecución candidatos, lo que provoca que la caché de planes consuma una cantidad significativa de memoria.

Consultar el uso de memoria de la caché de planes: en ApsaraDB for MongoDB 4.0 y versiones posteriores, puede ejecutar el comando db.serverStatus().metrics.query.planCacheTotalSizeEstimateBytes para consultar el uso de memoria.

La optimización de memoria busca equilibrar la utilización de recursos y el rendimiento, no minimizar el uso a toda costa.

ApsaraDB for MongoDB especifica el CacheSize, el cual no se puede modificar. Optimice el uso de memoria con estas estrategias:

• Controle las conexiones simultáneas. El controlador predeterminado de MongoDB establece un pool de 100 conexiones. Si se conectan muchos clientes, reduzca el tamaño del pool por cliente. Mantenga el total de conexiones persistentes por debajo de 1,000 para evitar un overhead excesivo de memoria y cambios de contexto.

• Reduzca el overhead de memoria por solicitud mediante la creación de índices para evitar escaneos de colecciones y clasificaciones en memoria.

• Si el uso de memoria permanece alto después de optimizar las consultas y las conexiones, actualice la especificación de memoria de la instancia para prevenir errores OOM y degradación del rendimiento causada por un desalojo excesivo de caché.

• Acelere la liberación de memoria por parte de tcmalloc. Si el uso de memoria de su instancia de base de datos supera el 80%, puede ajustar los parámetros relacionados con tcmalloc en la página Parameter Settings de la consola.

  1. Habilite el parámetro tcmallocAggressiveMemoryDecommit. Esta configuración resuelve eficazmente los problemas de retención de memoria.

  2. Si el problema persiste, aumente gradualmente el valor de tcmallocReleaseRate (por ejemplo, de 1 a 3 y luego a 5).

  Importante

  • Realice los ajustes durante horas de baja actividad. Estos parámetros pueden degradar el rendimiento de la base de datos. Revierta los cambios inmediatamente si su negocio se ve afectado.

  • Monitoree el uso de CPU, el tiempo de respuesta (RT) y los opCounters antes y después del ajuste para evaluar el impacto.

• Optimice la cantidad de bases de datos y colecciones eliminando colecciones e índices innecesarios, consolidando tablas, dividiendo la instancia o migrando a un clúster fragmentado. Instance performance slows down or becomes abnormal due to an excessive number of databases and tables.

Parámetros de desalojo