1. дома
  2. Вопрос и ответ
  3. MongoDB осколок кластера 25 медленнее, чем автономный узел

MongoDB осколок кластера 25 медленнее, чем автономный узел

2014-02-04 3 views
5

Я смущен ситуацией и попытаюсь исправить это уже пару дней. Я запускаю 3 осколка поверх трех наборов реплик из трех членов (rs0, rs1 и rs2). Все работает до сих пор. Данные распределяются по трем осколкам, а также клонируются в наборах реплик.MongoDB осколок кластера 25 медленнее, чем автономный узел

НО: импорт данных в один из наборов реплик отлично работает с постоянно 40k docs/s, но при включении sharding замедляет весь процесс вплоть до 1,5k docs/s.

Я заселена данные различными методами:

  • генерируются случайные данные в Монго оболочки (работает в моей mongos)
  • JSON импорт данных через mongoimport
  • MongoDB дамп восстановления от другого сервер через mongorestore

Все они приводят к разочарованию всего 1.5k doc/s. Mongod - это физические Xeon-боксы по 32 ГБ каждый, 3-х конфигурационные серверы - это виртуальные серверы (40-Гбайт HDD, 2 ГБ ОЗУ, если это имеет значение), монго работает на моем сервере приложений. Кстати, значение 1.5k inserts/s не зависит от ключа осколка, такого же поведения для выделенного ключа осколка (одно полевого ключа, а также составного ключа), а также хэшированного ключа осколка в поле _id.

Я пробовал много, даже переустановил весь кластер дважды. Возникает вопрос: каково узкое место в этой настройке:

  • серверы конфигурации, работающие на виртуальном сервере? -> не должно быть проблематичным из-за низкого потребления ресурсов конфигурационными серверами
  • mongos? -> запуск нескольких Mongos на выделенном ящике за HAproxy может быть альтернативой, еще не проверял, что еще нет

источник

2014-02-04 ctp

+1

Попробуйте остановить балансировщик в течение всего этого массового обновления и посмотреть, не ускорит ли он это. Кроме того, если это возможно, и данные позволяют это, попробуйте использовать метод целевого осколка, например «Tag Aware Sharding» –

+1

Когда вы загружаете данные на один сервер, вы, вероятно, используете большие партии, которые амортизируют стоимость блокировки, сетевые накладные расходы и т. д. Когда вы загружаете монго, монго нужно разбить свои партии на более мелкие партии, которые идут на каждый осколок. То, как это делается, неэффективно (https://github.com/Tokutek/mongo/issues/912 объясняет больше). Кстати, если это ваша проблема, убедитесь, что каждая партия документов из вашего приложения имеет один и тот же ключ осколка. – leif

+0

ОК, что сбивает с толку: коллекции, которые не зарегистрированы sh.shardCollection(), которые должны быть оштукатурены, сохраняются по умолчанию в основном осколке. Таким образом, нет маршрутизации, балансировки нагрузки и т. Д.требуется для них. Поэтому я создал фиктивную коллекцию, не делил ее, чтобы ее делили и заполняли ее в оболочке mongo mongo. Результат: такие же медленные вставки данных, как в общих коллекциях. Тем не менее 1/25 скорости при импорте одних и тех же данных в один из наборов реплик. – ctp

ответ

3

Давайте сначала сделаем математику: насколько велики ваши документы? Имейте в виду, что их нужно переносить через сеть несколько раз в зависимости от вашей проблемы с записью.

Возможно, вы испытываете это из-за индексов, которые должны быть построены.

Пожалуйста, попробуйте следующее:

  1. Отключить все индексы кроме один для _id (что невозможно в любом случае, IIRC)
  2. Загрузите данные
  3. индексы снова включить.
  4. Включить шардинг и балансировку, если не сделано уже

Это предлагаемый способ для импорта данных в общем кластер в любом случае и должен ускорить импорт значительно. Некоторые (осторожные!) Возиться с storage.syncPeriodSecs и storage.journal.commitIntervalMs тоже могут помочь.

Задержка может происходить даже при хранении данных на основном осколке. В зависимости от размера ваших индексов они могут значительно замедлить массовые операции. Вы также можете просмотреть конфигурацию replication.secondaryIndexPrefetch.

Другое дело, что ваш oplog просто заполняется быстрее, чем может произойти репликация. Проблема здесь: как только она создана, вы не можете увеличить ее размер. Я не уверен, что безопасно удалять и воссоздавать его в автономном режиме, а затем повторно размещать набор реплик, но я сомневаюсь. Таким образом, безопасный вариант состоял бы в том, чтобы фактический экземпляр оставил набор реплик, переустановите его с более подходящим размером oplog и добавьте экземпляр в набор реплик, как если бы он был в первый раз. Если вам не нужны данные, просто закройте набор реплик, отрегулируйте размер oplog в файле конфигурации, удалите dir данных и перезапустите и повторно инициализируйте набор реплик. Думая о вашей проблеме дважды, это звучит как лучший выбор для меня, поскольку opllog не участвует в автономном режиме, iirc.

Если у вас все еще есть те же проблемы с производительностью, моя ставка касается проблем с дисковым или сетевым IO.

У вас довольно стандартная настройка, ваш экземпляр mongos работает на другой машине, чем ваш mongod (будь то автономный или основной набор реплик). Вы можете проверить несколько вещей:

  1. Имени разрешения задержки для разрешения имени из первичных и вторичных осколков от машины, выполняющей своего mongos экземпляра. Я не могу сосчитать время установки nscd улучшенной производительности для различных операций.
  2. Задержка сети от вашего mongos экземпляра вашего основного осколка. Предполагая, что у вас есть межсетевой экран между вашим AppServer и вашим кластером, вы можете поговорить с соответствующим администратором.
  3. Если вы используете внешнюю аутентификацию, попробуйте измерить, сколько времени потребуется.
  4. При использовании своего рода туннелирования (например, stunnel или шифрования, такого как SSL/TLS), убедитесь, что вы отключили разрешение имен. Пожалуйста, имейте в виду, что шифрование и дешифрование могут длительное время принимать относительно.
  5. Мера случайного диск ввод-вывод на mongod экземплярах

источник

2014-06-02 13:07:18

+0

есть опция или фрагмент для обнаружения задержки с помощью параметра syncpersiod/commitinterval/indexprefetch? Мы пытаемся добавить умный вид обнаружения лучшей рекомендации и быстрого решения; но самая сложная часть идентифицирует это как источник ошибки или задержки. – ledy

+0

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

1

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

с помощью следующей команды:

mongos> use admin 
mongos> db.runCommand({ movePrimary: "mydb", to: "shard0003" })

После внесения этого изменения (не касаясь балансировки нагрузки или настройки что-нибудь еще), я был в состоянии загрузить сравнительно большой набор данных (25 миллионов строк) с помощью загрузчика I написал, и вся процедура заняла около 15 минут вместо часов/дней.

источник

2014-11-06 16:46:56 user3892260

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

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