sql >> Base de Datos >  >> NoSQL >> MongoDB

Una hoja de trucos de rendimiento para MongoDB

El rendimiento de la base de datos afecta el rendimiento de la organización y tendemos a querer buscar una solución rápida. Hay muchas vías diferentes para mejorar el rendimiento en MongoDB. En este blog, lo ayudaremos a comprender mejor la carga de trabajo de su base de datos y las cosas que pueden dañarla. El conocimiento de cómo usar recursos limitados es esencial para cualquiera que administre una base de datos de producción.

Le mostraremos cómo identificar los factores que limitan el rendimiento de la base de datos. Para garantizar que la base de datos funcione como se espera, comenzaremos con la herramienta de monitoreo gratuita MongoDB Cloud. Luego, veremos cómo administrar los archivos de registro y cómo examinar las consultas. Para poder lograr un uso óptimo de los recursos de hardware, analizaremos la optimización del kernel y otras configuraciones cruciales del sistema operativo. Finalmente, veremos la replicación de MongoDB y cómo examinar el rendimiento.

Supervisión gratuita del rendimiento

MongoDB presentó una herramienta de monitoreo de rendimiento gratuita en la nube para instancias independientes y conjuntos de réplicas. Cuando está habilitado, los datos monitoreados se cargan periódicamente al servicio en la nube del proveedor. Eso no requiere ningún agente adicional, la funcionalidad está integrada en el nuevo MongoDB 4.0+. El proceso es bastante simple de configurar y administrar. Después de la activación del comando único, obtendrá una dirección web única para acceder a sus estadísticas de rendimiento recientes. Solo puede acceder a los datos monitoreados que se cargaron en las últimas 24 horas.

Aquí se explica cómo activar esta función. Puede habilitar/deshabilitar el monitoreo gratuito durante el tiempo de ejecución usando:

-- Enable Free Monitoring
db.enableFreeMonitoring()
-- Disable Free Monitoring
db.disableFreeMonitoring()

También puede habilitar o deshabilitar el monitoreo gratuito durante el inicio de mongod usando la configuración del archivo de configuración cloud.monitoring.free.state o la opción de línea de comando --enableFreeMonitoring

db.enableFreeMonitoring()

Después de la activación, verá un mensaje con el estado actual.

{
    "state" : "enabled",
    "message" : "To see your monitoring data, navigate to the unique URL below. Anyone you share the URL with will also be able to view this page. You can disable monitoring at any time by running db.disableFreeMonitoring().",
    "url" : "https://cloud.mongodb.com/freemonitoring/cluster/XEARVO6RB2OTXEAHKHLKJ5V6KV3FAM6B",
    "userReminder" : "",
    "ok" : 1
}

Simplemente copie y pegue la URL de la salida de estado en el navegador y podrá comenzar a verificar las métricas de rendimiento.

El monitoreo gratuito de MongoDB proporciona información sobre las siguientes métricas:

  • Tiempos de ejecución de operaciones (LEER, ESCRIBIR, COMANDOS)
  • Utilización del disco (% DE UTILIDAD MÁXIMA DE CUALQUIER UNIDAD, % DE UTILIDAD PROMEDIO DE TODAS LAS UNIDADES)
  • Memoria (RESIDENTE, VIRTUAL, ASIGNADA)
  • Red - Entrada/Salida (BYTES DE ENTRADA, BYTES DE SALIDA)
  • Red:Núm. solicitudes (NÚM. SOLICITUDES)
  • Opcounters (INSERTAR, CONSULTAR, ACTUALIZAR, ELIMINAR, OBTENER MÁS, COMANDO)
  • Opcounters - Replicación (INSERTAR, CONSULTAR, ACTUALIZAR, ELIMINAR, OBTENER MÁS, COMANDO)
  • Segmentación de consultas (ESCANEADA/ DEVUELTA, OBJETOS ESCANEADOS/ DEVUELTA)
  • Colas (LECTORES, ESCRITORES, TOTAL)
  • Uso de la CPU del sistema (USUARIO, NICE, KERNEL, IOWAIT, IRQ, SOFT IRQ, STEAL, GUEST)
MongoDB Free Monitoring primer uso Uso de CPU del sistema de monitoreo gratuito MongoDB Gráficos de monitoreo gratuitos de MongoDB

Para ver el estado de su servicio de monitoreo gratuito, use el siguiente método:

db.getFreeMonitoringStatus()

serverStatus y el asistente db.serverStatus() también incluyen estadísticas de monitoreo gratuitas en el campo Monitoreo gratuito.

Cuando se ejecuta con control de acceso, el usuario debe tener los siguientes privilegios para habilitar el monitoreo gratuito y obtener el estado:

{ resource: { cluster : true }, actions: [ "setFreeMonitoring", "checkFreeMonitoringStatus" ] }

Esta herramienta puede ser un buen comienzo para aquellos a quienes les resulta difícil leer el estado del servidor MongoDB desde la línea de comandos:

db.serverStatus()

La supervisión gratuita es un buen comienzo, pero tiene opciones muy limitadas. Si necesita una herramienta más avanzada, puede consultar MongoDB Ops Manager o ClusterControl.

Registro de operaciones de la base de datos

Los controladores MongoDB y las aplicaciones cliente pueden enviar información al archivo de registro del servidor. Dicha información depende del tipo de evento. Para comprobar la configuración actual, inicie sesión como administrador y ejecute:

db.getLogComponents()

Los mensajes de registro incluyen muchos componentes. Esto es para proporcionar una categorización funcional de los mensajes. Para cada uno de los componentes, puede establecer un nivel de detalle de registro diferente. La lista actual de componentes es:

ACCESS, COMMAND, CONTROL, FTD, GEO, INDEX, NETWORK, QUERY, REPL_HB, REPL, ROLLBACK, REPL, SHARDING, STORAGE, RECOVERY, JOURNAL, STORAGE, WRITE.

Para más detalles sobre cada uno de los componentes, consulta la documentación.

Captura de consultas - Perfilador de base de datos

MongoDB Database Profiler recopila información sobre las operaciones que se ejecutan en una instancia de mongod. De forma predeterminada, el generador de perfiles no recopila ningún dato. Puede elegir recopilar todas las operaciones (valor 2), o aquellas que toman más tiempo que el valor de slowms . Este último es un parámetro de instancia que se puede controlar a través del archivo de configuración mongodb. Para comprobar el nivel actual:

db.getProfilingLevel()

Para capturar todas las consultas establecidas:

db.setProfilingLevel(2)

En el archivo de configuración, puede establecer:

profile = <0/1/2>
slowms = <value>

Esta configuración se aplicará en una única instancia y no se propagará a través de un conjunto de réplicas o un clúster compartido, por lo que debe repetir este comando en todos los nodos si desea capturar todas las actividades. La creación de perfiles de base de datos puede afectar el rendimiento de la base de datos. Habilite esta opción solo después de una cuidadosa consideración.

Luego para enumerar los 10 más recientes:

db.system.profile.find().limit(10).sort(
{ ts : -1 }
).pretty()

Para listar todos:

db.system.profile.find( { op:
{ $ne : 'command' }
} ).pretty()

Y para listar una colección específica:

db.system.profile.find(
{ ns : 'mydb.test' }
).pretty()

Registro de MongoDB

La ubicación del registro de MongoDB se define en la configuración de ruta de registro de su configuración y, por lo general, es /var/log/mongodb/mongod.log. Puede encontrar el archivo de configuración de MongoDB en /etc/mongod.conf.

Aquí hay datos de muestra:

2018-07-01T23:09:27.101+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Failed to connect to node1:27017 - HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Dropping all pooled connections to node1:27017 due to failed operation on a connection
2018-07-01T23:09:27.102+0000 I REPL_HB  [replexec-2] Error in heartbeat (requestId: 21589) to node1:27017, response status: HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017

Puede modificar el nivel de detalle del registro del componente configurando (ejemplo de consulta):

db.setLogLevel(2, "query")

El archivo de registro puede ser importante, por lo que es posible que desee borrarlo antes de crear perfiles. Desde la consola de línea de comandos de MongoDB, ingrese:

db.runCommand({ logRotate : 1 });

Comprobación de los parámetros del sistema operativo

Límites de memoria

Para ver los límites asociados con su inicio de sesión, use el comando ulimit -a. Los siguientes umbrales y configuraciones son particularmente importantes para las implementaciones de mongod y mongos:

-f (file size): unlimited
-t (cpu time): unlimited
-v (virtual memory): unlimited
-n (open files): 64000
-m (memory size): unlimited [1]
-u (processes/threads): 32000

La versión más reciente del script de inicio de mongod (/etc/init.d/mongod) tiene la configuración predeterminada integrada en la opción de inicio:

start()
{
  # Make sure the default pidfile directory exists
  if [ ! -d $PIDDIR ]; then
    install -d -m 0755 -o $MONGO_USER -g $MONGO_GROUP $PIDDIR
  fi

  # Make sure the pidfile does not exist
  if [ -f "$PIDFILEPATH" ]; then
      echo "Error starting mongod. $PIDFILEPATH exists."
      RETVAL=1
      return
  fi

  # Recommended ulimit values for mongod or mongos
  # See http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
  #
  ulimit -f unlimited
  ulimit -t unlimited
  ulimit -v unlimited
  ulimit -n 64000
  ulimit -m unlimited
  ulimit -u 64000
  ulimit -l unlimited

  echo -n $"Starting mongod: "
  daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mongod
}

La función del subsistema de administración de memoria, también llamado administrador de memoria virtual, es administrar la asignación de memoria física (RAM) para todo el kernel y los programas de usuario. Esto está controlado por los parámetros vm.*. Hay dos que debe considerar en primer lugar para ajustar el rendimiento de MongoDB:vm.dirty_ratio y vm.dirty_background_ratio .

vm.dirty_ratio es la cantidad máxima absoluta de memoria del sistema que se puede llenar con páginas sucias antes de que todo deba confirmarse en el disco. Cuando el sistema llega a este punto, todas las nuevas E/S se bloquean hasta que las páginas sucias se hayan escrito en el disco. Esta suele ser la fuente de largas pausas de E/S. El valor predeterminado es 30, que suele ser demasiado alto. vm.dirty_background_ratio es el porcentaje de la memoria del sistema que se puede llenar con páginas "sucias", páginas de memoria que aún deben escribirse en el disco. El buen comienzo es ir de 10 y medir rendimiento. Para un entorno con poca memoria, 20 es un buen comienzo. Una configuración recomendada para las proporciones sucias en servidores de bases de datos de gran memoria es vm.dirty_ratio =15 y vm.dirty_background_ratio =5 o posiblemente menos.

Para verificar la proporción de suciedad, ejecute:

sysctl -a | grep dirty

Puede configurar esto agregando las siguientes líneas a “/etc/sysctl.conf”:

Intercambio

En servidores donde MongoDB es el único servicio en ejecución, es una buena práctica configurar vm.swapiness =1. La configuración predeterminada se establece en 60, lo que no es apropiado para un sistema de base de datos.

vi /etc/sysctl.conf
vm.swappiness = 1

Páginas enormes transparentes

Si está ejecutando su MongoDB en RedHat, asegúrese de que las páginas gigantes transparentes estén deshabilitadas.
Esto se puede verificar con el comando:

cat /proc/sys/vm/nr_hugepages 
0

0 significa que las páginas grandes transparentes están deshabilitadas.

Opciones del sistema de archivos

ext4 rw,seclabel,noatime,data=ordered 0 0

NUMA (acceso a memoria no uniforme)

MongoDB no es compatible con NUMA, desactívelo en BIOS.

Pila de red

net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_max_syn_backlog = 4096

Demonio NTP

Para instalar el demonio del servidor de tiempo NTP, use uno de los siguientes comandos del sistema.

#Red Hat
sudo yum install ntp
#Debian
sudo apt-get install ntp

Puede encontrar más detalles sobre el rendimiento del sistema operativo para MongoDB en otro blog.

Explicar el plan

Al igual que otros sistemas de bases de datos populares, MongoDB proporciona una función de explicación que revela cómo se ejecutó una operación de base de datos. Los resultados de la explicación muestran los planes de consulta como un árbol de etapas. Cada etapa pasa sus eventos (es decir, documentos o claves de índice) al nodo principal. Los nodos de hoja acceden a la colección o a los índices. Puede agregar Explain('executionStats') a una consulta.

db.inventory.find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} ).explain('executionStats');
or append it to the collection:
db.inventory.explain('executionStats').find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} );

Las claves cuyos valores debe tener en cuenta en el resultado de la ejecución del comando anterior:

  • totalKeysExamined:el número total de entradas de índice analizadas para devolver la consulta.
  • totalDocsExamined:el número total de documentos escaneados para encontrar los resultados.
  • executionTimeMillis:tiempo total en milisegundos requerido para la selección del plan de consulta y la ejecución de la consulta.

Medición del rendimiento del retraso en la replicación

El retraso de replicación es un retraso entre una operación en el primario y la aplicación de esa operación desde el oplog al secundario. En otras palabras, define qué tan lejos está el secundario del nodo principal, que en el mejor de los casos, debería estar lo más cerca posible de 0.

El proceso de replicación puede verse afectado por múltiples razones. Uno de los principales problemas podría ser que los miembros secundarios se estén quedando sin capacidad del servidor. Las grandes operaciones de escritura en el miembro principal hacen que los miembros secundarios no puedan reproducir los registros de operaciones o la creación de índices en el miembro principal.

Para verificar el retraso de replicación actual, ejecute en un shell de MongoDB:

db.getReplicationInfo()
db.getReplicationInfo() 
{
    "logSizeMB" : 2157.1845703125,
    "usedMB" : 0.05,
    "timeDiff" : 4787,
    "timeDiffHours" : 1.33,
    "tFirst" : "Sun Jul 01 2018 21:40:32 GMT+0000 (UTC)",
    "tLast" : "Sun Jul 01 2018 23:00:19 GMT+0000 (UTC)",
    "now" : "Sun Jul 01 2018 23:00:26 GMT+0000 (UTC)"

La salida del estado de la replicación se puede utilizar para evaluar el estado actual de la replicación y determinar si hay algún retraso de replicación no deseado.

rs.printSlaveReplicationInfo()

Muestra el tiempo de retardo entre los miembros secundarios con respecto al primario.

rs.status()

Muestra los detalles en profundidad para la replicación. Podemos recopilar suficiente información sobre la replicación usando estos comandos. Con suerte, estos consejos brindan una descripción general rápida de cómo revisar el rendimiento de MongoDB. Háganos saber si nos hemos perdido algo.