Pull to refresh

Comments 15

Вы тестируете исключительно с очисткой исторических данных housekeeper'ом либо ещё и Automatic Data Retention Policies самого TSDB (который входит в версию Enterprise)? Если пробовали последнее, то заметна ли разница в производительности?
Очистка исторических данных производится хаускипером, версию Enterprise не тестировали.

Можно организовать удаление housekeeper'ом, но не через DELETE FROM, а именно через drop_chunk() самого TimescaleDB. Поэтому enterprise фича не особо и нужна, если housekeeper научится понимать дроп чанков из расширения. Можно добавить галочку в настройки, а в коде сделать if-else блок с DELETE FROM или drop_chunk() =)

Да, у нас так и сделано — если работаем с TSDB, то housekeeper вызывает drop_chunks().

Отличная статья! Не зря общались на HL++ в Новосибирске на стенде :)

У нас уже полтора месяца используется связка Zabbix+TimescaleDB на средних размеров инсталляции. Время запросов в таблицы history с использованием встроенных функций timescale увеличилась примерно на порядок. Скорость обычных запросов, которые использует и сам Zabbix — выросла, но несущественно (процентов на 30-50). Возможно, нужно что-то ещё тюнить
Я смотрел исходники Zabbix 4.2.1 — там все изменения, касающиеся timescale, сводятся к очистке исторических данных, хаускипингу. К сожалению, собственно select-запросы не учитывают использование tsdb, так что о каком-то существенном росте производительности в данном случае говорить не приходится. Надеюсь, что выборка из исторических таблиц будет учитывать tsdb в следующих версиях.

Время запросов в таблицы history с использованием встроенных функций timescale увеличилась примерно на порядок

то есть стало хуже?
Время запросов в таблицы history с использованием встроенных функций timescale увеличилась примерно на порядок

Вот я тоже не понял. Запросы стали в 10 раз дольше выполняться?

Падения производительности наши тесты точно не показывают, но, конечно, может быть по-всякому. Именно поэтому пока поддержка TSDB — экспериментальная. В 4.4 будут дополнительные оптимизации выборки из истории по рекомендациям инженеров TimescaleDB.
Ещё есть замечание к статье: упор на производительность операций записи не очень понятен.
Если в системе мониторинга хотя бы 10% от количества items составляют triggers и calculated items — именно их расчёт становится «узким местом», поскольку требуется выборка исторических данных. И как раз здесь сочетание Zabbix+TimescaleDB не даёт тех существенных преимуществ, которые могло бы дать, если бы select'ы на получение исторических данных использовали встроенные функции TSDB.
Например:
SELECT time_bucket(180, clock) period,
       max(ho.host) HOST,
                    max(i.key_) item_key,
                    last(value, clock) item_value
FROM history h
INNER JOIN items i USING(itemid)
INNER JOIN hosts ho USING(hostid)
WHERE
  h.clock > (extract(epoch FROM now()) :: int - 300)
    AND
  i.key_ ~ '^(system|vm\.mem|vfs\.fs)\.'
GROUP BY ho.hostid,
         i.itemid,
         period
ORDER BY period DESC
Есть замеры поновее, с триггерами, посмотрите презентацию здесь: www.highload.ru/siberia/2019/abstracts/5390
Если общественность проявит достаточный интерес, то расскажем об этом всём подробнее на конференции в августе в Москве.

Мне одному кажется что графики nvps по полчаса каждый — маловато? Стандартный хаускипер запускается каждый час, а тут как?

Думаю, Zabbix стоит выложить на github эти бенчмарки, и все встанет на свои места.

Конкретно в этих графиках хаускипер действительно не запускался, т.к. интересовала в первую очередь производительность TSDB. Есть уже выше упомянутые замеры на более протяжённых отрезках, там учитывается и работа хаускипера. Посмотрите эту презентацию: www.highload.ru/siberia/2019/abstracts/5390
Sign up to leave a comment.