Скорее всего, проблема в недостатке свободных ресурсов (cpu или disk io) на vmstorage нодах. Для нормальной работы кластера их должно хватать на предвиденные всплески в использовании вроде big merge либо временной недоступности одной из vmstorage нод (например, при последовательном обновлении vmstorage нод). При нехватке ресурсов для приема новых данных на одной из vmstorage нод vminsert ноды начинают перенаправлять (этот процесс называется rerouting) часть новых данных с этой vmstorage ноды на другие. Это приводит к возросшей нагрузке на других vmstorage нодах, что, в свою очередь, замедляет общую скорость сохранения данных. Если вы используете версию вм 1.66.0 или более новую, то там по умолчанию отключено автоматическое перенаправление поступающих новых данных с медленной vmstorage ноды на остальные ноды. В этом случае общая скорость вставки данных ограничена самой медленной vmstorage нодой. Автоматическое перенаправление данных можно включить, запустив vminsert ноды с флагом командной строки -disableRerouting=false. Но лучше добавить больше свободных ресурсов по cpu и/или disk io на vmstorage нодах, чтобы исключить проседание скорости вставки новых данных при запуске big merge. Второй способ - добавить дополнительные vmstorage ноды в кластер, чтобы размазать нагрузку по бОльшему количеству vmstorage нод. См. также https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#capacity-planning
Спасибо за подробный ответ! У нас 3 vmstorage, каждая по CPU: 32 RAM: 64 Storage: Pure SSD. Применил ограничение по bigMergeConcurrency и smallMergeConcurrency, до этого стоял default = 0. Пока наблюдаю.
smallMergeConcurrency главное сильно не срезать. Следить за lsm part small - чтоб сильно не вырастало. Ну и чтоб активные smallMerge не висели постоянно на значении = максимуму. У меня когда слишком сильно срезал после накопления определенного количества small lsm part нода замирала пока часть из них не смерджится.
Обсуждают сегодня