Оптимизация включала уменьшение количество буферов :) теперь они привязаны к количеству cpu спасибо @valyala

можете детальнее описать сетап и методику теста для селектов?

Да, конечно. Для тестов используем google compute engine с 2 vCPU, 8 GB, Ubuntu 20.04. Чтобы исключить все случайные факторы, связанные с природой облака, запускаем два экземпляра vm параллельно на одной машине и ограничиваем их cpu до 1 процессора(пробовали не ограничивать вообще или присваивать конкретное  ядро, не меняет результатов), память до 30%. Сравниваем только производительность этих экземпляров между собой). Docker образы для vm  собираем сами из кода с помощью описанных в readme команд(с версиями с dockerhub те же результаты).

На другой машине запускаем клиенты для тестов. В качестве клиентов используем TSBS(https://github.com/timescale/tsbs). Селекты для теста: 8640 штук  cpu-max-all-8, 1440 double-groupby-all. Для обоих типов используем 10 worker'ов(количество тоже не сильно влияет на результаты, кроме случая когда их слишком мало). Тесты запускаем параллельно, нагрузка подобрана так, чтобы у клиентов всегда было достаточно памяти и цпу.

Как уже написал выше производительность отличается на 15-20% раз в 3-4 коммита. Пробовали также запускать клиенты на той же машине, так чтобы всем хватало цпу и памяти, результаты это не поменяло. Перепробовали много всего. Аналогичный сетап для InfluxDB работал.

Сейчас сочиняю хранение "долгих метрик"
Пока хочу слать из из прома внутир кубера через remote_write.

    remoteWrite:
      - url: '${PROMETHEUS_EXTERNAL_STORAGE_1}'
        writeRelabelConfigs:
        - sourceLabels: [__name__]
          regex: '^[metric1|metric2|metric3]$'
          action: keep

Т.к. метрик будет много это будет здоровенная портянка
Есть ли более изящный способ перечислить метрики дропнуть остальное?
Вдруг кто-то сочинял подобное

> запускаем два экземпляра vm параллельно на одной машине

- имеются в виду сингл версии или кластерные версии?
- клиент tsbs идет всегда в одинаковом порядке по запросам?
- при чтении данных, вм mmap"ит блоки с данными в память. Если данные остаются в page cache - доступ к ним быстрый. Если другой процесс вытесняет прочитанные блоки из page cache, то повторный доступ к ним приведет к дополнительным задержкам на IO. Вы можете удостоверится, что между процессами вм нет гонки за вытеснение данных из памяти? (на оф дашборде должны быть панели показывающие кол-во прочитанных из диска данных)

А подскажите, есть ли вариант в Виктории сдалть запрос по конкретному диапазону времени?
00.00 - 23:59, сумму посмитать по метрики например 🤔

Да, это можно сделать, отправив запрос sum_over_time(metric[1d]) на /api/v1/query с параметром time, указывающем на окончание заданного диапазона времени. Тогда он вернет суммы всех значений по каждому ряду с именем metric на заданном интервале времени. См. https://prometheus.io/docs/prometheus/latest/querying/api/#instant-queries

Если нужно получить сумму всех значений по всем метрикам с именем metric, то нужно завернуть запрос из комментария выше в sum()

ясно, спасибо! я думал что может это можно сделать в MetricQL/PromQL миную взаимодействие с API

Можно, если в графане выбрать нужный промежуток времени и использовать $__range внутри квадратных скобок

о, как вариант тоже хорошо) спасибо за наводку

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

Подцепили дашбоард  сейчас и судя по нему чтением с диска можно пренебречь. У нас не так много датапоинтов(175 млн с 400 временных рядов).  Также попробовали провести тест с 16 гб памяти и это не повлияло на производительность.

На фото disk IO для инсертов, а затем селектов(в хвосте)

спасибо!
Последовательные тесты на чтение для одного и того же вм процесса показывают стабильные рез-ты (без паралельного опрашивания второго)?

а почему на дашборде кластера нет метрики bytes per point?

а зачем insert нодам передавать список select нод?

забыли мб) создайте тикет чтобы не потерялось плз

хорошо

чтобы сбрасывать кеш на vmselect'ах при удалении метрики

а, оно не на графике, а отдельной панелью

ребят, а поделитесь опытом размазывания кластера виктории между двумя дц. интересует, что для балансировки вставки/чтения метрик использовали и как выглядит у вас избыточность компонентов