Как разнести непрерывное выполнение запроса Infxdb?

У меня есть много непрерывных запросов (CQ) infxdb, которые несколько раз использовались для субдискретизации данных за определенный период времени. В какой-то момент нагрузка стала высокой, и во время выполнения непрерывных запросов у infxdb не хватило памяти.

Скажем, у меня 10 CQ, и все 10 CQ выполняются в infxdb за раз. Это сильно влияет на память. Я не уверен, есть ли способ равномерно распределить интервалы или иметь некоторую задержку при выполнении каждого CQ один за другим. Мое предположение, что выполнение всех CQ одновременно приводит к сбою InfxDB. Все CQ указаны в config. Я надеюсь, что есть способ включить временную задержку между CQ в конфигурацию притока. Я не знал точно, как включить задержку в конфиг. Один образец CQ:

CREATE CONTINUOUS QUERY "cq_volume_reads" ON "metrics" 
BEGIN 
    SELECT sum(reads) as reads INTO rollup1.tire_volume FROM
    "metrics".raw.tier_volume GROUP BY time(10m),* 
END

К тому же я не знаю, лучший ли это способ решить проблему. Мы будем очень благодарны за любые мысли об этом подходе или предложения лучшего подхода. Было бы неплохо получить предложения по использованию инструментов отладки для Influxdb. Спасибо!


influxdb influxql
person Rajan    schedule 21.10.2020    source источник
comment
Какую версию infxdb вы используете?   -  person Phil    schedule 28.10.2020
comment
Если вы ищете более подробную информацию, дайте мне знать.   -  person Phil    schedule 31.10.2020

Ответы (1)


arrow_upward
0
arrow_downward

@Rajan - Несколько комментариев:

  • каноническая документация для CQ находится здесь. Многое из того, что я предлагаю, исходит оттуда.
  • Вы используете обратную ссылку? Я вижу, что ваш пример CQ использует GROUP BY time(10m),* - подстановочный знак * обычно используется с обратные ссылки. В противном случае я не думаю, что вам нужно включать *, чтобы указать группировку по всем тегам - он уже должен быть сгруппирован по всем тегам.
  • Если вы используете обратные ссылки, это запускает CQ для каждого измерения в базе данных metrics. Это потенциально может быть очень много выполнений CQ одновременно, особенно если у вас так определено много CQ.
  • Вы можете установить смещения с помощью GROUP BY time(10m, <offset>), но это также влияет на временной интервал, используемый для вашей функции агрегирования (sum в вашем примере), поэтому, если ваше смещение составляет 1 минуту, то временные метки будут суммой данных между, например. 13: 11- ›13:21 вместо 13:10 -› 13:20. Это компенсирует выполнение, но может не сработать для вашего варианта использования понижающей дискретизации. С точки зрения обработки сигнала смещение в 1 минуту не изменит достоверность субдискретизированных данных, но может вызвать нежелательные проблемы с графическим отображением в зависимости от того, что вы делаете. Предлагаю попробовать этот вариант.
  • В противном случае вы можете попытаться уменьшить количество CQ с пониженной дискретизацией, чтобы уменьшить нагрузку на память или понизить дискретизацию в более крупном масштабе времени (например, 20 м), или, наконец, увеличить аппаратные ресурсы, доступные для InfluxDB.
  • Для управления использованием памяти посмотрите в этом посте. В 1.8 корректировок не так много, но они есть.
person Phil    schedule 27.10.2020