Preguntas frecuentes: Diagnóstico autogestionado de MongoDB

Ajuste del valor keepalive de TCP:

Será necesario reiniciar los procesos y para que las nuevas configuraciones de keepalive en todo el sistema surtan mongod mongos efecto.

Ajustar el tiempo de espera de retransmisión TCP

¿El tamaño de mi conjunto de trabajo debe ajustarse a la RAM?

No.

Si el caché no tiene suficiente espacio para cargar datos adicionales, WiredTiger expulsa páginas del caché para liberar espacio.

El valor por defecto del tamaño de la caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene varias instancias de MongoDB, reduce la configuración para acomodar las otras instancias mongod.

Si ejecuta en un contenedor (por mongod ejemplo,,, lxc cgroupsDocker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debe establecer storage.wiredTiger.engineConfig.cacheSizeGB o en un valor menor que la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los demás procesos que se ejecutan en el storage.wiredTiger.engineConfig.cacheSizePct contenedor.memLimitMB Consulte.

Solo puedes proporcionar uno de storage.wiredTiger.engineConfig.cacheSizeGB o storage.wiredTiger.engineConfig.cacheSizePct.

Para ver las estadísticas de caché y desalojo, use el serverStatus comando. El wiredTiger.cache campo contiene la información sobre caché y desalojo.

...
"wiredTiger" : {
   ...
   "cache" : {
      "tracked dirty bytes in the cache" : <num>,
      "bytes currently in the cache" : <num>,
      "maximum bytes configured" : <num>,
      "bytes read into cache" :<num>,
      "bytes written from cache" : <num>,
      "pages evicted by application threads" : <num>,
      "checkpoint blocked page eviction" : <num>,
      "unmodified pages evicted" : <num>,
      "page split during eviction deepened the tree" : <num>,
      "modified pages evicted" : <num>,
      "pages selected for eviction unable to be evicted" : <num>,
      "pages evicted because they exceeded the in-memory maximum" : <num>,,
      "pages evicted because they had chains of deleted items" : <num>,
      "failed eviction of pages that exceeded the in-memory maximum" : <num>,
      "hazard pointer blocked page eviction" : <num>,
      "internal pages evicted" : <num>,
      "maximum page size at eviction" : <num>,
      "eviction server candidate queue empty when topping up" : <num>,
      "eviction server candidate queue not empty when topping up" : <num>,
      "eviction server evicting pages" : <num>,
      "eviction server populating queue, but not evicting pages" : <num>,
      "eviction server unable to reach eviction goal" : <num>,
      "pages split during eviction" : <num>,
      "pages walked for eviction" : <num>,
      "eviction worker thread evicting pages" : <num>,
      "in-memory page splits" : <num>,
      "percentage overhead" : <num>,
      "tracked dirty pages in the cache" : <num>,
      "pages currently held in the cache" : <num>,
      "pages read into cache" : <num>,
      "pages written from cache" : <num>,
   },
   ...

Para obtener una explicación de algunas estadísticas de caché de claves y desalojo, como wiredTiger.cache.bytes currently in the cache y,wiredTiger.cache.tracked dirty bytes in the cache wiredTiger.cacheconsulte.

Para ajustar el tamaño de la caché interna de WiredTiger, consulta --wiredTigerCacheSizeGB y storage.wiredTiger.engineConfig.cacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto. Si el caso de uso requiere un aumento del tamaño de la caché interna, consulta --wiredTigerCacheSizePct y storage.wiredTiger.engineConfig.cacheSizePct.

¿Cómo calculo cuánta RAM necesito para mi aplicación?

Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.

Por defecto, WiredTiger utiliza la compresión de bloques Snappy para todas las colecciones y la reducción de prefijo para todos los índices. Los valores de compresión por defecto son configurables a nivel global y también pueden establecerse por colección y por índice durante la creación de colecciones e índices.

Se utilizan diferentes representaciones para los datos en la caché interna de WiredTiger frente al formato en disco:

• Los datos en la caché del sistema de archivos son idénticos al formato en disco, incluidos los beneficios de cualquier compresión para los archivos de datos. La caché del sistema de archivos es utilizada por el sistema operativo para reducir la E/S del disco.

• Los índices cargados en la caché interna de WiredTiger tienen una representación de datos diferente al formato en disco, pero aún pueden aprovechar la reducción de prefijo de índice para reducir el uso de RAM. La reducción de prefijo de índice elimina duplicados de los prefijos comunes de los campos indexados.

• Los datos de la colección en la caché interna de WiredTiger están sin comprimir y utilizan una representación diferente al formato en disco. La compresión de bloques puede proporcionar un ahorro significativo de almacenamiento en disco, pero los datos deben ser descomprimidos para que el servidor los manipule.

Con la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no está siendo utilizada por la caché de WiredTiger ni por otros procesos.

Para ajustar el tamaño de la caché interna de WiredTiger, consulta --wiredTigerCacheSizeGB y storage.wiredTiger.engineConfig.cacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto. Si el caso de uso requiere un aumento del tamaño de la caché interna, consulta --wiredTigerCacheSizePct y storage.wiredTiger.engineConfig.cacheSizePct.

El valor por defecto del tamaño de la caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene varias instancias de MongoDB, reduce la configuración para acomodar las otras instancias mongod.

Si ejecuta en un contenedor (por mongod ejemplo,,, lxc cgroupsDocker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debe establecer storage.wiredTiger.engineConfig.cacheSizeGB o en un valor menor que la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los demás procesos que se ejecutan en el storage.wiredTiger.engineConfig.cacheSizePct contenedor.memLimitMB Consulte.

Solo puedes proporcionar uno de storage.wiredTiger.engineConfig.cacheSizeGB o storage.wiredTiger.engineConfig.cacheSizePct.

Para ver las estadísticas sobre la caché y la tasa de desalojos, consultar el campo wiredTiger.cache devuelto por el comando serverStatus.

En un nuevo clúster fragmentado, ¿por qué todos los datos permanecen en un solo fragmento?

Su clúster debe tener suficientes datos para que la fragmentación sea lógica. La fragmentación funciona migrando fragmentos entre los fragmentos hasta que cada uno tenga aproximadamente la misma cantidad de fragmentos.

El tamaño predeterminado 128 de los fragmentos es de megabytes. MongoDB no iniciará las migraciones hasta que el desequilibrio de fragmentos en el clúster supere el umbral de migración. Este comportamiento ayuda a evitar migraciones innecesarias de fragmentos, que pueden reducir el rendimiento general del clúster.

Si acaba de implementar un clúster fragmentado, asegúrese de tener suficientes datos para que la fragmentación sea efectiva. Si no tiene suficientes datos para crear más de ocho 128 fragmentos de megabytes, todos los datos permanecerán en un solo fragmento. Reduzca el tamaño del fragmento o añada más datos al clúster.

Como problema relacionado, el sistema divide los fragmentos solo al insertar o actualizar. Esto significa que, si configura la fragmentación y no realiza operaciones de inserción y actualización, la base de datos no creará ningún fragmento. Puede esperar a que la aplicación inserte los datos o dividir los fragmentos manualmente.

Por último, si tu clave de partición tiene una cardinalidad baja, es posible que MongoDB no pueda crear suficientes particiones entre los datos.

¿Por qué un fragmento recibiría una cantidad desproporcionada de tráfico en un clúster fragmentado?

En algunas situaciones, un solo fragmento o un subconjunto del clúster recibirá una parte desproporcionada del tráfico y la carga de trabajo. En casi todos los casos, esto se debe a una clave de fragmento que no permite el escalado de escritura de forma eficaz.

También es posible que tenga fragmentos activos. En este caso, podría resolver el problema dividiendo y migrando partes de estos fragmentos.

Es posible que tengas que considerar volver a fragmentar tu colección con una clave de fragmentación diferente para corregir este patrón.

¿Qué puede impedir que un clúster fragmentado se equilibre?

Si acabas de implementar tu clúster particionado, podrías considerar las sugerencias de solución de problemas para un clúster nuevo donde los datos permanecen en una sola partición.

Si el clúster estaba inicialmente equilibrado, pero luego desarrolló una distribución desigual de datos, considere las siguientes posibles causas:

• Ha eliminado una cantidad significativa de datos del clúster. Si ha añadido datos adicionales, es posible que su distribución sea diferente según su clave de fragmento.

• Su clave de fragmento tiene baja cardinalidad y MongoDB no puede dividir más los fragmentos.

• Su conjunto de datos crece a una velocidad mayor a la que el balanceador puede distribuir los datos en el clúster. Esto es poco común y suele deberse a:

  • una ventana de equilibrio demasiado corta, dada la tasa de crecimiento de los datos.

  • Una distribución desigual de las operaciones de escritura requiere mayor migración de datos. Es posible que deba elegir una clave de fragmento diferente para resolver este problema.

  • Mala conectividad de red entre fragmentos, lo que puede provocar migraciones de fragmentos demasiado largas. Investigue la configuración de red y las interconexiones entre fragmentos.

¿Por qué las migraciones de fragmentos afectan el rendimiento del clúster fragmentado?

Si las migraciones afectan el rendimiento de su clúster o aplicación, considere las siguientes opciones, según la naturaleza del impacto:

1. Si las migraciones solo interrumpen sus clústeres esporádicamente, puede limitar la ventana de balanceo para evitar la actividad de balanceo durante las horas punta. Asegúrese de que haya suficiente tiempo restante para evitar que los datos se desequilibren nuevamente.

2. Si el equilibrador siempre está migrando fragmentos en detrimento del rendimiento general del clúster:

   • Es posible que desees intentar reducir el tamaño del fragmento para limitar el tamaño de la migración.

   • Es posible que su clúster supere su capacidad y que desee intentar agregar uno o dos fragmentos al clúster para distribuir la carga.

También es posible que la clave de su fragmento haga que su aplicación dirija todas las escrituras a un solo fragmento. Este tipo de patrón de actividad puede requerir que el balanceador migre la mayoría de los datos poco después de escribirlos. Quizás deba considerar volver a fragmentar su colección con una clave de fragmento diferente que ofrezca un mejor escalado de escritura.