У меня есть кластер Cassandra из 6 узлов EC2 (i3.2xlarge с хранилищем экземпляров), который я расширил с 3 узлов. Каждый раз, когда присоединяется узел, он берет на себя ответственность за около 600 ГБ данных. Все несистемные пространства ключей используют NetworkTopologyStrategy с 1 DC и 3 стойками (AZ) и коэффициентом репликации 3.
Потоки данных в 10 раз медленнее, чем доступная пропускная способность сети (что я проверил с помощью nc) и количество потоковых хостов (обычно 1). Мой вопрос: что может вызвать это, и как мне получить более полное представление о том, что замедляет это? Соответствует ли это опыту других людей?
Я ожидаю, что мы могли бы улучшить это время, перейдя к топологии с более мелкими узлами, но это было исключено из-за факторов стоимости. Главное беспокойство - это узкое место, о котором мы не знаем.
Я обычно вижу:
- Пропускная способность сети самая высокая в начале (20-30 Мбит / с в течение часа на присоединяющемся узле)
- затем он замедляется до минимума (0-5 МБ / с)
- Существуют последующие периоды, когда пропускная способность возрастает в течение пары часов (10-20 Мбит / с)
- Общее время присоединения - 12-30 часов
Я смотрел на:
- пропускная способность потока - высокая (800 Мбит / с) / неограниченная на обоих концах
- Уплотнение - низкая активность уплотнения на каждом конце; пробовал низкую / высокую / неограниченную пропускную способность без заметного влияния
- Метрики ОС / Java - ЦП, дисковый IO, сетевой IO, активность GC, использование памяти все низкое
- Использование Cassandra - 150 операций чтения в секунду на хост, 150 операций записи в среднем. Производительность потока не меняется при изменении использования
- Другие кластеры - у нас есть другие кластеры разных размеров, но в остальном похожая конфигурация, где мы видим похожий шаблон (общее снижение пропускной способности с течением времени, намного ниже пропускной способности без очевидных узких мест), но с более высокой общей пропускной способностью и более быстрым временем завершения.
Кластер включен 3.11.2.