Блог

Главная - Вопросы по программированию - Тайм-ауты курсора MongoDB при выполнении большого количества операций записи

Тайм-ауты курсора MongoDB при выполнении большого количества операций записи

#mongodb

#mongodb

Вопрос:

У нас есть кластер из 2 наборов реплик, по 3 сервера в наборе. При разделении одной коллекции. У нас также есть еще довольно много (более 8) коллекций, которые мы используем ежедневно. Большая часть данных находится в разделенной коллекции, в которой содержится около 100 миллионов записей.

Недавно мы добавили требование получать в 100 раз больше данных, которые мы получали ранее, и нам нужно записать это в mongodb. Установлен демон для выполнения операций записи, необходимых для поддержания базы данных в актуальном состоянии. Скрипт выполняет более 200 операций записи в секунду, причем большинство операций выполняется во всех отдельных коллекциях.

При таком количестве операций записи мы не смогли выполнять большие операции чтения в аналитических целях. Получение комбинации тайм-аутов курсора на стороне клиента и на стороне сервера («Курсор не найден»).

Мы пытались использовать схемы ограничения / пропуска при чтении, но проблема сохраняется. Каков наилучший способ исправить это, поскольку нам требуется как большое количество операций записи, так и несколько, но больших операций чтения?

Ответ №1:

Обычно в подобном случае вы хотите начать просмотр запросов, вызывающих время. Затем вы хотите взглянуть на аппаратное обеспечение, чтобы увидеть, что находится под напряжением.

  1. Правильно ли проиндексированы эти запросы?
  2. Насколько велики индексы? Помещаются ли они в оперативную память?
  3. Можете ли вы предоставить некоторые подробности о том, где находятся узкие места?
  4. Вы заблокированы в режиме ввода-вывода?
  5. Работают ли ваши процессоры на полной скорости?

Кроме того, есть ли что-нибудь необычное в журналах?

В принципе, нам нужно убедиться, что у вас: 1. Правильно построенная система для обработки запроса 2. Правильно подготовленная система для обработки объемов данных

Комментарии:

1. 1. Мы запрашиваем наши операции чтения только с полем _id. 2. Наши индексы лишь немного превышают объем памяти, у наших экземпляров EC2 — 7,5 ГБ, а наши индексы на replSet — 9,5 ГБ. В настоящее время мы находимся в процессе обновления до 32 ГБ masters. 3. Я не вижу никаких узких мест, просто проблемы с полным чтением данных. 4. Обычно у нас заблокирована запись в коллекции, которая выполняет больше всего операций записи, но в остальном все в порядке. 5. Наши процессоры на самом деле не испытывают слишком большой нагрузки.

2. Как выглядят iostat и mongostat? Вы работаете на дисках EBS? ПОДВЕРГСЯ РЕЙДУ? Какова их производительность?

3. mongostat показывает заблокированный процент, плавающий около 90%, с обновлениями, доминирующими на графиках. В настоящее время мы запускаем ephemeral на основных устройствах и EBS на вторичных. iostat показывает количество операций чтения / с на уровне 622 и 365 для операций записи / с, количество операций чтения, вероятно, велико, потому что в настоящее время мы восстанавливаем 2 сервера по 32 ГБ.

4. обычно я делаю iostat -dxk 1 . Здесь есть %util столбец. Если это значение велико, то вы облагаете налогом операции ввода-вывода на диске (дисках).

5. Стандартные решения для максимального ввода-вывода: RAID, больше оперативной памяти и сегментирование. Вы захотите начать с RAID и RAM, прежде чем переходить к сегментированию. Также рассмотрите возможность использования slaveOkay для ваших операций чтения.