Здравствуйте! Помогите разобраться с проблемой, пожалуйста. Переехали на новый кластер

clickhouse, 10 шардов по 3 реплики, равномерно записали данные во все шарды.
Запросы работают хорошо, если в SELECT части запрашивается мало колонок, но если запросить по * или перечислить много колонок (у нас их примерно 1000),
то большинство шардов (обычно 9 из 10) выполняют запрос быстро (например 3 секунды), а один шард отдает за 60 секунд. При этом иногда все шарды отвечают за 3 секунды и запрос завершается быстро.
Со стороны выглядит будто запрос очень быстро отрабатывает на 98% и потом зависает на 55 секунд. Может каких-то потоков на чтение не хватает?

На старом кластере таких проблем не было, но там distributed запросы не так часто обращались ко всем шардам (данные лежали не равномерно, а разделены по датам между шардами). Также в старом кластере была другая версия clickhouse 23.3 LTS, теперь 23.8 LTS.

Пробовали применить настройку local_filesystem_read_method: read - проблема осталась без изменений.

что в system.query_log проблемного шарда для дочерней initial_query_id вашего запроса в ProfileEvents и query_duration_ms ?

Как такового одного проблемного шарда \хоста нет, они все время разные для разных запросов query_duration_ms: 96677 ProfileEvents. {'Query':1,'SelectQuery':1,'QueriesWithSubqueries':1,'SelectQueriesWithSubqueries':1,'FileOpen':1326,'ReadBufferFromFileDescriptorReadBytes':6301636738,'ReadCompressedBytes':5344578591,'CompressedReadBufferBlocks':390473,'CompressedReadBufferBytes':26353692217,'OpenedFileCacheHits':7326,'OpenedFileCacheMisses':1326,'OpenedFileCacheMicroseconds':19677,'IOBufferAllocs':16571,'IOBufferAllocBytes':718122149,'FunctionExecute':217105,'MarkCacheHits':8022,'MarkCacheMisses':657,'CreatedReadBufferOrdinary':8652,'DiskReadElapsedMicroseconds':27518514,'NetworkReceiveElapsedMicroseconds':3832,'NetworkSendElapsedMicroseconds':66322,'NetworkReceiveBytes':110,'NetworkSendBytes':2829584,'SelectedParts':6,'SelectedRanges':29601,'SelectedMarks':86169,'SelectedRows':204338531,'SelectedBytes':3376589005,'WaitMarksLoadMicroseconds':1074432668,'LoadedMarksCount':882437029,'LoadedMarksMemoryBytes':2271793616,'ContextLock':8687,'ContextLockWaitMicroseconds':5761,'RWLockAcquiredReadLocks':1,'PartsLockHoldMicroseconds':45,'RealTimeMicroseconds':1739002453,'UserTimeMicroseconds':134077382,'SystemTimeMicroseconds':8666225,'SoftPageFaults':1641539,'HardPageFaults':3,'OSIOWaitMicroseconds':23900000,'OSCPUWaitMicroseconds':1662260,'OSCPUVirtualTimeMicroseconds':142705859,'OSReadBytes':5588750336,'OSWriteBytes':12288,'OSReadChars':6337477090,'OSWriteChars':21148386,'QueryProfilerSignalOverruns':74558,'QueryProfilerRuns':65489,'ThreadPoolReaderPageCacheMiss':68243,'ThreadPoolReaderPageCacheMissBytes':6301636738,'ThreadPoolReaderPageCacheMissElapsedMicroseconds':27518514,'AsynchronousReadWaitMicroseconds':35337771,'LogDebug':7}

посмотрите query_log на всех нодах для одного медленного запроса особенно на event_time. Надо понять запрос поздно прилетел на шард или шард долго читал, или долго отдавал

event_time у всех QueryStart строчек одинаковый, то есть запросы прилетели одновременно

'LoadedMarksCount':882437029 гхм... 'WaitMarksLoadMicroseconds':1074432668 ну это суммарно по всем тредам 17 минут... если ядер 17 томожет тут ваша минута.. 'MarkCacheHits':8022,'MarkCacheMisses':657 хотя вроде оно из кеша все 91% а не с диска... 'SoftPageFaults':1641539 у вас там в swap случайно не залазит все? The number of soft page faults in query execution threads. Soft page fault usually means a miss in the memory allocator cache which required a new memory mapping from the OS and subsequent allocation of a page of physical memory.

16 CPU 64 RAM хосты

и? это не значит что свап например отключен... 'DiskReadElapsedMicroseconds':27518514 25 секунд с диска читалось что-то... там кроме clickhouse у вас что-то еще запущено?

Это я подтвердил, что у нас около 17 ядер) Уточнил у коллег, swap не используется. Кроме clickhouse ничего не запущено.

А прямо на шарде запросы к mergetree тормозят? Но вообще похоже на загрузку засечек в кеш засечек.

У нас ReplicatedReplacingMergeTree, если обращаться только к локальной таблице, а не distributed, то так же иногда тормозит, но реже чем у distributed (видимо потому что в этом случае мы зависим от скорости 1 хоста, а не от 10)

Ну сделайте markcache 10гб а не 5

Попробуем, спасибо

https://clickhouse.com/docs/en/operations/server-configuration-parameters/settings#mark_cache_size вот эту опцию увеличьте

помогло, спасибо!