Preguntas frecuentes: Diagnóstico de MongoDB autogestionado

Ajuste del valor keepalive de TCP:

Deberás reiniciar los procesos de mongod y mongos para que los nuevos ajustes del sistema keepalive tengan 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 predeterminado del tamaño de la memoria caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene múltiples instancias de MongoDB, entonces debes disminuir la configuración para alojar las otras instancias de mongod.

Si se ejecuta mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, se debe establecer storage.wiredTiger.engineConfig.cacheSizeGB en un valor inferior a la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los otros procesos que se ejecutan en el contenedor. Ver memLimitMB.

Para ver las estadísticas sobre el caché y la expulsión, utiliza el comando serverStatus. El campo wiredTiger.cache contiene la información sobre el almacenamiento en caché y el 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 clave de caché y expulsión, como wiredTiger.cache.bytes currently in the cache y wiredTiger.cache.tracked dirty bytes in the cache, consulte wiredTiger.cache.

Para ajustar el tamaño de la caché interna de WiredTiger, consulta storage.wiredTiger.engineConfig.cacheSizeGB y --wiredTigerCacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto.

¿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.

El tamaño de caché interno por defecto de WiredTiger es el mayor de los siguientes:

• 50 % de (RAM - 1 GB), o

• 256 MB.

Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger utiliza 1.5GB de RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). Por el contrario, en un sistema con un total de 1.25 GB de RAM, WiredTiger asigna 256 MB a la caché de WiredTiger porque eso es más de la mitad de la RAM total menos un gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).

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 storage.wiredTiger.engineConfig.cacheSizeGB y --wiredTigerCacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto.

El valor predeterminado del tamaño de la memoria caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene múltiples instancias de MongoDB, entonces debes disminuir la configuración para alojar las otras instancias de mongod.

Si se ejecuta mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, se debe establecer storage.wiredTiger.engineConfig.cacheSizeGB en un valor inferior a la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los otros procesos que se ejecutan en el contenedor. Ver memLimitMB.

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 el particionado tenga sentido. El particionado funciona mediante la migración de fragmentos entre las particiones hasta que cada partición tenga aproximadamente el mismo número de fragmentos.

El tamaño por defecto del fragmento es 128 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 prevenir migraciones innecesarias de fragmentos, lo que puede degradar el rendimiento de su clúster en general.

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 fragmentos de 128 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 un problema relacionado, el sistema solo dividirá los fragmentos en caso de inserciones o actualizaciones, lo que significa que si configuras el particionado y no continúas emitiendo operaciones de inserción y actualizar, la base de datos no creará ningún fragmento. Puedes esperar hasta que tu aplicación inserte 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, una única partición o un subconjunto del clúster recibirán una porción desproporcionada del tráfico y la carga de trabajo. En casi todos los casos este es el resultado de una clave de partición que no permite efectivamente el escalado de escritura.

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

Puede que tengas que considerar reasignar fragmentos de tu colección con una clave de partición diferente para corregir este patrón.

¿Qué puede impedir el equilibrio de un clúster fragmentado?

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 equilibrado inicialmente, pero más tarde se produjo 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.

• Conjunto de datos está creciendo más rápido de lo que el balanceador puede distribuir datos en el clúster. Esto es poco común y suele ser el resultado de:

  • una ventana de equilibrio que es demasiado corta, dado el ritmo de crecimiento de los datos.

  • una distribución desigual de operaciones de guardar que requiere una mayor migración de datos. Puede que tengas que seleccionar una clave de partición 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 tu clúster o aplicación, considera las siguientes opciones, dependiendo de la naturaleza del impacto:

1. Si las migraciones solo interrumpen esporádicamente tus clusters, puedes limitar la ventana de balanceo para evitar actividades de balanceo durante las horas pico. Asegúrate de que quede suficiente tiempo para evitar que los datos vuelvan a desequilibrarse.

2. Si el balanceador 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 tu clúster esté por encima de su capacidad, y que quieras intentar añadir una o dos particiones al clúster para distribuir la carga.

También es posible que tu clave de partición provoque que tu aplicación dirija todas las escrituras a una sola partición. Este tipo de patrón de actividad puede requerir que el balanceador migre la mayor parte de los datos poco tiempo después de escribirlos. Es posible que debas considerar reorganizar los fragmentos de tu colección con una clave de partición diferente que proporcione un mejor escalado de guardado.