Estoy intentando revisar algunos registros de Mongo en un intento de encontrar operaciones lentas que necesito optimizar. El registro de consultas lento es el predeterminado y registra operaciones de más de 100 ms.
Creo que es seguro decir que, en general, una búsqueda de COLLSCANS mostrará consultas que necesitan atención. Lo que está menos claro es si IXSCANS es un detalle que debería buscar.
Teniendo en cuenta la documentación de MongoDB aquí:
https://docs.mongodb.com/manual/reference/explain-results/#collection-scan-vs-index-use
Tengo entendido que se trata de una situación binaria, una consulta es COLLSCAN o IXSCAN. Entonces, si busco IXSCAN, miraré TODAS las consultas lentas que no son COLLSCANS. ¿Es esto cierto?
Respuesta1
Estoy intentando revisar algunos registros de Mongo en un intento de encontrar operaciones lentas que necesito optimizar. El registro de consultas lento es el predeterminado y registra operaciones de más de 100 ms.
En lugar de buscar en los registros de MongoDB, recomiendo encarecidamente utilizar los scripts de código abierto.mtoolsproyecto. NOTA: No soy el mtoolsautor original, pero soy colaborador.
mtools es una colección de scripts de Python que se inspiró en el dolor de buscar en GB de registros para tratar de encontrar información de interés para implementaciones de producción de MongoDB. Los scripts clave están destinados a encajar con el flujo de trabajo típico de la línea de comandos de canalizar la salida a través de filtros sucesivos (p. ej. mlogfilter --scan | mplotqueries).
Por ejemplo:
mloginfo --querieses un buen punto de partida: agrega patrones de consulta para que pueda centrarse en las consultas que se ejecutan con frecuencia y que tienen un impacto más general en su implementación.mlogfilteres esencialmente un grep para registros de MongoDB: puede filtrar líneas de registro por espacio de nombres, duración, conexión, patrón y otros criterios. El--scanLa opción es útil para identificar consultas ineficientes que no son necesariamente un análisis de colección.mplotquerieses una herramienta para visualizar registros, que puede resultar muy útil para identificar patrones y valores atípicos.
Creo que es seguro decir que, en general, una búsqueda de COLLSCANS mostrará consultas que necesitan atención. Lo que está menos claro es si IXSCANS es un detalle que debería buscar.
Los escaneos de colecciones generalmente son de interés, pero también pueden ser el resultado de consultas únicas o del uso esperado en una colección pequeña. En lugar de centrarme en el tipo de consulta, revisaría las consultas lentas (u operaciones lentas en general) de su implementación para comprender mejor lo que podría mejorar. Usar un índice suele ser bueno, pero hay usos de índice ineficientes (por ejemplo, clasificación en memoria oexpresiones regulares que no distinguen entre mayúsculas y minúsculas) que puede valer la pena abordar.
Tengo entendido que se trata de una situación binaria, una consulta es COLLSCAN o IXSCAN. Entonces, si busco IXSCAN, miraré TODAS las consultas lentas que no son COLLSCANS. ¿Es esto cierto?
Si busca, IXSCANencontrará todas las líneas de registro que mencionan IXSCAN, pero el resultado del registro de consultas lento definitivamente no es binario y también variará según la versión del servidor MongoDB. Si bien el uso eficiente del índice es una optimización obvia, existen una serie de problemas internos.etapas del planificador de consultasque pueden ser relevantes para comprender el rendimiento de las consultas.
Cuando encuentra una consulta lenta interesante en los registros, el siguiente paso suele ser una revisión más detallada.explain output. Yo uso explain(true)(también conocido comoallPlansExecutionmodo) ya que esto muestra detalles de los planes de consulta que se consideraron, así como el plan ganador. Si no está seguro de cómo interpretar el resultado de la explicación para una consulta lenta, le recomiendo publicar enIntercambio de pila de DBA.
Vale la pena señalar que explicar una consulta no es una medida del desempeño real con una carga de trabajo. En el funcionamiento normal, los planes de consulta se almacenan en caché, mientras que explainla salida detallada reevalúa específicamente los índices candidatos y el plan de consulta. VerPlanes de consultaen el manual de MongoDB para obtener más información.