Как настроить Java-драйвер MongoDB MongoOptions для производственного использования? - PullRequest
98 голосов
/ 29 июня 2011

Я искал в интернете лучшие рекомендации по настройке MongoOptions для Java-драйвера MongoDB, и я не придумал ничего, кроме API.Этот поиск начался после того, как я столкнулся с ошибкой «com.mongodb.DBPortPool $ SemaphoresOut: Out of semaphores to get db connection» и, увеличив число соединений / множитель, я смог решить эту проблему.Я ищу ссылки или ваши рекомендации по настройке этих параметров для производства.

Варианты драйвера 2.4 включают в себя: http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

  • autoConnectRetry
  • connectionsPerHost
  • connectTimeout
  • maxWaitTime
  • socketTimeout
  • threadsAllowedToBlockForConnectionMultiplier

Более новые драйверы имеют больше параметров, и я был бы заинтересовануслышав о них.

1 Ответ

157 голосов
/ 29 июня 2011

Обновлено до 2.9:

  • autoConnectRetry просто означает, что драйвер автоматически попытается повторно подключиться к серверу (серверам) после неожиданного отключения. В производственных средах обычно требуется, чтобы для этого параметра было установлено значение true.

  • connectionsPerHost - это количество физических соединений, которые один монго-экземпляр (он одноэлементный, поэтому обычно у вас есть один на приложение) может быть установлен с процессом mongod / mongos. Во время написания java-драйвер в конечном итоге установит это количество соединений, даже если фактическая пропускная способность запроса будет низкой (в словах порядка вы увидите, что статистика «conn» в mongostat будет расти, пока она не достигнет этого числа на сервер приложений).

    Нет необходимости устанавливать это значение выше 100 в большинстве случаев, но этот параметр является одним из тех, которые «проверяют и видят» вещи. Обратите внимание, что вы должны убедиться, что вы установили достаточно низкое значение, чтобы общее количество подключений к вашему серверу не превышало

    db.serverStatus().connections.available

    В производстве у нас сейчас это 40.

  • ConnectTimeout . Как следует из названия, количество миллисекунд будет зависать от драйвера, прежде чем попытка подключения будет прервана. Установите тайм-аут на что-то длинное (15-30 секунд), если нет реалистичного, ожидаемого шанса, что это будет мешать в противном случае успешным попыткам соединения. Обычно, если попытка подключения занимает больше пары секунд, ваша сетевая инфраструктура не способна обеспечить высокую пропускную способность.

  • maxWaitTime . Количество мс, которое поток будет ожидать, пока соединение не станет доступным в пуле соединений, и вызывает исключение, если это не произойдет во времени. Сохранить по умолчанию.

  • socketTimeout . Стандартное значение времени ожидания сокета. Установите на 60 секунд (60000).

  • threadsAllowedToBlockForConnectionMultiplier . Множитель для connectionsPerHost, который обозначает количество потоков, которым разрешено ожидать подключения, если пул в настоящее время исчерпан. Этот параметр вызовет исключение «com.mongodb.DBPortPool $ SemaphoresOut: Out of semaphores to get db connection». Он выдаст это исключение, как только эта очередь потока превысит значение threadsAllowedToBlockForConnectionMultiplier. Например, если connectionPerHost равен 10, а это значение от 5 до 50 потоков могут блокироваться до того, как будет создано вышеупомянутое исключение.

    Если вы ожидаете большие пики пропускной способности, которые могут вызвать большие очереди, временно увеличьте это значение. У нас это в 1500 на данный момент именно по этой причине. Если загрузка вашего запроса постоянно превышает сервер, вам следует соответствующим образом улучшить ситуацию с аппаратным обеспечением и масштабированием.

  • readPreference . (ОБНОВЛЕНО, 2.8 +) Используется для определения предпочтения чтения по умолчанию и заменяет «slaveOk». Установите ReadPreference с помощью одного из методов фабрики классов. Полное описание наиболее распространенных настроек можно найти в конце этого поста

  • ш . (ОБНОВЛЕНО, 2.6 +) Это значение определяет «безопасность» записи. Когда это значение равно -1, запись не будет сообщать о каких-либо ошибках независимо от ошибок сети или базы данных. WriteConcern.NONE является подходящим предопределенным WriteConcern для этого. Если w равно 0, то сетевые ошибки приведут к ошибке записи, но ошибки Монго - нет. Это обычно называется записью «запускай и забывай» и должно использоваться, когда производительность важнее, чем согласованность и долговечность. Используйте WriteConcern.NORMAL для этого режима.

    Если вы установите значение 1 или выше, запись считается безопасной. Безопасные операции записи выполняют запись и следуют за ней по запросу к серверу, чтобы убедиться, что запись прошла успешно, или, если это не удалось, получить значение ошибки (другими словами, после записи она отправляет команду getLastError ()). Обратите внимание, что до тех пор, пока эта команда getLastError () не будет завершена, соединение резервируется. В результате этой и дополнительной команды пропускная способность будет значительно ниже, чем запись с w <= 0. При значении w равном 1, MongoDB гарантирует успешную запись (или ошибку проверки) в экземпляре, в который вы отправили запись. </p>

    В случае наборов реплик вы можете использовать более высокие значения, чтобы указать MongoDB отправлять запись по меньшей мере на «w» членов набора реплик перед возвратом (или, точнее, дождаться репликации вашей записи в » ж "члены). Вы также можете установить w в строку «большинство», которая указывает MongoDB выполнить запись для большинства членов набора реплик (WriteConcern.MAJORITY). Как правило, вы должны установить это значение равным 1, если вам не нужна необработанная производительность (-1 или 0) или реплицированные записи (> 1). Значения выше 1 оказывают значительное влияние на пропускную способность записи.

  • FSYNC . Опция долговечности, которая заставляет монго записываться на диск после каждой записи при включении. У меня никогда не было проблем с долговечностью, связанных с невыполненной записью, поэтому мы имеем это в false (по умолчанию) в рабочей среде.

  • j * (NEW 2.7 +) *. Логическое значение, которое при значении true заставляет MongoDB ожидать успешной фиксации группы журналирования перед возвратом. Если у вас включено ведение журнала, вы можете включить его для увеличения срока службы. Обратитесь к http://www.mongodb.org/display/DOCS/Journaling, чтобы узнать, что именно вам дает журналирование (и, следовательно, почему вы можете захотеть включить этот флаг).

ReadPreference Класс ReadPreference позволяет вам настраивать, на какие запросы экземпляров mongod направляться, если вы работаете с наборами реплик. Доступны следующие опции:

  • ReadPreference.primary () : Все чтения идут только на основной элемент repset. Используйте это, если вам требуется, чтобы все запросы возвращали согласованные (самые последние записанные) данные. Это значение по умолчанию.

  • ReadPreference.primaryPreferred () : Все чтения передаются на основной элемент repset, если это возможно, но могут запрашивать вторичные элементы, если основной узел недоступен. Таким образом, если первичный становится недоступным, чтения в конечном итоге становятся согласованными, но только если первичный недоступен.

  • ReadPreference.secondary () : Все операции чтения передаются вторичным членам набора, а основной элемент используется только для записи. Используйте это, только если вы можете жить с в конечном итоге последовательным чтением. Дополнительные члены repset могут использоваться для увеличения производительности чтения, хотя существуют ограничения на количество (голосующих) членов, которые может иметь repset.

  • ReadPreference.secondaryPreferred () : Все чтения передаются вторичным членам набора, если они доступны. Основной элемент используется исключительно для записи, если все дополнительные элементы не становятся недоступными. Кроме откат к основному члену для чтения, это то же самое, что ReadPreference.secondary ().

  • ReadPreference.nearest () : Чтения идут до ближайшего члена набора, доступного для клиента базы данных. Используйте только в том случае, если в конечном итоге последовательные чтения являются приемлемыми. Ближайший элемент - это элемент с наименьшей задержкой между клиентом и различными членами repset. Поскольку у занятых участников в конечном итоге задержка будет выше, эта должна также автоматически уравновесить нагрузку чтения, хотя в моем опыте вторичная (Предпочитаемая), похоже, будет лучше, если задержки у членов относительно постоянны.

Примечание. Все вышеперечисленное имеет версии с поддержкой тегов одного и того же метода, которые возвращают экземпляры TaggableReadPreference.Полное описание тегов набора реплик можно найти здесь: Теги набора реплик

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...