on tab final.
Вставки одинакового размера.
Вставки в одну партицию.
Параллельно с ними в эту же таблицу и в эту партицию идут вставки Insert values
Могут ли они друг друга аффектить?
Происходит то, что иногда вставки деградируют по скорости в 10 раз. Хочу выяснить почему так может происходить.
каждая вставка порождает парт. Это отдельный подкаталог с полной структурой файлов таблицы. Друг на друга они никак не влияют, но используют общие iops диска и циклы CPU. После этого бекграунд процесс мерджит эти парты в более крупные. Мерждит - это читает, декомпрессирует, совмещает по порядку order by, компрессирует, пишет. И так постоянно. Не стоит делать много вставок. Особенно в 5-10 потоков. Нужно делать мало больших вставок, используя для этого какие-то внешние инструменты (kafka, kittenhouse , etc). Хороший размер вставки 100к
100к не можем вставлять, так как нужно вставлять быстро обновления делаем по 5-10к, потому что результаты нужны прям вот онлайн.
Используете SSD? Включены compact парты? Какая версия кх?
Да, данные на ссд. 21.2.9.41.
Replicated таблица? Какая версия КХ? То что вам тут наговорили скорее всего не связано с этим
да, replicated. 1 шард - 3 реплики, все версии 21.2.9.41 пишем только в одну
включите part_log или посмотрите в логе есть ли параллельно мержи посмотрите летенси в ZK , и сообщения в логе ZK про слишком долгие запись на версиях типа 20.8 тоже самое? в общем есть какая-то проблема которую пока не воспроизвели, не могу найти в гитхабе, потом напишу
до этого была версия 20.1.3.7, там с такими нагрузками не работали
ZK вдруг не на тех же серверах что и кх?
нет конечно)
параллельные мерджи при запросе вставки? или чего?
Мержи в тоже самое время что и инсерт https://github.com/ClickHouse/ClickHouse/issues/26755
нашел нужные query_id, нашел время в part_log и отфильтровал part_log по этому промежутку времени + по пару секунд с разных сторон, остортировал по event_time MergeParts показывает после запросов на вставку. То есть во время вставки никаких мерджей не было, как я понял.
это абсолютно похожая ситуация, подобные варнинги постоянно в логах реплик Found parts with the same min block and with the same max block as the missing part 1627030800_61998_62022_2. Hoping that it will eventually appear as a result of a merge.
Обсуждают сегодня