Notas de producción para implementaciones autogestionadas

WiredTiger

El motor de almacenamiento WiredTiger es multihilo y puede aprovechar núcleos de CPU adicionales. Específicamente, el número total de subprocesos activos (es decir, operaciones concurrentes) en relación con el número de CPU disponibles pueden afectar el rendimiento:

• El rendimiento aumenta a medida que el número de operaciones activas simultáneas aumenta hasta igualar el número de CPUs.

• El rendimiento disminuye a medida que el número de operaciones activas simultáneas supera el número de CPUs por cierta cantidad de umbral.

El umbral depende de su aplicación. Puede determinarse el número óptimo de operaciones activas concurrentes para su aplicación experimentando y midiendo el rendimiento. La salida de mongostat proporciona estadísticas sobre la cantidad de lecturas/guardados activas en la columna (ar|aw).

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.

Compresión y cifrado

Al utilizar el cifrado, las CPU equipadas con extensiones del conjunto de instrucciones AES-NI muestran ventajas significativas de rendimiento. Si estás utilizando MongoDB Enterprise con el motor de almacenamiento cifrado, elige una CPU que admita AES-NI para un mejor rendimiento.

Configurar NUMA en Windows

En Windows, el entrelazado de memoria debe habilitarse a través del BIOS de la máquina. Se debe consultar la documentación del sistema para obtener detalles.

Configuración de NUMA en Linux

En Linux, debes deshabilitar recuperación de zona y también garantizar que las instancias mongod y mongos se inicien mediante numactl, que generalmente se configura a través del sistema de inicialización de la plataforma. Se deben realizar ambas operaciones para deshabilitar correctamente NUMA para su uso con MongoDB.

1. Desactiva zona reclaim con uno de los siguientes comandos:

   echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode

   sudo sysctl -w vm.zone_reclaim_mode=0

2. Es necesario garantizar que mongod y mongos sean iniciados por numactl. Esto generalmente se configura a través del sistema de inicialización de la plataforma. Se debe ejecutar el siguiente comando para determinar qué sistema de inicialización está en uso en la plataforma:

   ps --no-headers -o comm 1

   • Si "systemd", la plataforma utiliza el sistema de inicialización systemd, y se debe seguir los pasos en la pestaña systemd a continuación para editar los archivos de servicio de MongoDB.

   • Si "init", la plataforma utiliza el sistema de inicialización SysV Init, y no se necesita realizar este paso. El script de inicio predeterminado de MongoDB para SysV Init incluye los pasos necesarios para iniciar instancias de MongoDB a través de numactl por defecto.

   • Si gestionas tus propios scripts de inicio (es decir, no estás utilizando ninguno de estos sistemas de inicialización), debes seguir los pasos en la pestaña Scripts de inicio personalizados a continuación para editar tus scripts de inicio personalizados.

     
     
   systemd

   Scripts de inicio personalizados

   Debes usar numactl para iniciar cada una de tus instancias demongod, incluyendo todos los servidores de configuración, instancias demongos y clientes. Edita el archivo de servicio systemd por defecto para cada uno de la siguiente manera:

   1. Copia el archivo de servicio por defecto de MongoDB:

      sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/

   2. Edita el archivo /etc/systemd/system/mongod.service y actualiza la instrucción ExecStart para que comience con:

      /usr/bin/numactl --interleave=all

      Ejemplo

      Si la instrucción ExecStart actual dice:

      ExecStart=/usr/bin/mongod --config /etc/mongod.conf

      Actualizar esa instrucción para que diga:

      ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf

   3. Aplicar el cambio a systemd:

      sudo systemctl daemon-reload

   4. Reiniciar cualquier instancia de mongod en ejecución:

      sudo systemctl stop mongod
      sudo systemctl start mongod

   5. Si corresponde, repita estos pasos para cualquier instancia de mongos.

   Debes usar numactl para iniciar cada una de tus instancias demongod, incluyendo todos los servidores de configuración, instancias demongos y clientes.

   1. Instalar numactl para la plataforma si aún no está instalado. Consultar la documentación del sistema operativo para obtener información sobre la instalación del paquete numactl.

   2. Configura cada uno de tus scripts de inicio personalizados para iniciar cada instancia de MongoDB mediante numactl:

      numactl --interleave=all <path> <options>

      Donde <path> es la ruta al programa que está iniciando y <options> son los argumentos opcionales para pasar a ese programa.

      Ejemplo

      numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

Para obtener más información, consulte la Documentación para /proc/sys/vm/*.

Swap

MongoDB funciona mejor cuando se puede evitar el intercambio o mantenerlo al mínimo, ya que recuperar datos del swap siempre es más lento que acceder a los datos en RAM. Sin embargo, si el sistema que aloja MongoDB se queda sin RAM, el intercambio puede evitar que el OOM Killer de Linux termine el proceso mongod.

En general, debe elegir una de las siguientes estrategias de intercambio:

1. Asigne espacio de intercambio en su sistema y configure el kernel para que solo permita el intercambio bajo alta carga de memoria, o

2. No asignar espacio de intercambio en el sistema y configurar el kernel para desactivar completamente el intercambio

Se debe consultar Establecer vm.swappiness para obtener instrucciones sobre cómo configurar el swap en el sistema Linux siguiendo estas directrices.

RAID

Para un rendimiento óptimo en términos de la capa de almacenamiento, utiliza discos respaldados por RAID-10. RAID-5 y RAID-6 generalmente no proporcionan un rendimiento suficiente para soportar una implementación de MongoDB.

Sistemas de archivos remotos (NFS)

Con el motor de almacenamiento WiredTiger, los objetos de WiredTiger pueden almacenarse en sistemas de archivos remotos si el sistema de archivos remoto cumple con la norma ISO/IEC 9945-1:1996 (POSIX.1). Dado que los sistemas de archivos remotos suelen ser más lentos que los sistemas de archivos locales, el uso de un sistema de archivos remoto para el almacenamiento puede degradar el rendimiento.

Si se utiliza NFS, añadir las siguientes opciones NFS al archivo /etc/fstab:

• bg

• hard

• nolock

• noatime

• nointr

Dependiendo de la versión del kernel, algunos de estos valores ya pueden estar establecidos por defecto. Se debe consultar la documentación de la plataforma para obtener más información.

Separar los componentes en diferentes dispositivos de almacenamiento

Para mejorar el rendimiento, se debe considerar separar los datos, la bitácora y los registros de la base de datos en diferentes dispositivos de almacenamiento, según el patrón de acceso y escritura de la aplicación. Se deben montar los componentes como sistemas de archivos separados y se deben usar enlaces simbólicos para asignar la ruta de cada componente al dispositivo que lo almacena.

Para el motor de almacenamiento WiredTiger, también puede almacenar los índices en un dispositivo de almacenamiento diferente. Consulte storage.wiredTiger.engineConfig.directoryForIndexes.

Cronograma

Kernel y sistemas de archivos

Cuando ejecutes MongoDB en producción en Linux, debes usar la versión 2.6.36 o posterior del kernel de Linux, con el sistema de archivos XFS o EXT4. Si es posible, utiliza XFS, ya que generalmente ofrece un mejor rendimiento con MongoDB.

Con el motor de almacenamiento WiredTiger, se recomienda encarecidamente utilizar XFS para los nodos que contienen datos para evitar problemas de rendimiento que puedan surgir al usar EXT4 con WiredTiger.

• En general, si se utiliza el sistema de archivos XFS, utilizar al menos la versión 2.6.25 del Kernel de Linux.

• Si se utiliza el sistema de archivos EXT4, usar al menos la versión 2.6.28 del Kernel de Linux.

• En Red Hat Enterprise Linux y CentOS, utiliza al menos la versión 2.6.18-194 del kernel de Linux.

Librería del sistema C

MongoDB utiliza la GNU C Library (glibc) en Linux. Generalmente, cada distribución de Linux ofrece su propia versión verificada de esta biblioteca. Para obtener los mejores resultados, utiliza la última actualización disponible para esta versión proporcionada por el sistema. Puedes comprobar si tiene la última versión instalada usando el administrador de paquetes de su sistema. Por ejemplo:

• En RHEL / CentOS, el siguiente comando actualiza la librería GNU C proporcionada por el sistema:

  sudo yum update glibc

• En Ubuntu/Debian, el siguiente comando actualiza la librería GNU C proporcionada por el sistema:

  sudo apt-get install libc6

fsync() en los directorios

Establezca vm.swappiness en 1 o 0

"Swappiness" es un ajuste del kernel de Linux que afecta el comportamiento del administrador de memoria virtual. La configuración de vm.swappiness tiene un rango de 0 a 100: cuanto mayor sea el valor, la preferencia será intercambiar páginas de memoria al disco en lugar de eliminar páginas de la RAM.

• Una configuración de 0 desactiva el intercambio por completo [8].

• Una configuración de 1 permite al kernel intercambiar solo para evitar problemas de falta de memoria.

• Una configuración de 60 indica al kernel que intercambie al disco con frecuencia, y es el valor por defecto en muchas distribuciones de Linux.

• Una configuración de 100 indica al kernel que intercambie agresivamente al disco.

MongoDB rinde mejor cuando se evita o se minimiza el intercambio. Por lo tanto, se debería establecer vm.swappiness en 1 o 0 según las necesidades de la aplicación y la configuración del clúster.

• Para comprobar la configuración actual de swappiness en el sistema, se debe ejecutar:

  cat /proc/sys/vm/swappiness

• Para cambiar la swappiness en su sistema:

  1. Edite el archivo /etc/sysctl.conf y añada la siguiente línea:

     vm.swappiness = 1

  2. Ejecute el siguiente comando para aplicar la configuración:

     sudo sysctl -p

Configuración recomendada

Para todas las implementaciones de MongoDB:

• Utilizar el protocolo de Tiempo de Red (NTP) para sincronizar el tiempo entre los hosts. Esto es especialmente importante en clústeres particionados.

Para los motores de almacenamiento WiredTiger, considere las siguientes recomendaciones:

• Desactiva atime para el volumen de almacenamiento que contiene los archivos de la base de datos.

• Se debe ajustar la configuración ulimit de la plataforma de acuerdo con las recomendaciones en la referencia de ulimit. Los valores bajos de ulimit afectarán negativamente a MongoDB cuando se utilice intensamente y pueden provocar conexiones fallidas a los procesos de MongoDB y la pérdida del servicio.

  Nota

  Si el valor ulimit para el número de archivos abiertos es inferior a 64000, MongoDB genera una advertencia de inicio.

• Si estás ejecutando MongoDB 8.0, habilita Transparent Hugepages.

  • Si estás ejecutando MongoDB 7.0 o una versión anterior, desactiva Transparent Hugepages. En versiones anteriores, MongoDB rinde mejor con páginas de memoria virtual típicas (4096 bytes).

• Se debe desactivar NUMA en el BIOS. Si eso no es posible, se debe consultar MongoDB sobre hardware NUMA.

• Configura SELinux para MongoDB si no estás utilizando las rutas de directorio por defecto de MongoDB o puertos.

  Nota

  Si está utilizando SELinux, cualquier operación de MongoDB que requiera JavaScript del lado del servidor resultará en errores de segmentación. Deshabilitar la ejecución de JavaScript del lado del servidor describe cómo deshabilitar la ejecución de JavaScript del lado del servidor.

Para el motor de almacenamiento WiredTiger:

• Establecer la configuración de lectura anticipada entre 8 y 32, independientemente del tipo de medio de almacenamiento (disco giratorio, SSD, etc.).

  Un mayor lectura anticipada suele beneficiar a las operaciones de E/S secuenciales. Dado que los patrones de acceso a disco de MongoDB son generalmente aleatorios, el uso de configuraciones de lectura anticipada más altas proporciona un beneficio limitado o una posible degradación del rendimiento. Por lo tanto, para un rendimiento óptimo de MongoDB, se debe configurar la lectura anticipada entre 8 y 32, a menos que las pruebas demuestren un beneficio medible, repetible y confiable en un valor de lectura anticipada más alto. El soporte comercial de MongoDB puede ofrecer consejos y orientación sobre configuraciones alternativas de lectura anticipada.

MongoDB y bibliotecas TLS/SSL

En plataformas Linux, puede observar una de las siguientes instrucciones en el registro de MongoDB:

<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod)
<path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)

Estas advertencias indican que las librerías TLS/SSL del sistema son diferentes de las bibliotecas TLS/SSL contra las que se compiló el mongod. Por lo general, estos mensajes no requieren intervención; sin embargo, puedes utilizar las siguientes operaciones para determinar las versiones del símbolo que mongod espera:

objdump -T <path to mongod>/mongod | grep " SSL_"
objdump -T <path to mongod>/mongod | grep " CRYPTO_"

Estas operaciones devolverán un resultado que se asemeja a una de las siguientes líneas:

0000000000000000      DF *UND*       0000000000000000  libssl.so.10 SSL_write
0000000000000000      DF *UND*       0000000000000000  OPENSSL_1.0.0 SSL_write

Las dos últimas cadenas de esta salida son la versión del símbolo y el nombre del símbolo. Compara estos valores con los valores devueltos por las siguientes operaciones para detectar desajustes de versión de símbolos:

objdump -T <path to TLS/SSL libs>/libssl.so.1*
objdump -T <path to TLS/SSL libs>/libcrypto.so.1*

Este procedimiento no es ni exacto ni exhaustivo: muchos símbolos utilizados por mongod de la biblioteca libcrypto no comienzan con CRYPTO_.

AWS EC2

Existen dos configuraciones de rendimiento que se deben considerar:

• Rendimiento reproducible para pruebas de rendimiento o benchmarking, y

• Rendimiento máximo en bruto

Para ajustar el rendimiento en EC2 para cualquiera de las dos configuraciones, debe:

• Se debe habilitar AWS Enhanced Networking para la instancia. No todos los tipos de instancias admiten Enhanced Networking.

  Para aprender más sobre Enhanced Networking, consulta la documentación de AWS.

• Configura tcp_keepalive_time a 120.

Si se prioriza un rendimiento reproducible en EC2, también se recomienda:

• Utilizar IOPS aprovisionadas para el almacenamiento, con dispositivos separados para la bitácora y los datos. No utilizar el almacenamiento efímero (SSD) disponible en la mayoría de los tipos de instancia, ya que su rendimiento cambia de un momento a otro. (La serie i es una excepción notable, pero muy costosa).

• Desactivar DVFS y las modas de ahorro de energía de la CPU.

  Tip

  Documentación de Amazon sobre el Control del Estado del Procesador

• Deshabilita el hiperthreading.

  Tip

  Entrada de blog de Amazon sobre la desactivación de Hyper-Threading.

• Utilizar numactl para vincular la localidad de memoria a un solo socket.

Azure

Utilice Almacenamiento Premium. Microsoft Azure ofrece dos tipos generales de almacenamiento: almacenamiento estándar y almacenamiento Premium. MongoDB en Azure tiene un mejor rendimiento cuando se utiliza el almacenamiento Premium que cuando se utiliza el almacenamiento estándar.

VMware

MongoDB es compatible con VMware.

VMware admite la sobrecarga de memoria, que permite asignar más memoria a las máquinas virtuales de la que tiene disponible la máquina física. Cuando la memoria está sobrecargada, el hipervisor reasigna la memoria entre las máquinas virtuales. El controlador de memoria de VMware (vmmemctl) recupera las páginas que se consideran menos valiosas.

El controlador de globo reside dentro del sistema operativo invitado. Bajo ciertas configuraciones, cuando el controlador de globo se expande, puede interferir con la gestión de memoria de MongoDB y afectar su rendimiento.

Para evitar un impacto negativo en el rendimiento por el controlador de globo y las características de sobrecarga de memoria, reserva la cantidad total de memoria para la máquina virtual que ejecuta MongoDB. Reservar la cantidad adecuada de memoria para la máquina virtual evita que el globo se infle en el sistema operativo local cuando hay presión de memoria en el hipervisor.

Aunque las características del controlador de globo y la sobreasignación de memoria pueden afectar negativamente el rendimiento de MongoDB en ciertas configuraciones, no desactives estas características. Si desactivas estas características, el hipervisor puede usar su espacio de intercambio para cumplir con las solicitudes de memoria, lo que afecta negativamente el rendimiento.

Asegúrate de que las máquinas virtuales permanezcan en un host ESX/ESXi específico configurando las reglas de afinidad de VMware. Si debes migrar manualmente una máquina virtual a otro host y la instancia mongod en la máquina virtual es la primaria, primero debes step down la primaria y luego shut down the instance.

Sigue las prácticas recomendadas de redes para vMotion y VMKernel. No seguir las prácticas recomendadas puede resultar en problemas de rendimiento y afectar los mecanismos de alta disponibilidad de sets de réplicas y clústeres particionados.

Se puede clonar una máquina virtual que ejecuta MongoDB. Es posible utilizar esta función para implementar un nuevo host virtual y añadirlo como un nodo de un set de réplicas.

KVM

MongoDB es compatible con KVM.

KVM admite la sobrecarga de memoria, la cual permite asignar más memoria a sus máquinas virtuales de la que tiene disponible la máquina física. Cuando la memoria está sobrecargada, el hipervisor reasigna la memoria entre las máquinas virtuales. El controlador de memoria de KVM recupera las páginas que se consideran menos valiosas.

El controlador de globo reside dentro del sistema operativo invitado. Bajo ciertas configuraciones, cuando el controlador de globo se expande, puede interferir con la gestión de memoria de MongoDB y afectar su rendimiento.

Para evitar un impacto negativo en el rendimiento por el controlador de globo y las características de sobrecarga de memoria, reserva la cantidad total de memoria para la máquina virtual que ejecuta MongoDB. Reservar la cantidad adecuada de memoria para la máquina virtual evita que el globo se infle en el sistema operativo local cuando hay presión de memoria en el hipervisor.

Aunque las características del controlador de globo y la sobreasignación de memoria pueden afectar negativamente el rendimiento de MongoDB en ciertas configuraciones, no desactives estas características. Si desactivas estas características, el hipervisor puede usar su espacio de intercambio para cumplir con las solicitudes de memoria, lo que afecta negativamente el rendimiento.