Чтобы выяснить, насколько хорошо Solr 7.6.0 работает на виртуальных машинах Azure (в частности, сценарий восстановления реплик), я провел тест производительности.
Цель состояла в том, чтобы выяснить, как быстро неисправный узел реплики может восстановиться в осколке.
Что я сделал?
- Я провел нагрузочный тест для 48часы
- Захватил полное время восстановления узла реплики вручную, перезапустив его в тот момент, когда каждый шард начал размещать 250+ ГБ данных (близко к ОЗУ виртуальной машины с 32-ядерным компьютером)
Результаты эксперимента
Одной из самых больших красных отметок в этом эксперименте было время, необходимое для восстановления реплик:
Потребовалось ~ 2 часа для восстановления 350 ГБ, чтоозначает 350 / (2 * 60) = 2,91 ГБ / мин, что составляет 2,91 * 8/60 = 0,4 Гб / с (не то, что это маленький б значащий бит, а не байт).
Так что кажется, что Solr7.6.0 просто может использовать пропускную способность 0,4 Гбит / с для передачи данных от своего лидера к неудачной реплике.
Чтобы проверить, поддерживает ли соответствующая виртуальная машина большую пропускную способность, я запустил
iperf3
на этих виртуальных машинах и обнаружил, что яt поддерживал 11 Гбит / с (однако согласно Azure он должен составлять 16 Гбит / с, что здесь не является преградой).
Итак, проблема в том, почему Solr может использовать толькоПропускная способность 0,4 Гбит / с, в то время как виртуальные машины способны поддерживать ~ 11 Гбит / с?