11238
Обсуждаем ClickHouse
щас
т.е. у нас есть паркет , у него есть блок
input_format_parquet_prefer_block_bytes прмерно 16 МБ
у нас есть 8 ядер
т.е. каждый блок развернется в памяти но ок на 160 мб
8* 160 мб = 1.6 гб запишется в кх. откуда там на 30 гб?
сорри если не так считаю
Объем всех паркетов за день =2 ГБ
Дак попробуйте, если поможет, то у вас не хватает памяти, чтобы обрабатывать файлы во все потоки
Читать полностью…
но у нас нет проекций, таблицы system.projection_parts system.projection_parts_columns system.projection пустые
Читать полностью…
так я не против ) я просто понять хочу из-за чего проблема с памятью
Читать полностью…
а что за файлы? а то у паркетов, там свой размер блока, через размер роугрупы
Читать полностью…
вот это то и не понятно )
т.е. он нормально читает с 1 до 20 файла, а на 22 условно падает
я делаю вывод, что где то накапление в памяти чего то идет
причем размер max_block_size роли не играет все равно на 20 падает
нет, в таком случае, остальне ядра будут проставить и будет долго грузиться же.
я размером блока же рулю объем обработки батчей
т.е. идея есть много маленькими порциями
в 1 дне: 25 файлов ( по часам)
сорри, я не понимаю связь
да даже если 8 потоков
у него max_block_size = 1
он же не будет пытаться все паркеты в памяти держать,
он прочитал 8 файликов = по 1 строке вставляет (8 строк)
т.е. вы предлагаете сделать max_threads=1 ?
чем это поможет? остальыне 7 ядер будут мержить в фоне?
settings max_threads=1 ?
>он читает в цикле, но не сбрасыавет кеш?
нет, он просто 10005000 файлов разом процессит
вообщем несколько дней бьюсь ) SETTINGS max_block_size = 1 и 100 и 1000 и 10000все равно Exception: (total) memory limit exceeded: would use 26.33 GiB (attempt to allocate chunk of 5.04 MiB), current RSS: 27.58 GiB, maximum: 27.57 GiB. OvercommitTracker decision: Query was selected to stop by OvercommitTracker. Stack trace:
читаю данные с s3 по 1 дню (1 гб в паркете в дне)
мне кажется, он читает в цикле, но не сбрасыавет кеш?
подкиньте плиз идей кудо покопать?
вроде есть баги про проекции, show create table DB.table
еще возможно что битый minmax индекс, который побился в сильно раньше
там однопоточный инсерт из distributed в шарды, просто не успевает, мелкие инсерты
попробуйте поменять insert_distributed_sync на 1
Кластер из примера на локальном компе
Наливаю в таблицу Distributed
Растет очередь distribution_queue
SELECT *
FROM system.distribution_queue
Row 1:
──────
database: obs
table: metrics_null
data_path: /var/lib/clickhouse/store/392/392d910a-15f9-400d-aef2-897947b7e22a/shard2_all_replicas/
is_blocked: 0
error_count: 0
data_files: 3268
data_compressed_bytes: 349309099 -- 349.31 million
broken_data_files: 0
broken_data_compressed_bytes: 0
last_exception:
last_exception_time: 1970-01-01 00:00:00
implicit_projections это проекции созданные в памяти неявно из minmax индексов от partitionby и orderby
читайте как дебажат и воспроизводят иши https://github.com/ClickHouse/ClickHouse/issues?q=is%3Aissue%20state%3Aopen%20optimize_use_implicit_projections
читайте все закрытые и все открытые иши
вы представляете как паркет устроен? что оттуда нельзя прочитать одну строку?
Читать полностью…
Всем привет, столкнулся с проблемой, в КХ заливаются логи командой 'INSERT INTO db.table FORMAT JSONEachRow' в поле c типом String.Проблема: в поле ничего не записывается, вставки пустые, в err.log ошибки отсутствуют, в query.log в эту таблицу по цифрам есть вставка. Может кто-то знает куда копать?
Читать полностью…
input_format_parquet_enable_row_group_prefetch │ 1
input_format_parquet_max_block_size │ 65409
input_format_parquet_prefer_block_bytes │ 16744704
Понял. А чё тогда памяти то не хватает )
Читать полностью…
да, предлагаю. Память у вас улетает, потому что КХ пытается разом проглотить 10005000 файлов
Читать полностью…
Встречаются двое глухих.
-Ты в баню?
-Да нет в баню.
-А,я подумал ты в баню.
:)
SELECT max(calc_time)Читать полностью…
FROM DB.table
SETTINGS optimize_use_implicit_projections = 0
┌──────max(calc_time)─┐
1. │ 2025-10-21 12:53:07 │
└─────────────────────┘
что показывает
SELECT max(calc_time) FROM DB.table settings optimize_use_implicit_projections=0
┌─statement─────────────────────────────────────────────────────────────────────────────┐Читать полностью…
1. │ CREATE TABLE DB.table ↴│
│↳( ↴│
│↳ `directory_service_name` String, ↴│
│↳ `calc_time` DateTime, ↴│
│↳ `calc_type` UInt8, ↴│
│↳ `status` UInt8, ↴│
│↳ `rm_log` String, ↴│
│↳ `ad_log` String ↴│
│↳) ↴│
│↳ENGINE = Distributed('cluster', 'DB', 'table_repl_sharded', rand()) │
└───────────────────────────────────────────────────────────────────────────────────────┘
подскажите, известно про такое поведение? Версия 25.8.10.7
SELECT max(calc_time)Читать полностью…
FROM DB.table
┌──────max(calc_time)─┐
1. │ 1970-01-01 00:00:00 │
└─────────────────────┘
SELECT max(calc_time)
FROM DB.table
WHERE calc_time != 1
┌──────max(calc_time)─┐
1. │ 2025-10-21 12:53:07 │
└─────────────────────┘
SELECT max(calc_time)
FROM DB.table
WHERE calc_time != 2
┌──────max(calc_time)─┐
1. │ 2025-10-21 12:53:07 │
└─────────────────────┘
SELECT
max(calc_time),
max(1)
FROM DB.table
┌──────max(calc_time)─┬─max(1)─┐
1. │ 2025-10-21 12:53:07 │ 1 │
└─────────────────────┴────────┘
это ожидаемо
надо в явном виде указывать Decimal(76,0)
Добрый день, подскажите, пожалуйста, ожидаемое это поведение или это баг. При использовании в запросе большого числа оно автоматически приводится к типу Float64, что в моем случае приводит к неправильному результату на запрос:
clickhouse-01.test.net 🙂 🙂 select points from some_table final where some_field = unhex('some_hex')
AND requested_block_number > 23146000 and points = 2441753498842748200000000000000000000000000000000000 limit 10;
SELECT points
FROM some_table
FINAL
WHERE (some_field = unhex('some_hex')) AND (requested_block_number > 23146000) AND (points = 2.4417534988427482e51)
LIMIT 10
┌───────────────────────────────────────────────points─┐
1. │ 2441753498842748218059455865257984907244327467332535 │
2. │ 2441753498842748218059455865257984907244327467332535 │
3. │ 2441753498842748218059455865257984907244327467332535 │
4. │ 2441753498842748218059455865257984907244327467332535 │
5. │ 2441753498842748218059455865257984907244327467332535 │
6. │ 2441753498842748218059455865257984907244327467332535 │
7. │ 2441753498842748218059455865257984907244327467332535 │
8. │ 2441753498842748218059455865257984907244327467332535 │
9. │ 2441753498842748218059455865257984907244327467332535 │
10. │ 2441753498842748218059455865257984907244327467332535 │
└──────────────────────────────────────────────────────┘
10 rows in set. Elapsed: 0.109 sec. Processed 6.49 million rows, 389.29 MB (59.27 million rows/s., 3.56 GB/s.)
Peak memory usage: 15.49 MiB.
[clickhouse-01.test.net] 2025.10.21 12:19:54.384464 [ 464524 ] {} <Debug> `some_database`.some_table ... Query condition cache has dropped 0/5291 granules for WHERE condition and(equals(points, 2.4417534988427482e51_Float64), ...