Понимание IXSCAN и COLLSCAN в журналах MongoDB

Question

Я пытаюсь выполнить grep по некоторым журналам Mongo, чтобы найти медленные операции, которые мне нужно оптимизировать. Медленное ведение журнала запросов установлено по умолчанию и регистрирует операции более 100 мс.

Вместо того, чтобы просматривать логи MongoDB, я настоятельно рекомендую использовать скрипты из открытого исходного кодаmtoolsпроектПРИМЕЧАНИЕ: Я не являюсь первоначальным mtoolsавтором, но я внес вклад.

mtools представляет собой набор скриптов Python, которые были вдохновлены болью от поиска информации, представляющей интерес для производственных развертываний MongoDB, в гигабайтах журналов. Ключевые скрипты предназначены для встраивания в типичный рабочий процесс командной строки, передавая вывод через последовательные фильтры (например, mlogfilter --scan | mplotqueries).

Например:

mloginfo --queriesявляется хорошей отправной точкой: он объединяет шаблоны запросов, чтобы вы могли сосредоточиться на запросах, которые выполняются часто и оказывают большее общее влияние на ваше развертывание.
mlogfilterпо сути является grep для журналов MongoDB: вы можете фильтровать строки журнала по пространству имен, длительности, подключению, шаблону и другим критериям.--scanопция полезна для выявления неэффективных запросов, которые не обязательно являются сканированием коллекции.
mplotqueries— это инструмент для визуализации журналов, который может быть очень полезен для выявления закономерностей и выбросов.

Я думаю, можно с уверенностью сказать, что в целом поиск COLLSCANS покажет запросы, требующие внимания. Менее ясно, что если IXSCANS — это деталь, по которой мне следует искать.

Сканирование коллекций обычно представляет интерес, но также может быть результатом одноразовых запросов или ожидаемого использования небольшой коллекции. Вместо того, чтобы сосредоточиться на типе запроса, я бы рассмотрел медленные запросы (или медленные операции в целом) для вашего развертывания, чтобы лучше понять, что вы можете улучшить. Использование индекса обычно хорошо, но есть неэффективное использование индекса (например, сортировка в памяти илиРегулярные выражения, нечувствительные к регистру), которые стоит рассмотреть.

Насколько я понимаю, это бинарная ситуация, запрос — это либо COLLSCAN, либо IXSCAN. Так что если я grep для IXSCAN, я буду смотреть на ВСЕ медленные запросы, которые не являются COLLSCANS. Это правда?

Если вы выполните grep для , IXSCANвы найдете все строки журнала, в которых упоминается IXSCAN, но медленный результат регистрации запросов определенно не является двоичным и также будет зависеть от версии сервера MongoDB. Хотя эффективное использование индекса является очевидной оптимизацией, есть ряд внутреннихэтапы планировщика запросовкоторые могут иметь значение для понимания производительности запросов.

Когда вы находите в журналах интересный медленный запрос, следующим шагом обычно становится более подробный просмотрexplain output. Я использую explain(true)(он жеallPlansExecutionmode), поскольку это показывает детали для планов запросов, которые были рассмотрены, а также победивший план. Если вы не уверены, как интерпретировать вывод объяснения для медленного запроса, я бы рекомендовал разместить наАдминистратор баз данных StackExchange.

Стоит отметить, что объяснение запроса не является мерой фактической производительности с рабочей нагрузкой. При нормальной работе планы запросов кэшируются, тогда как подробный explainвывод специально переоценивает индексы-кандидаты и план запроса. СмотретьПланы запросовв руководстве MongoDB для получения дополнительной информации.

Answer 1

Я пытаюсь выполнить grep по некоторым журналам Mongo, чтобы найти медленные операции, которые мне нужно оптимизировать. Медленное ведение журнала запросов установлено по умолчанию и регистрирует операции более 100 мс.

Вместо того, чтобы просматривать логи MongoDB, я настоятельно рекомендую использовать скрипты из открытого исходного кодаmtoolsпроектПРИМЕЧАНИЕ: Я не являюсь первоначальным mtoolsавтором, но я внес вклад.

mtools представляет собой набор скриптов Python, которые были вдохновлены болью от поиска информации, представляющей интерес для производственных развертываний MongoDB, в гигабайтах журналов. Ключевые скрипты предназначены для встраивания в типичный рабочий процесс командной строки, передавая вывод через последовательные фильтры (например, mlogfilter --scan | mplotqueries).

Например:

mloginfo --queriesявляется хорошей отправной точкой: он объединяет шаблоны запросов, чтобы вы могли сосредоточиться на запросах, которые выполняются часто и оказывают большее общее влияние на ваше развертывание.
mlogfilterпо сути является grep для журналов MongoDB: вы можете фильтровать строки журнала по пространству имен, длительности, подключению, шаблону и другим критериям.--scanопция полезна для выявления неэффективных запросов, которые не обязательно являются сканированием коллекции.
mplotqueries— это инструмент для визуализации журналов, который может быть очень полезен для выявления закономерностей и выбросов.

Я думаю, можно с уверенностью сказать, что в целом поиск COLLSCANS покажет запросы, требующие внимания. Менее ясно, что если IXSCANS — это деталь, по которой мне следует искать.

Сканирование коллекций обычно представляет интерес, но также может быть результатом одноразовых запросов или ожидаемого использования небольшой коллекции. Вместо того, чтобы сосредоточиться на типе запроса, я бы рассмотрел медленные запросы (или медленные операции в целом) для вашего развертывания, чтобы лучше понять, что вы можете улучшить. Использование индекса обычно хорошо, но есть неэффективное использование индекса (например, сортировка в памяти илиРегулярные выражения, нечувствительные к регистру), которые стоит рассмотреть.

Насколько я понимаю, это бинарная ситуация, запрос — это либо COLLSCAN, либо IXSCAN. Так что если я grep для IXSCAN, я буду смотреть на ВСЕ медленные запросы, которые не являются COLLSCANS. Это правда?

Если вы выполните grep для , IXSCANвы найдете все строки журнала, в которых упоминается IXSCAN, но медленный результат регистрации запросов определенно не является двоичным и также будет зависеть от версии сервера MongoDB. Хотя эффективное использование индекса является очевидной оптимизацией, есть ряд внутреннихэтапы планировщика запросовкоторые могут иметь значение для понимания производительности запросов.

Когда вы находите в журналах интересный медленный запрос, следующим шагом обычно становится более подробный просмотрexplain output. Я использую explain(true)(он жеallPlansExecutionmode), поскольку это показывает детали для планов запросов, которые были рассмотрены, а также победивший план. Если вы не уверены, как интерпретировать вывод объяснения для медленного запроса, я бы рекомендовал разместить наАдминистратор баз данных StackExchange.

Стоит отметить, что объяснение запроса не является мерой фактической производительности с рабочей нагрузкой. При нормальной работе планы запросов кэшируются, тогда как подробный explainвывод специально переоценивает индексы-кандидаты и план запроса. СмотретьПланы запросовв руководстве MongoDB для получения дополнительной информации.

Понимание IXSCAN и COLLSCAN в журналах MongoDB

решение1

Связанный контент