Назад | Перейти на главную страницу

Реплицируемый сервер MongoDB медленнее, чем простые шарды

Я попытался сравнить производительность сегментированной конфигурации с сегментированной и реплицированная конфигурация.

Шардированная конфигурация состоит из 8 сегментов, каждый из которых работает на трех разных машинах, что в сумме составляет 24 сегмента. Все 8 этих шардов работают в одном разделе на каждой машине.

Раздробленная и реплицированная версия - это снова 8 осколков, как и обычный осколок, и все 8 mongods запускаются в одном разделе на каждой машине. Но помимо этого, каждая из этих трех машин теперь запускает дополнительные 16 потоков в другом разделе, который служит вторичным для 8 mongodработает на других машинах. Таким образом я подготовил сегментированную и реплицированную конфигурацию с фрагментами данных с коэффициентом репликации 3.

Важно отметить, что после загрузки данные не изменяются. Итак, после того, как первичный и вторичный синхронизируются, не имеет значения, с какого я читаю.

Для выполнения запросов я использую совершенно другую машину (назовем ее config), которая запускает mongos и единственная цель этой машины - получать запросы и запускать их в кластере.

Вопреки моим ожиданиям, простое сегментирование 8 потоков на каждой машине (всего = 3 * 8 = 24) работает лучше для запросов, чем конфигурация сегментированная + реплицированная.

У меня есть сценарий для выполнения запроса. Итак, чтобы синхронизировать скрипты, я использую time ./testScript и посмотрите результат. Я попытался изменить предпочтение чтения для реплицированного кластера, войдя в mongo config и запустив db.getMongo().setReadPref('secondary') а затем выйдите из оболочки и выполните такие запросы, как time ./testScript.

Вопросы следующие:

  1. Где я ошибаюсь в репликации? Почему он медленнее, чем его обычная версия с сегментированием?
  2. Есть ли db.getMongo().ReadPref('secondary') сохраняться, когда я выхожу из оболочки и пытаюсь выполнить запрос?

Все четыре машины работают под управлением Linux, и я уже увеличил ulimit -n до 2048 с начального значения 1024, чтобы разрешить больше соединений. Коллекции распределены правильно, и все mongods имеют одинаковое количество блоков. Само собой разумеется, что показатели в обеих конфигурациях совпадают.

Технические характеристики оборудования - Архитектура: AMD64 - Оперативная память: 64 ГБ - Количество ядер: 32