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

Я пытаюсь просмотреть некоторые журналы Mongo, пытаясь найти медленные операции, которые мне нужно оптимизировать. Медленное ведение журнала запросов используется по умолчанию и требует выполнения операций регистрации более 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 режим), поскольку это показывает детали для планов запросов, которые были рассмотрены, а также выигрышный план. Если вы не уверены, как интерпретировать вывод объяснения для медленного запроса, я рекомендую опубликовать в DBA StackExchange.

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