|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
Добрый вечер, Подскажите, пожалуйста, как искать запрос, который привел к очередям? У меня периодически на произвольной шарде Монго 2.6, возникает очередь из нескольких сотен запросов. Очередь сама рассасывается за 1-2 часа. Может, у кого-нибудь есть удобные скрипты? Потому что с таким количеством запросов простой db.currentOp() не слишком нагляден. Конкретного блокирующего запроса не вижу, т.к. текущий выполняющийся запрос непрерывно меняется. Убивание десятка самых длинных не помогает. Вручную от очереди можно избавиться через более масштабные жертвы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 18:11 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
Eleanor, хм, как-то ручками писали bash скрипт, складывающий вывод db.currentOp() в лог. Потом этот лог через mongoimport загрузил в отдельную коллекцию, проанализировал, используя aggregation framework и построил необходимые идексы. Вы бы уточнили очередь на что у Вас? На запись, чтение? Чем смотрите, mongostat ? А вообще есть плагин для zabbix для мониторинга . ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 18:25 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
И на 3.0 переходите, там collection-level locking в MMAPv1 . ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 18:27 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
А вообще можно профилирование медленных запросов включить: db.setProfilingLevel() . И получить всё тоже самое, что и при выполнение db.currentOp() только в коллеции system.profile . Мне этого тогда не дали сделать на проде, поэтому писали bash скрипт. Также запросы дольше 100мс должны в лог падать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 18:40 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 18:43 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
skyANA, Спасибо за подсказку с mongostat. С mms про него забыла. Получилось убивать запросы по одному и смотреть на уменьшение очереди (на чтение). Оказались виноваты несколько курсоров. Теперь буду обновляться до 2.6.11, чтобы вместо getmore увидеть настоящий текст запроса. На 3.0 пока не получится - переход запланирован после НГ. И 3.0 тут не поможет, все блокировки возникают на одной коллекции. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2015, 21:38 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
EleanorНа 3.0 пока не получится - переход запланирован после НГ. И 3.0 тут не поможет, все блокировки возникают на одной коллекции.Если перейдёте ещё и на WiredTiger, то получите document level concurrency control :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 09:44 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
skyANA, а вы на WT уже перешли? проблемы были? Первый раз тестировала переход на WT почти год назад. После 2 Тб скорость процесса конвертации упала практически до нуля, почти никаких подвижек за неделю. Ладно, согласовали на будущее разбиение данных на маленькие базы. Стала оценивать степень сжатия на маленькой базе. Со Snappy всё было отлично. А zlib показал, что при попытке сжатия возникло 300 тыс ошибок. Доверия WT не вызывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2015, 13:48 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2015, 08:43 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
Итого: Оказалось, столкнулась с багом https://jira.mongodb.org/browse/SERVER-13866 Запросы берут не тот индекс. Раньше брался индекс, поиск по которому занимает 0.01 сек, а теперь тот, по которому час. Причем, при запуске запросов вручную берется правильный индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 15:19 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
Eleanor, в planSummary же видно какой индекс использовался. И в логе и в currentOp . А запросы в ручную при такой же нагрузке выполнялись? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 16:38 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
На тех же данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 16:39 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
skyANA, индекс смотрела в planSummary: периодически несколько десятков запросов вместо индекса с почти уникальным полем выбирают индекс, у которого надо проверить 10 млн записей. Это происходит только на одной из шард. Запрос scatter/gather. Другая шарда берет уникальный индекс. Если я сразу же вручную выполняю тот же самый запрос, то обе шарды берут корректный индекс. Дальше несколько часов все последующие запросы выполняются на корректном индексе. Потом опять берется не тот индекс. Причем, это может произойти уже на другой шарде. Буду пробовать: - явно сделать индекс уникальным... сижу удаляю дубли. - хэшированный индекс, т.к. поисковое поле достаточно широкое - hint на стороне клиента, чего не хотелось бы ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2015, 20:43 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
Eleanor, Есть еще вот такая штука - https://docs.mongodb.org/manual/reference/command/planCacheSetFilter/#dbcmd.planCacheSetFilter ... |
|||
:
Нравится:
Не нравится:
|
|||
04.12.2015, 00:57 |
|
Поиск блокирующих запросов в Монго
|
|||
---|---|---|---|
#18+
В итоге пришлось на клиенте делать постоянный hint, и, пока не прошло обновление, использовать фильтр на стороне Монго. Хэшированный индекс, не смотря на то, что он в 2 раза меньше обычного, вообще не используется. Запросы с ним работают на несколько процентов медленнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 17:10 |
|
|
start [/forum/topic.php?fid=48&msg=39114991&tid=1856780]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 293ms |
0 / 0 |