Regresión de rendimiento de MongoDB 4.4: eliminado de la memoria

Hay una colección especial de errores en la base de datos cuando el sistema comienza a empeorar cuando proporciona más recursos. Ejemplos de errores de este tipo para MySQL que tengo:

Error # 15815 – Aquí es donde InnoDB en un sistema de 8 CPU se desempeñó peor que en un sistema de 4 CPU con mayor competencia.

Error # 29847 – Este es un error similar al que describiré hoy, cuando se le da más memoria (innodb_buffer_pool_size), el proceso de recuperación de fallas de MySQL tomará más tiempo que con menos memoria, que se ha descrito en nuestro blog Innodb Recovery – Es un gran grupo de búfer siempre mejor. ?

Parece que InnoDB Flushing no era óptimo con una gran cantidad de memoria en ese momento, y esto es lo que creo que sucede con MongoDB 4.4 en el escenario que describiré.

Procedimientos de carga de datos de MongoDB 4.4

Entonces, al preparar datos para mi punto de referencia (Percona Server para MongoDB 4.2 vs 4.4 en Python TPCC Benchmark), también medí cuánto tiempo llevaría cargar 1000 almacenes (aproximadamente 165GB de datos en MongoDB) y tener números repetibles, como I como suele ser. repetir el procedimiento varias veces.

Lo que noté es que cuando MongoDB 4.4 comienza con un caché ilimitado (que está en el servidor con 250 GB de RAM, asignará 125 GB para el caché WiredTiger y el resto se puede usar para el caché del sistema operativo) muestra un comportamiento interesante.

Permítanme describir el procedimiento de carga, que es bastante simple.

  1. Sube los datos a la base de datos TPCC1
  2. Duerme 10 minutos
  3. Sube los datos a la base de datos TPCC3

Esta es la segunda vez que lo cargamos en una base de datos diferente, y en las páginas de fondo de la base de datos, es necesario lavar y raspar TPCC1.

Antes de saltar al problema que veo, verifiquemos el número de MongoDB 4.2, y para el número me refiero a cuánto tiempo lleva hacer el paso 1 y el paso 3.

MongoDB 4.2 con memoria limitada (caché WiredTiger de 25 GB):

Paso 1:20 min

Paso 3:21 min

MongoDB 4.4 con memoria limitada (caché WiredTiger de 25 GB):

Paso 1:24 min

Paso 3:26 min

MongoDB 4.2 con 125 GB de caché WiredTiger

Paso 1:18 min

Paso 3:19 min

Y ahora al problema veo:

MongoDB 4.4 con caché WiredTiger

Paso 1:19 min

Paso 3: 497 min

Observe que el paso 3 lleva casi un tiempo 8 horas y media, en lugar de los ~ 20 minutos habituales para todos los casos anteriores, y esto es cuando MongoDB tiene 125 GB de caché WiredTiger.

Lo interesante es que no veo este problema cuando limito la caché de WiredTiger a 25 GB, e incluso este problema no existe en MongoDB 4.2.

Es por eso que creo que MongoDB 4.4 comienza a comportarse de manera diferente cuando se le da mucha memoria para la caché WiredTiger. Debido a que esto sucede exactamente, ni siquiera lo sé y continuaré describiendo este caso. Un vistazo rápido puede indicar que esto está relacionado con el proceso de desalojo de WiredTiger (similar al problema de flujo de InnoDB en el proceso de recuperación de fallas) y el control de flujo de replicación que se creó en MongoDB 4.2 para mantener las réplicas sincronizadas (pero no usé réplicas para eso). prueba).


Obtenga más información sobre la historia de Oracle, el crecimiento de MongoDB y lo que realmente califica al software como código abierto. Si es un DBA o un ejecutivo que busca adoptar o renovar con MongoDB, ¡esta es una lectura obligada!

Descargar «¿MongoDB es el nuevo Oracle?»

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario