2016-05-18 3 views
2

Наша база данных Mongo периодически (иногда один раз в день) замедляется примерно на 30-40 минут. API, получающий доступ к базе данных, испытывает спайки с высокой задержкой, которые происходят каждые 5-10 минут в течение этого медленного периода.Как диагностировать периодическое замедление MongoDB?

Глядя на файл журнала mongod эти 2 линии появляются в начале медлительности и сотрудничеству совпадают с каждым API латентного шипа (я отформатировал JSON для удобства чтения):

killcursors keyUpdates:0 numYields:0 locks(micros) r:91 4157ms 
serverStatus was very slow: { 
    after basic: 0, 
    after asserts: 0, 
    after backgroundFlushing: 0, 
    after connections: 0, 
    after cursors: 0, 
    after dur: 0, 
    after extra_info: 0, 
    after globalLock: 0, 
    after indexCounters: 0, 
    after locks: 0, 
    after network: 0, 
    after opcounters: 0, 
    after opcountersRepl: 0, 
    after recordStats: 2359, 
    after repl: 2359, 
    at end: 2359 
} 

Запросы после этого регистрируются, потому что они занимают несколько секунд - намного медленнее, чем обычно.

Для killCursors документации по документации не существует, поэтому я не понимаю, что означает эта запись в журнале. Что такое r?

Действительно ли команда killCursors занимает много времени, так как существует большое количество открытых курсоров для очистки? Насколько я ничего не знаю в нашем коде приложения, явным образом убиваю курсоры, так ли это нормальная работа? Он регистрируется очень часто, но обычно занимает 20-120 мс.

ответ

0

г является Намерение Общий (IS) замок. Killcursors здесь не проблема. Возможно, вам придется глубоко заглянуть, чтобы найти актуальную проблему. Проверьте индексы. Объясните все запросы, которые используют ваши API. Вы можете получить эту идею от https://groups.google.com/forum/#!msg/mongodb-user/qc4AD7kqu4U/7kaI1zwaAwAJ

0

По умолчанию сервер автоматически закрывает курсор после 10 минут бездействия или если клиент исчерпал курсор.

Это значит, что у вас могут быть сброшенные соединения и очистка в процессе - или другое задание на обслуживание дискового/системного оборудования может выполняться в одном и том же окне времени.

Чтобы определить причину падения производительности, вы можете увидеть вывод mongo top, проверить использование диска и памяти и посмотреть, в какой именно области имеется шип.

killCursor ссылка: manual

+0

Спасибо за ссылку на страницу «Курсоры» - я искал это сегодня утром и не смог найти. Однако на самом деле это не упоминание 'killCursors'. Я посмотрю, смогу ли я прыгнуть на коробку и запустить «mongotop» и «mongostat» в следующий раз, когда это произойдет ... –

Смежные вопросы