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

двигатель mongodb wiredtiger с ext4 на xfs

У меня проблема с производительностью, связанная с движком mongodb wiredtiger в файловой системе ext4 (https://docs.mongodb.com/manual/administration/production-notes/#kernel-and-file-systems)

У меня есть репликант с 2 серверами и одним арбитром (все на ext4).

Я хотел бы знать, есть ли проблема с добавлением нового сервера в этот набор реплик с другой файловой системой (в моем случае XFS), идея состоит в том, чтобы добавить новые вторичные XFS и продвинуть один на первичный, прежде чем закрывать старые, которые на ext4.

mongodb

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

Хотя использование файловой системы Ext4 является одной из возможностей проблем с производительностью MongoDB и WiredTiger (особенно при значительной нагрузке на запись), могут быть и другие проблемы, влияющие на ваш вариант использования. Такие подробности, как конкретная версия сервера MongoDB, версия O / S, предупреждения о запуске и любые сообщения журнала, коррелирующие с периодом замедления, могут дать больше информации, если вы решите опубликовать дополнительный вопрос для исследования вашей периодической проблемы с производительностью. Другие детали развертывания, такие как хостинг (голое железо или облако), ресурсы сервера (ОЗУ, ЦП, тип диска) и mongod изменения конфигурации также могут иметь значение.

Поскольку вы подозреваете, что проблема с производительностью связана с использованием Ext4, я бы попытался изолировать изменения в вашем развертывании MongoDB, чтобы попытаться подтвердить эту теорию (особенно, если ваши периодические срывы постоянно воспроизводимы):

Если вы видите периодические остановки только на одном члене набора реплик (например, на основном), попробуйте понизить уровень текущего основного, чтобы члены поменялись ролями. Иногда причиной может быть медленный / недостаточно подготовленный ввод-вывод (или шумный сосед в среде облачного / общего хостинга). Вы также можете обнаружить, что существует другой фактор, зависящий от роли участника (например, если ваше приложение считывает данные из вторичных источников).
Если вы видите периодические остановки на обоих текущих элементах, несущих данные, добавьте новый член, используя XFS для storage.dbPath чтобы проверить, демонстрирует ли этот новый член такое же поведение.
Если вы еще не используете последний дополнительный выпуск для своей версии MongoDB, выполните обновление. Например, если вы используете MongoDB 3.4.2, а последняя доступная версия 3.4.x - 3.4.10, определенно стоит протестировать последнюю стабильную версию. Обновления в рамках той же серии производственных выпусков включают исправления ошибок и улучшения стабильности, но не должны вносить никаких изменений совместимости.

Другие предложения:

Просмотрите журналы MongoDB на предмет любых подозрительных действий или сообщений журнала, которые могут коррелировать с периодами замедления или остановок. Например, TTL (время жизни) Задача истечения срока действия индекса запускается каждые 60 секунд и может удалять значительное количество документов. Могут быть зарегистрированы медленные запросы или другие соответствующие предупреждения.
Предполагая, что у вас есть некоторый мониторинг метрик, просмотрите метрики развертывания MongoDB, чтобы найти выбросы или шаблоны, совпадающие с вашими периодами низкой производительности.
Если вы запускаете несколько основных выпусков после последней серии производственных выпусков MongoDB, рассмотрите возможность тестирования обновления основной версии в репрезентативной среде подготовки / разработки. В последовательных основных выпусках произошли значительные улучшения.
Для получения общей информации о настройке развертываний также стоит просмотреть Примечания к производству MongoDB.