Добрый день, мы столкнулись с такой проблемой, есть таблица mytable,

Question

Добрый день, мы столкнулись с такой проблемой, есть таблица mytable,

которая,

PARTITION BY ((toYYYYMMDD(ConnFirstEventTimestamp) * 100) + toHour(ConnFirstEventTimestamp), shardid)

где shardid = [0...9]

Во время записи несколькими параллельными инсертами для разных часов, возникла ошибка "too many open files". Было принято решение подправить ulimit и перезапустить сервер. После service clickhouse-server restart, CH стартовал долго (около 40 минут), и в процессе запуска мы увидели в логе больше 50 тыс. сообщений типа
2020.02.06 18:07:48.361884 [ 232 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12418_12418_0
2020.02.06 18:07:48.364380 [ 104 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12547_12547_0
2020.02.06 18:07:48.420295 [ 141 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12738_12738_0
...
Посоветуйте, пожалуйста, как такого избежать?

@den_crane тут https://t.me/clickhouse_ru/139874 вы также писали подобные инсерты убивает зукипер. Почему?

P.S. Нам очень нужен партишнинг именно по часам + shardid (типа subpartitioning) - т.к. в час льётся "100500" ТБ данных.

#backend #clickhouse #database #devops #programming #russian

0

10.02.2020

1 ответов

27 просмотров

Denny [Altinity] · Accepted Answer

ой да, умора, вы конечно уникальные такие и трафика у вас больше чем Я и других мастодонтов которым хватает месячных партиций. Давайте посчитаем, вы уникумы льете 150ГБ в час, у вас там i/o не трещит не? 3.6TB в сутки, как вам hdd дисков на неделю-то хватает?

184 похожих чатов

Добрый день, мы столкнулись с такой проблемой, есть таблица mytable,

1 ответов

Похожие вопросы