rollup делается во время мержей. Мержи букают 2 размера суммарного исходных партов.

<function>avg</function> -- считается неправильно, потому что это avg

Добрый день! Наблюдаю проблему с тем, что конфигурация rollup в GraphiteMergeTree в какой-то момент перестала выполнять агрегацию. Версия кликхаус ClickHouse server version 19.8.3.8 (official build).

Настройки rollup:

<graphite_rollup>
        <path_column_name>Path</path_column_name>
        <time_column_name>Time</time_column_name>
        <value_column_name>Value</value_column_name>
        <version_column_name>Timestamp</version_column_name>
        <default>
            <function>avg</function>
            <retention>
                <age>0</age>
                <precision>1</precision>
            </retention>
            <retention>
                <age>86400</age>
                <precision>60</precision>
            </retention>
            <retention>
                <age>864000</age>
                <precision>900</precision>
            </retention>
            <retention>
                <age>1728000</age>
                <precision>1800</precision>
            </retention>
        </default>
    </graphite_rollup>

Конфигурация таблицы:

CREATE TABLE graphite (`Path` String, Value Float64, Time DateTime, Date Date, Timestamp UInt32) ENGINE = GraphiteMergeTree('graphite_rollup') PARTITION BY toYYYYMM(Date) ORDER BY (Path, Time) SETTINGS index_granularity = 8192

Запрос метрики за 17.06.2020 (сегодня 14.07.2020) возвращает метрики с интервалом в 1 сек, хотя согласно настройкам метрика должна остаться 1 метрика за 30 мин.

SELECT *
FROM graphite
WHERE (Date = '2020-06-17') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2

┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │              4 │ 2020-06-17 23:59:59 │ 2020-06-17 │   1592427599 │
│ statsd.numStats │              4 │ 2020-06-17 23:59:58 │ 2020-06-17 │   1592427598 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘

А запрос метрики за 16.06.2020 возвращает метрики с интервалом в 1 минуту, и тоже не подходит не под одно правило

SELECT *
FROM graphite
WHERE (Date = '2020-06-16') AND (Path = 'statsd.numStats')
ORDER BY Timestamp DESC
LIMIT 2

┌─Path────────────┬──────────Value─┬────────────────Time─┬───────Date─┬────Timestamp─┐
│ statsd.numStats │              4 │ 2020-06-16 23:59:00 │ 2020-06-16 │   1592341199 │
│ statsd.numStats │              4 │ 2020-06-16 23:58:00 │ 2020-06-16 │   1592341139 │
└─────────────────┴────────────────┴─────────────────────┴────────────┴──────────────┘

Метрики за 26.06.2020 хранятся по одной секунде, а уже за 27.06.2020 - по одной минуте.
При выполнении OPTIMIZE получаю следующее:

## SET optimize_throw_if_noop = 1
## OPTIMIZE TABLE graphite PARTITION 202007 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 191.81 GB.
## OPTIMIZE TABLE graphite PARTITION 202006 FINAL
Code: 388. DB::Exception: Received from localhost:6788, 127.0.0.1. DB::Exception: Insufficient available disk space, required 124.50 GB.

Сами размеры партиций меньше, чем размер на диске, требуемый для выполнения OPTIMIZE:

SELECT
    table,
    sum(rows),
    partition,
    count() AS number_of_parts,
    formatReadableSize(sum(bytes)) AS sum_size
FROM system.parts
WHERE table = 'graphite'
GROUP BY
    table,
    partition
ORDER BY partition ASC

┌────table─┬──────sum(rows)─┬─partition─┬─number_of_parts─┬─sum_size───┐
│ graphite │     7171581973 │   202006  │               9 │ 57.98 GiB  │
│ graphite │    14093390942 │   202007  │             619 │ 89.65 GiB  │
└──────────┴────────────────┴───────────┴─────────────────┴────────────┘

Правильно ли я понимаю, что rollup не может выполниться из-за нехватки места на диске? если это так, то какие минимальные требования по размеру диска нужно закладывать при проектировании, если в качестве хранилища graphite метрик использовать clickhouse? Записываются ли в логи ошибки слияния партиций, чтобы по ним можно было сразу среагировать на невыполненное слияние?

про avg не понял. Что считается неправильно?

Всем привет, есть такая проблема. Примерно 2к селектов в секунду. Сначала всё ок. А потом начинает возвращать ошибку, что вся память закончилось. Не подскажите как решить? Кликхаус не умеет высвобождать память? Или нужно set max_memory_usage перед каждым запросом выставлять?

Подскажите не опытному )))
CREATE TABLE example (
 browser_id   UInt16,
 managers   Array(UInt64)
) engine=Memory

Как должен выглядеть запрос на поиск ГДЕ managers содержит в массиве 111122223333 ?

Коллеги, помогите с таким эксепшном.

На реплике:
2020.07.14 17:58:17.151895 [ 14 ] {} <Error> table: DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Timeout: connect timed out: 10.22.1.24:90090. 0xbc31e1b Poco::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)  in /usr/bin/clickhouse


Беспокоит 10.22.1.24:90090.
IP верный, но порт такой как получился? О_о

надо вам в ЗК смотреть как реплика себя анонсировала, я не понимаю почему там ip а не имя хоста, возможно лишний 0 это просто баг при логировании

В ЗК хостнеймы.

Что примечательно, репликация по этой таблице работает. Но периодически такая ошибка проскакивает. Иногда не получается сделать truncate с ошибкой таймаута, будто бы реплика недоступна, хотя в это же самое время telnet на порт проходит

на какой порт? порт репликации 9009

на 9009

попробуйте на ВСЕХ хостах

cd /etc/clickhouse-server/
grep -R 90090 *

пусто

select * from example where has(managers,111122223333)

Благодарю. Подскажите пожалуйста если внутри массива до 5 значений. Может быть имеет смысл в следующей структуре таблицы исходя из скорости нахождения manager:  

CREATE TABLE example (
 browser_id   UInt16,
 managers1   UInt64,
 managers2   UInt64,
 managers3   UInt64,
 managers4   UInt64,
 managers5   UInt64
) engine=Memory

если искать во всех 5 полях, то не имеет, даже наоборот

Благодарю. Подскажите пожалуйста если внутри массива до 5 значений. Может быть имеет смысл в следующей структуре таблицы исходя из скорости нахождения manager:  

CREATE TABLE example (
 browser_id   UInt16,
 managers1   UInt64,
 managers2   UInt64,
 managers3   UInt64,
 managers4   UInt64,
 managers5   UInt64
) engine=Memory

ClickHouse/ClickHouse tagged: v20.4.7.67-stable
Link: https://github.com/ClickHouse/ClickHouse/releases/tag/v20.4.7.67-stable
Release notes:

v20.4.7.67-stable

вообще конечно можно таблицу развернуть (столбцы в строки), и сделать manager в индексе или выкинуть нафиг КХ и взять православный PG (там индексировать массивы можно)