ситуация, что одна реплика сильно отстала и никак не могла догнаться, пришлось этот параметр задрать до 512
Очевидно, что оставлять так не будем
Отсюда вопрос: можете ли порекомендовать как выбрать оптимальное значение для него?
И заодно для background_schedule_pool_size: как для него выбрать оптимальное значение? Полагаю в 2-4 раза больше, чем для background_fetches?
это странно -- качать 512 партов одновременно, много мелких инсертов и большая летенси? Я не представляю зачем надо больше 32. Одно время в КХ было background_fetches_pool_size=3 background_schedule_pool_size типа того, он кстати 128 сейчас.
2 причины: 1. Последствие system restore replica спустя несколько дней (раньше не могли по причине ограничения аплинка ДЦ) 2. Активный догон вставок после их остановки Полагаю, что сроляло олновременно и множество мелких вставок и множество attach part Поэтому и хотел уточнить нет ли рекомендаций размеру пула тредов для fetch Конечно же мы уменьшим это значение обратно. Вопрос лишь в том до какого значения при том, что по-умолчанию - 8
множество attach part по идее если парты есть на остальных репликах... не должно к fetch приводить, если нет, тогда да, тогда много всего смотрите длинну system.replication_queue
Смотрели. Более 10к событий на одну таблицу. КХ было тяжко
ну attach part скачивает парт с реплики, потому что парт переименовывается в момент attach есть разница attach part и system restore replica
я думаю что background_fetches_pool_size ни на что не повлиял
Обсуждают сегодня