Preguntas frecuentes: Diagnóstico de MongoDB autogestionado

Este documento proporciona respuestas a preguntas y problemas comunes de diagnóstico.

Si no encuentras la respuesta que buscas, revisa el lista completa de Preguntas Frecuentes o publica tu pregunta en el MongoDB Community.

¿Dónde puedo encontrar información sobre un `mongod` ¿proceso que dejó de ejecutarse inesperadamente?

Si mongod se apaga inesperadamente en una plataforma UNIX o basada en UNIX, y si mongod no logra registrar un apagado o mensaje de error, entonces verifique sus registros del sistema para mensajes relacionados con MongoDB. Por ejemplo, para los registros ubicados en /var/log/messages, utiliza los siguientes comandos:

sudo grep mongod /var/log/messages
sudo grep score /var/log/messages

¿El tiempo TCP afecta las implementaciones de MongoDB?`keepalive`

Si experimenta tiempos de espera de red o errores de socket en la comunicación entre clientes y servidores, o entre miembros de un clúster fragmentado o un conjunto de réplicas, verifique el valor de keepalive de TCP para los sistemas afectados.

Muchos sistemas operativos establecen este valor en 7200 segundos (dos horas) por defecto. Para MongoDB, generalmente tendrás mejores resultados con un valor keepalive más corto, del orden de 120 segundos (dos minutos).

Si tu implementación de MongoDB experimenta problemas relacionados con keepalive, debes modificar el valor keepalive en todos los sistemas afectados. Esto incluye todas las máquinas que ejecutan mongod o mongos, así como todas las máquinas que alojan procesos cliente que se conectan a MongoDB.

Ajuste del valor keepalive de TCP:

Para ver la configuración de keepalive en Linux, utilice uno de los siguientes comandos:
```
sysctl net.ipv4.tcp_keepalive_time
```
O:
```
cat /proc/sys/net/ipv4/tcp_keepalive_time
```
El valor se mide en segundos.
Nota
Aunque el nombre de la configuración incluye ipv4, el valor tcp_keepalive_time se aplica tanto a IPv4 como a IPv6.
Para cambiar el tcp_keepalive_time valor, puedes utilizar uno de los siguientes comandos, proporcionando un <value> en segundos:
```
sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>
```
O:
```
echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time
```
Estas operaciones no persisten a través de los reinicios del sistema. Para persistir la configuración, añade la siguiente línea a /etc/sysctl.conf, proporcionando un <value> en segundos, y reinicia el equipo:
```
net.ipv4.tcp_keepalive_time = <value>
```
Los valores de Keepalive mayores que 300 segundos, (5 minutos) serán anulados en los sockets de mongod y mongos y se establecerán en 300 segundos.

Para ver la configuración de keepalive en Windows, emita el siguiente comando:
```
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime
```
El valor del registro no está presente por defecto. El valor por defecto del sistema, utilizado si el valor está ausente, es 7200000 milisegundos o 0x6ddd00 en hexadecimal.
Para cambiar el valor de KeepAliveTime, use el siguiente comando como Administrador Command Prompt, donde <value> se expresa en hexadecimal (por ejemplo, 120000 es 0x1d4c0):
```
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>
```
Los usuarios de Windows deberían considerar el artículo de Technet de Windows Server sobre KeepAliveTime para obtener más información sobre cómo configurar keepalive para implementaciones de MongoDB en sistemas Windows. Los valores de keepalive mayores o iguales a 600000 milisegundos (10 minutos) serán ignorados por mongod y mongos.

Para ver la configuración de keepalive en macOS, ejecute el siguiente comando:
```
sysctl net.inet.tcp.keepidle
```
El valor se mide en milisegundos.
Para cambiar el net.inet.tcp.keepidle valor, puede utilizar el siguiente comando, proporcionando un <value> en milisegundos:
```
sudo sysctl net.inet.tcp.keepidle=<value>
```
Esta operación no persiste después de los reinicios del sistema y debe configurarse cada vez que el sistema se reinicie. Consulta la documentación de tu sistema operativo para obtener instrucciones sobre cómo establecer este valor de manera persistente. Los valores de Keepalive mayores o iguales a 600000 milisegundos (10 minutos) serán ignorados por mongod y mongos.
Nota
En macOS 10.15 Catalina, Apple ya no permite la configuración de la opción net.inet.tcp.keepidle.

Deberás reiniciar los procesos de mongod y mongos para que los nuevos ajustes del sistema keepalive tengan efecto.

¿Los TCP Retransmission Timeouts afectan las implementaciones de MongoDB?

Si se experimentan demoras prolongadas (de más de dos minutos) seguidas de timeout de red o errores de socket entre clientes y servidores o entre nodos de un clúster o un set de réplicas, se debe verificar el valor de tcp_retries2 en los sistemas afectados.

La mayoría de los sistemas operativos Linux establecen este valor en 15 por defecto, mientras que Windows lo establece en 5. Para MongoDB, experimentarás mejores resultados con un menor valor de tcp_retries2, en el orden de 5 (12 segundos) o menor.

Si tu implementación de MongoDB experimenta problemas relacionados con el tiempo de espera de retransmisión TCP, cambia el valor tcp_retries2 (TcpMaxDataRetransmission en Windows) para todos los sistemas afectados. Esto incluye todas las máquinas que ejecutan mongod o mongos procesos y todas las máquinas que alojan clientes que se conectan a MongoDB.

Ajustar el tiempo de espera de retransmisión TCP

En la mayoría de los sistemas operativos Linux, controla la retransmisión TCP ajustando la configuración sysctl net.ipv4.tcp_retries2.

Nota

Aunque el nombre de la configuración incluye ipv4, la configuración tcp_retries2 se aplica tanto a IPv4 como a IPv6.

Para ver la configuración actual, usa el comando sysctl:
sysctl net.ipv4.tcp_retries2
net.ipv4.tcp_retries = 15
Para cambiar la configuración de tcp_retries2 en tiempo de ejecución, utilice el comando sysctl:
```
sysctl -w net.ipv4.tcp_retries2=8
```
Para hacer el cambio permanente, edita el archivo de configuración:
1. Abra /etc/sysctl.conf en su editor de texto preferido:
  vi /etc/sysctl.conf
2. Configure el ajuste net.ipv4.tcp_retries2:
  net.ipv4.tcp_retries2 = 8
3. Reinicie el sistema.
Tu sistema ahora utiliza el nuevo ajuste tcp_retries2.

En Windows, control la retransmisión TCP ajustando el parámetro TcpMaxDataRetransmissions.

Para ver la configuración TcpMaxDataRetransmissions en Windows, ejecute este comando:
```
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxDataRetransmissions
```
Por defecto, el parámetro no está configurado. La configuración por defecto del sistema, que se utiliza si falta el valor, es 5 reintentos.
Para cambiar el valor de TcpMaxDataRetransmissions, utiliza el siguiente comando en un Command Prompt de administrador, donde <value> es un número entero:
```
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v TcpMaxDataRetransmission /d <value>
```

¿Por qué MongoDB registra tantos eventos "Connection Accepted" (Conexión aceptada)?

Si ves un número muy grande de mensajes de conexión y reconexión en tu registro de MongoDB, significa que los clientes se están conectando y desconectando del servidor MongoDB con frecuencia. Este es el comportamiento normal para aplicaciones que no utilizan pooling de solicitudes, como CGI. Considera usar FastCGI, un módulo de Apache u otro tipo de servidor de aplicaciones persistente para reducir la sobrecarga de conexiones.

Si estas conexiones no afectan el rendimiento, puede utilizar la opción de tiempo de ejecución quiet o la opción de línea de comandos --quiet para suprimir estos mensajes del registro.

¿Qué herramientas están disponibles para la supervisión de MongoDB?

El MongoDB Cloud Manager y el Ops Manager, una solución on-premises disponible en MongoDB Enterprise Advanced incluyen una funcionalidad de supervisión, que recopila datos de implementaciones de MongoDB en ejecución y proporciona visualización y alertas basadas en esos datos.

Para obtener más información, vea también la documentación de MongoDB Cloud Manager y la documentación de Ops Manager.

Se puede acceder a una lista completa de herramientas de terceros como parte de la documentación Supervisión de una implementación autogestionada de MongoDB.

Diagnóstico de memoria para el motor de almacenamiento WiredTiger

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

Nota

El storage.wiredTiger.engineConfig.cacheSizeGB limita el tamaño de la caché interna de WiredTiger. El sistema operativo utiliza la memoria libre disponible para la caché del sistema de archivos, lo que permite que los archivos de datos comprimidos de MongoDB permanezcan en la memoria. Además, el sistema operativo utiliza cualquier RAM libre para almacenar en búfer los bloques del sistema de archivos y la caché del sistema de archivos.

Para acomodar a los consumidores adicionales de RAM, es posible que debas reducir el tamaño de la caché interna de WiredTiger.

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 ejecutas mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debes establecer storage.wiredTiger.engineConfig.cacheSizeGB o storage.wiredTiger.engineConfig.cacheSizePct a 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. Consulta memLimitMB.

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

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

Configuración de caché

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

El 50% de (RAM - 1GB), o
0.256 GB.

Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger usa 1.5GB de RAM (0.5 * (4GB - 1GB) = 1.5 GB). Al proporcionar un tamaño de caché específico, asegúrese de que la RAM no supere los límites de 0.256GB a 10000GB.

Evita aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado. Si tu caso requiere hacerlo, puedes usar --wiredTigerCacheSizePct para contabilizar cambios de memoria debido a aumentos verticales. Debes especificar un porcentaje de hasta un 80% de la memoria disponible. Los valores calculados pueden oscilar entre 0.256GB y 10000GB. Por ejemplo, en un sistema con 2GB de RAM, el --wiredTigerCacheSizePct no puede configurarse en 10 porque el 10% de 2GB es 0.2 GB, lo que es menor que 0.256GB.

Nota

En algunos casos, como al ejecutarse en un contenedor configurado para usar menos RAM que la memoria asignada al host, es necesario tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger con un valor adecuado, ya que WiredTiger podría no tener en cuenta los límites de memoria del contenedor específico en ciertos casos.

Para ver, el valor que WiredTiger utiliza como memory limit hostInfo la cantidad máxima de RAM disponible, utilice el comando.

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.

Nota

Para acomodar a los consumidores adicionales de RAM, es posible que debas reducir el tamaño de la caché interna de WiredTiger.

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.

Diagnóstico de clúster fragmentado

Los dos factores más importantes para mantener un clúster particionado exitoso son:

Si bien puedes cambiar tu clave de partición más tarde, es importante considerar cuidadosamente tu elección de clave de partición para evitar problemas de escalabilidad y rendimiento. Continúa leyendo para conocer los problemas específicos que podrías encontrar en un entorno de producción.

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:

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

Volver

Supervisar clústeres

Gestión

¿El tiempo TCP afecta las implementaciones de MongoDB?keepalive

Ajuste del valor keepalive de TCP:

Nota

Nota

¿Los TCP Retransmission Timeouts afectan las implementaciones de MongoDB?

Ajustar el tiempo de espera de retransmisión TCP

Nota

¿Por qué MongoDB registra tantos eventos "Connection Accepted" (Conexión aceptada)?

¿Qué herramientas están disponibles para la supervisión de MongoDB?

Diagnóstico de memoria para el motor de almacenamiento WiredTiger

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

Nota

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

Configuración de caché

Nota

Nota

Diagnóstico de clúster fragmentado

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

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

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

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

¿El tiempo TCP afecta las implementaciones de MongoDB?`keepalive`