Обсуждаем ClickHouse
А там не будет проблем с тем, что парты мелкие и он не будет сразу мерджить, ибо будет ждать какого-то размера выборки партов?
Читать полностью…тредов больше даешь, чаще мержит, в чем проблема
Читать полностью…это широко известная проблема, обновитесь на 25.6.8.10
Читать полностью…это очень сложно сделать, и это просто остановит инсерт совсем
Читать полностью…Коллеги подскажите как продиагностировать текущий расход памяти в clickhouse тестовый сервер поэтому сейчас удобно с ним возиться в clickhouse-client получаю отлуп
DB::Exception: Received from localhost:9000. DB::Exception: (total) memory limit exceeded: would use 29.49 GiB (attempt to allocate chunk of 4.11 MiB bytes), current RSS: 6.97 GiB, maximum: 28.21 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker. (MEMORY_LIMIT_EXCEEDED) (version 25.6.3.116 (official build))
event,
formatReadableSize(value) AS size
FROM system.events
WHERE (event LIKE '%Memory%') AND (value > 0)
ORDER BY value DESC
Query id: b3f1afe7-45a5-4aa9-aecd-b8ffbf65e3fd
┌─event────────────────────────────────┬─size───────┐
1. │ LoadedMarksMemoryBytes │ 10.23 GiB │
2. │ MemoryWorkerRunElapsedMicroseconds │ 2.41 GiB │
3. │ QueryMemoryLimitExceeded │ 65.37 MiB │
4. │ MemoryWorkerRun │ 37.00 MiB │
5. │ MemoryAllocatorPurgeTimeMicroseconds │ 114.83 KiB │
6. │ MemoryAllocatorPurge │ 4.00 B │
└──────────────────────────────────────┴────────────┘
SELECT
metric,
formatReadableSize(value) AS size
FROM system.metrics
WHERE metric LIKE '%Memory%'
ORDER BY value DESC
Query id: f80e27b6-7bf7-4964-93c9-a412bacdfd5e
┌─metric────────────────────────┬─size───────┐
1. │ MemoryTracking │ 29.40 GiB │
2. │ MergesMutationsMemoryTracking │ 184.34 MiB │
3. │ MemoryTrackingUncorrected │ 1.71 MiB │
└───────────────────────────────┴────────────┘
SELECT *Читать полностью…
FROM system.asynchronous_metrics
WHERE name LIKE 'jemalloc%'
Query id: 52c6e2e4-a19c-41cf-9b20-28f20c76fb52
Connecting to database system at localhost:9000 as user default.
Connected to ClickHouse server version 25.6.3.
┌─metric───────────────────────────────────┬───────────value─┬─description────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
1. │ jemalloc.prof.active │ 0 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
2. │ jemalloc.background_thread.run_intervals │ 139996961466912 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
3. │ jemalloc.allocated │ 998048928 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
4. │ jemalloc.metadata │ 210529648 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
5. │ jemalloc.resident │ 1441112064 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
6. │ jemalloc.arenas.all.muzzy_purged │ 0 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
7. │ jemalloc.metadata_thp │ 0 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
8. │ jemalloc.arenas.all.pmuzzy │ 0 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
9. │ jemalloc.background_thread.num_threads │ 4 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
А если временно лимит поменять какой-нибудь, чтобы чаще мерджил мелкие парты?
Читать полностью…раньше была проблема из-за того что клинер чексумм дедупликации высасывал из зукипера все чексуммы для всех партиций и это создавало трафик и нагрузку на cpu
Читать полностью…Ну ладно, согласен, в контексте одной MV-шки наверное и правда сложновато этого добиться, но вообще вам бы в наследство какой то кластерок на сотню другую териков, да со снятым этим самым ограничением, да с каким высококардинальным полем в ключе партиционирования. Вы бы увидели что происходит с кипером при этом.
Читать полностью…да не будет он пухнуть. 50000 партов это ничто для кипера
Читать полностью…и наблюдать как кипер пухнет по памяти и cpu, с последующей деградацией вставки, уходом таблиц в ридонли, лагом репликации...
Читать полностью…замедлить вставку
поменять лимит для too many parts на бесконечность
лить по партициям
Мысль вашу понял. Благодарю)). Но к этой прекрасной функции нет пока прав
Читать полностью…ну или из system.clusters, если нет доступа к консоли
Читать полностью…Спасибо.:) забыли добавить "в узких кругах"
Читать полностью…почему же сложно, ручка background_pool_size вам знакома?
Читать полностью…ну одно следствие другого в моём примере
Читать полностью…
10. │ jemalloc.active │ 1112510464 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
11. │ jemalloc.background_thread.num_runs │ 31250568 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
12. │ jemalloc.retained │ 44659097600 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
13. │ jemalloc.arenas.all.pactive │ 271609 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
14. │ jemalloc.mapped │ 1478246400 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
15. │ jemalloc.epoch │ 2004271 │ An internal incremental update number of the statistics of jemalloc (Jason Evans' memory allocator), used in all other `jemalloc` metrics. │
16. │ jemalloc.arenas.all.pdirty │ 34507 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
17. │ jemalloc.arenas.all.dirty_purged │ 70340000818 │ An internal metric of the low-level memory allocator (jemalloc). See https://jemalloc.net/jemalloc.3.html │
└──────────────────────────────────────────┴─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Не знаю насколько это хорошо, конечно
Читать полностью…сейчас клинер не сосет чексуммы если не было инсертов в партицию
но кол-во партов в партиции на это не влияет
много партиций и много партов -- это не одно и тоже
Читать полностью…проблема большого кол-ва партов это замедление селектов, если селекты никто не делает, то это и не проблема
Читать полностью…я через freeze ктстти перезаливаю
https://den-crane.github.io/Everything_you_should_know_about_materialized_views_commented.pdf slide 36
Отдетачить MV, перезалить "from" таблицу, перезалить "to" таблицу запросами об "from" забирая пачками побольше учитывая партиционирование "to" таблицы, приатачить MV назад.
Читать полностью…Здравствуйте. При полном перезаливе сорс таблицы МВ пишет в партиционированную таблицу и разделяет батч на парты для каждой партиции, это выливается в большое количество мелких parts per partition и начинаются delay и reject инсертов.
Можно что-то сделать вроде буффера или есть другие варианты? Вставка синхронная
я надеюсь вы не повторили запрос ещё на каждой реплике, если что можно при походе в clusterAllReplicas(...) попросить среди прочих колонок hostName()
и даже погруппироваться, какие реплики победовее будут )
да ну... вообще count() = 0 в квери логе? выключен?
Читать полностью…Кстати по всему полю exception_code = 0
Читать полностью…а на соседних репликах?
from clusterAllReplicas(ваш_кластер_из_remote_servers,system,query_log)