чем с --send_logs_level=trace?
Не понятна причина стабильной скорости работы вот такого плана:
<Debug> MergeTreeReadPool: Slow read, event №1: read 1048576 bytes in 1.244 sec., 0.843 MB/s.
<Debug> MergeTreeReadPool: Slow read, event №2: read 1048576 bytes in 1.060 sec., 0.989 MB/s.
При этом диски загружены на 40-60%, памяти под кэш еще прилично, а повторные запросы выполняются вот с такой фееричной скоростью.
врятли. это самые подробные ну можно еще попробовать flamegraph построить из system.trace_log для конкретной query ну вообще 40-60% это сколько IOPS в штуках и на каком оборудовании? ;)
Рейд из обычных дисков
так вы latency покажите рядом. само по себе использование ни о чем не говорит... даже чем больше - тем лучше тут может быть: - у вас ХФС (у нас он иногда уходит в себя периодами и выжирал ИО) - у вас кеш ФС спойлится - допустим рядом ИО интенсив приложение, даже если оно читает пишет на другой массив дисков, это все равно влияет - у вас диски не успевают за ЦПУ когда данные часто не в кеше. уменьшаете max_threads и проверяете.
Если ХФС - это HFS, то ее нет. Сервер только под КХ, повторный тот же самый запрос через секунду после завершения этого опять ставит КХ в позу на 30-50 секунд. Попробуем обновить его на более-менее свежий и последить пристальнее.
попробуйте последовательно уменьшать max_threads, и следите где latency перестанет проседать...
Обсуждают сегодня