Я занимаюсь этой проблемой уже несколько недель.
У меня есть следующий сценарий:
Couchdb2.3.1-A <===> Couchdb2.3.1-B <===> Couchdb3.1.1-A <===> Couchdb3.1.1-B
куда <===> представляет собой две репликации по запросу, по одной настроенной на каждой стороне. то есть: Couchdb1 извлекает из Couchdb2 и наоборот.
Couchdb работает в контейнерах докеров
Если запись сделана в диванб2.3.1-А, он должен пройти через все серверы, пока не дойдет до диванб3.1.1-Б.
У каждого из них есть эксклюзивный HDD. Couchdb не использует диск совместно с какой-либо другой службой.
диван-бд2.3.1 А и Б нет проблем.
диван-бдб3.1.1-А постепенно начал увеличивать задержку диска с течением времени. Поэтому мы перестали делать ему запросы на запись и стали общаться только с диванб3.1.1-Б. диван-бдб3.1.1-А по-прежнему получает записи, но только по протоколу репликации. Задержка диска не изменилась.
Изменения, которые мы внесли с момента возникновения проблемы:
- Обновленное ядро от
4.15.0-55-общий к 5.4.0-88-общий
- Обновил убунту с
18.04 к 20.04
- Удалено
_global_changes база данных из диван-бдб3.1.1-А
Больше информации:
- Couchdb использует локальные постоянные тома Docker.
- Диски WD Purple для
2.3.1 Couchdbs и WD Black для 3.1.1 кушетки.
- У нас есть только одна база данных
88 ГБ и 2 вида: один из 22 ГБ и маленький из 30 МБ (очень обновлено)
статистика докера показывает, что Couchdb3.1.1 использует много памяти по сравнению с 2.3.1:
3,5 ГБ для Couchdb3.1.1-A (не получает прямых запросов на запись)8,0 ГБ для Couchdb3.1.1-A (получение запросов на чтение и запись)226 МиБ для 2.3.1-А552 МиБ для 2.3.1-Б
- Сжатие базы данных выполняется ночью. Проблема возникает только в течение дня, когда выполняется большая часть операций записи.
- Большая часть конфигурации по умолчанию.
График задержки от мониторинга munin:
задержка диска
Любая помощь приветствуется.
