шардах, делаю один распределенный запрос, который равномерно использует все четыре шарда, данные довольно ровно разложены по машинкам, конфигурации у серверов одинаковые, живут в одном ДЦ, но раз за разом 1 из 4х шардов здорово отстает от остальных. в query_log картинка примерно такая (проблемный и два других шарда)
ms | read_rows | read_bytes
1555 │ 89996061 │ 899960610
450 │ 89221474 │ 892214740
475 │ 89227264 │ 892272640
т.е. проблемный в три раза медленнее, обрабатывает примерно аналогичное число и строк, и байт, таблицы оптимизированы, optimize final выполнен, активных партов на шардовых таблицах по 1, и на проблемном, и на остальных серверах, при других выборках ситуация аналогичная, на более масштабных выборках, когда суммарно запрос выполняется за 37 секунд, то все шарды отсреливаются за 16-17, а проблемный - за 35 и цифры на нем в сравнении с другим выглядят примерно так
34903 │ 1250343709 │ 12503437090
16655 │ 1250281826 │ 12502818260
куда копать, на что смотреть, какие инструменты могут пролить свет?
А этот проблемный случайно не шард-инициатор рапред.запроса?
1. не виртуалки? 2. смотреть латенси дисковой системы
Обсуждают сегодня