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

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

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

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

Например:

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

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

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

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

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

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

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