дашборде 19 графиков, каждый график грузится в среднем за 200мс.
Но если я обновляю все 19 штук сразу - обновление происходит более 10 секунд.
В момент обновления 1 графика загружено на 100% только 1 ядро, при одновременном обновлении 19 графиков - все 32 ядра.
Нагрузка на диск - нулевая.
max_threads =16
Версия 1.1.54292
С чем это может быть связано? Есть ли какое-то решение, кроме ограничения количества одновременных запросов?
Привет! Побробуйте использовать https://github.com/Vertamedia/chproxy Он умеет выстраивать запросы в очередь при первышении лимитов на кол-во одновременно выполняемых запросов: # Enable requests queueing - chproxy will queue up to max_queue_size # of incoming requests for up to max_queue_time until they stop exceeding # the current limits. # This allows gracefully handling request bursts when more than # max_concurrent_queries concurrent requests arrive. max_queue_size: 40 max_queue_time: 25s
мы используем для этого https://github.com/Vertamedia/chproxy со следующими ограничениями для юзера, из-под которого делаются запросы из графаны: max_concurrent_queries: 2 max_queue_size: 50 max_queue_time: 20s тогда chproxy будет пропускать не более двух одновременных запросов в кликхаус, а остальные запросы держать в очереди максимальной длины 50 до 20 секунд. Т.е. если одновременно придет более 50 запросов, то все что больше 50, моментально отвалится с ошибкой от chproxy. Если запрос пролежит в очереди более 20 секунд, то вернется ошибка и он не будет отправлен в кликхаус. Можете еще выставить max_execution_time: 10s , чтобы ограничить негативные последствия от дебильных запросов из графаны, которые слишком сильно и долго грузят кликхаус. Если отправленный в кликхаус запрос не выполнится в течение 10 секунд, chproxy принудительно его завершает с помощью KILL QUERY.
Обсуждают сегодня