Подвисает и с настройкой гемор

А подвисает это что значит?
Подвисает - и не принимает данные?
Подвисает и не сразу отрисовывается график в  графане?
В общем, это интересно, дайте плз фактуру

у кликхауса тоже отзывы не самые шикарные были год назад. жаловались на доку и синтаксис помню

а что вы считаете большим количеством входных данных? и на каких ресурсах инфлюкс?

На каких не помню точно, не жирная тачка, 2-4 ядра ОЗУ не более 8, и на 4к с 3х серверов jmeter инфлюкс уже падал 🤷‍♂

Что стоит проверить в скрипте JMeter, если InfluxDB тормозит:

Если в имени Sampler или Transaction Controller есть переменные ${varName}, то будет тормозить.

Видел, что добавлялись ThreadNum, ID, Login, даже Random.

Переменные надо убирать

Интересно
А почему?
Ведь в json видно, что запрос улетает без переменной

Хуже что если там стоит «все переменные», улетает in () и в скобках все переменные перечисляются

забаньте это тело с криптой

Спс

Может я не так был понят. Написал про имя. Не понимаю комментарий про JSON.

Имя транзакции попадает в InfluxDB. По нему строится аналитика.

Как правило все запросы типовые и достаточно назвать транзакцию так:
/getDoc?id={id} (GET)
или
/getDoc (GET)

Но иногда транзакцию называют (в JMeter):
/getDoc?id=${id} (GET)
Где id - существующая переменная.

И в InfluxDB пишется
/getDoc?id=1 (GET)
/getDoc?id=2 (GET)
/getDoc?id=3 (GET)
...

Индекс InfluxDB растет, ведь у тега transaction увеличивается количество уникальных значений.
По умолчанию индекс хранится в оперативной памяти, и память медленно заканчивается. А при переиндексацию или старте сервера - более активно потребляется.

Сервер даже может перезапуститься. Если ему памяти не хватит.

При переиндексациях большого индекса будет сильнее расходоваться CPU. Если в этот момент придет статистика, а тут InfluxDB был занят, то запрос может упасть по тайм-ауту.

о! так речь о том, что генерация большого количества тегов приводит к проблемам в influx
да, с этим согласен.

проблема не в переменных в имени транзакции, а в большом их количестве.

я-то сперва подумал что ты о переменных в фильтрах графаны :)))

Grafana тоже влияет на вероятность пробелов (пропуске метрик, вероятности того, что метрики не принялись) в статистике от JMeter.

Если сделать тяжёлый отчёт, неоптимальный. Такой что будет загружать CPU на InfluxDB на 30+ секунд. И настроить его активное обновление прямо во время нагрузки, на autorefresh проставить каждые 10 секунд.

То когда придет пачка данных от JMeter, ресурсов CPU может не хватить, чтобы за 30 секунд их принять

Тут совет:
- не обновлять тяжёлые отчёты во время нагрузки
- или для тяжёлых отчётов завести отдельный сервер
- или делать быстрые отчеты :)

Да, верно. Если значений будет немного, то не будет большого замедления. А если  значений десятки, то надо продумать.

А если сотни, то точно нет. Первые два-три дня будет работать быстро. А потом все встанет.

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

(Ушёл дропать старые тесты из инфлакса)

Может пригодятся. Не горячись. Если совсем старые, то можно рядом настроить второй InfluxDB, который будет пустой, но на запись и чтение. А старый пусть на чтение для истории. Разнести каталоги wal и data только надо и порты разные задать. А Grafana легко переключается между двумя DataSource

ага, так и делаю