22.7.1.2484 выделено 16Гб. Он всегда потреблял около 2Гб, а неделю назад резко уперся в потолок и до сих пор его не отпускает. По статье https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-who-ate-my-memory/ выяснил, что это мержи.
```
SELECT table, result_part_name, formatReadableSize(memory_usage)
FROM system.merges order by table
+------------------------------------+----------------------+------------+
|table |result_part_name |memory_usage|
+------------------------------------+----------------------+------------+
|well_data_120_hub_us_pas_1852654119 |all_1421364_1423304_12|3.03 GiB |
|well_data_120_hub_us_pas_1852654119 |all_1412503_1417711_16|2.74 GiB |
|well_data_120_hub_us_pas_1852654119 |all_1368384_1412502_24|2.49 GiB |
|well_data_19_witsml_wel_1130857934 |all_2361041_2380784_70|3.68 GiB |
|well_data_1_witsml_wel_1130857934 |all_190146_274401_89 |2.40 GiB |
|well_data_255_witsml_us__1445694652 |all_7542_12413_22 |1.52 GiB |
|well_data_334_witsml_wel__1828797414|all_525481_1051874_103|3.16 GiB |
|well_data_334_witsml_wel__1828797414|all_1126525_1130189_14|2.85 GiB |
|well_data_48_rockpigeon_205310986 |all_172680_186459_44 |3.96 GiB |
|well_data_48_rockpigeon_205310986 |all_187844_188616_16 |3.74 GiB |
+------------------------------------+----------------------+------------+
```
В логах куча ошибок
<Error> MergeFromLogEntryTask: virtual bool DB::ReplicatedMergeMutateTaskBase::executeStep(): Code: 241. DB::Exception: Memory limit (total) exceeded: would use 13.84 GiB (attempt to allocate chunk of 4210192 bytes), maximum: 13.84 GiB. OvercommitTracker decision: Memory overcommit isn't used. Waiting time or orvercommit denominator are set to zero..: (while reading column rss_tfds_64d98624f0): (while reading from part /var/lib/clickhouse/data/prod_0_replica_0/well_data_48_rockpigeon_205310986/all_187466_187663_13/ from mark 18 with max_rows_to_read = 1638): While executing MergeTreeSequentialSource. (MEMORY_LIMIT_EXCEEDED)
Как можно подтюнить Clickhouse под 16Гб?
Количество тредов уменьшить? Может есть лимит памяти на мержи?
Привет! Ещё актуально. Clickhouse таки ушел в даунтайм, в логах куча ошибок про нехватку памяти для мержа, iops диска выжран полностью. Остановили вставку данных совсем, но легче не стало. В итоге добавили свопа 100Гб, Clickhouse минут 5 его поиспользовал и бросил. Все ожило, ошибки про память ушли, диск вернулся в норму, оперативка вернулась в норму, своп больше не используется. Такое чувство, что Clickhouse зациклился на мерже одних и тех же партиций, которые в память не влазили. Зачем ему столько памяти на мерж? И можно ли её размер ограничить?
А что такое мерж? Это слияние двух частей. А как их слить на физическом уровне? Вероятно, поднять все данные в память, слепить новый кусок из двух и положить на диск. А если парты большие, то и данных много и памяти надо много....
нет. мердж-сорт как раз таков, что ему не надо всё поднимать в память
сколько памяти будет использовано на мерж зависит от типа мержа, вертикальный или горизонтальный, от того что написали в полях default/materialized (там я видел ужасно тяжелые функции) и от длины строк String и размера state-в AggregateFunction
а как узнать какой именно мерж? Таблички у нас вот такие только, никаких мат вьюх нет на них. сreate table well_data_XXX ( ind1 UUID, ind2 String, ind3 DateTime64(3), created_at SimpleAggregateFunction(anyLast, DateTime64(3)) default now64(), f1 SimpleAggregateFunction(anyLast, Nullable(Float64)), f2 SimpleAggregateFunction(anyLast, Nullable(Float64)), f3 SimpleAggregateFunction(anyLast, Nullable(Float64)), ... ) engine = ReplicatedAggregatingMergeTree('path', 'replica_X') ORDER BY (ind1, ind2, ind3)
В system.merges видно сколько памяти мерж использует. И в part.log
Обсуждают сегодня