#mongodb #sharding
#mongodb #сегментирование
Вопрос:
У меня есть кластер mongo 2.4.8. Мое программное обеспечение динамически разделяет данные, и теперь у меня около 30 000 разделенных коллекций. В настоящее время кластер содержит только один сегмент (который является набором реплик); это кластер, позволяющий легко расширять его в будущем.
Когда я запускаю новый mongos процесс и запускаю show collections , на его завершение уходит несколько часов. В течение этого времени mongos не отвечает на запросы всех клиентов (но кластер работает нормально). Если я никогда не запускаю show collectoins , все остальные операции через mongos работают нормально.
В конечном итоге show collections завершается, и после этого mongos все работает нормально, и show collections повторный запуск с тем же mongos результатом сразу возвращается. Я узнал о проблеме только тогда, когда мне впервые за много месяцев понадобилось перезапустить mongos , в течение которого количество коллекций значительно возросло.
Логично, что передача данных (о фрагментах коллекции) с серверов конфигурации на новые mongos является узким местом. Но ни одна из сторон не демонстрирует высокой активности процессора или сети, пока это происходит.
Известно ли это поведение? Как я могу дополнительно исследовать проблему?
Комментарии:
1. Можете ли вы указать размеры серверов конфигурации? Кроме того, какова задержка между серверами конфигурации и между серверами конфигурации и сегментами?
2. @MarkusWMahlberg
configбаза данных (как видно черезmongos) имеет объем 32 МБ данных, 250 МБ на диске, 62 тыс. объектов. Все серверы находятся в EC2, в разных зонах одного региона, поэтому задержка должна составлять < 10 мс. Серверы конфигурации работают на небольших узлах, но они не используют много ресурсов, поэтому я не пытался их увеличить.3. Я имел в виду размеры экземпляров, но дополнительная информация не повредит. 😉 Очень странно, я не могу воспроизвести вашу проблему. Единственное, о чем я могу думать, это о том, что разрешение имен всегда заканчивается таймаутом. Можете ли вы проверить, сколько времени занимает вход по ssh от вашего
mongosк вашим серверам конфигурации, от ваших серверов конфигурации к основной реплике и наоборот, соответственно?4. Все они находятся в EC2 и используют DNS-имена, разрешенные серверами имен EC2, я проверил, и с этим проблем нет. Кроме того, это не соответствует схеме, когда требуется очень много времени, но затем выполняется успешно.
5. Это идеально соответствовало бы этому шаблону, поскольку mongos и серверы конфигурации обычно кэшируют расположение фрагментов в сегментах (ну, на самом деле диапазон сегментов для каждого сегмента). Но они проверяют это время от времени, iirc, наверняка при запуске серверов конфигурации и, возможно, при первом подключении с mongos. Таким образом, даже при наличии одного фрагмента проверка может занять некоторое время, если для разрешения имени хоста в каждом запросе требуется много времени, а имя не кэшируется.
Ответ №1:
Я проследил проблему до неисправного сервера конфигурации. После его замены все снова работает нормально.
Подробности: неисправный сервер не отвечал на запросы, после чего они были повторно отправлены на другие серверы. Это создало эффективную задержку для каждого запроса к серверам конфигурации, которая была наиболее выражена в операции «показать коллекции», которая выполняет по крайней мере один цикл для каждой коллекции между mongos и серверами конфигурации, и выполняет их все последовательно.