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

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

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

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

Например:

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

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

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

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

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

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

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