Comments 6
Снизу — overload controller. Этот блок собирает feedback в виде размеров
очередей тредпулов и отправляет сигнал контроля для RPC: принимать
или отклонять запросы.
Пока очереди не заполнились до критической отметки, но статистика уже распологает, возможно, контролеру есть смысл ещё и замедлять запросы? Вставлять какие-то примлемые паузы между реквестами, чтоб дать больше времени очередям для освободиться.
Мы о таком не думали: в первую очередь хотелось избежать перегрузки тредпулов, из-за которой и правда очень больно. Плавность деградации, второй шаг, но что-то мне подсказывает, что в сценарии, когда есть много клиентов, посылающих запросы, искуственно замедлять несильно поможет: рейт входящих запросов от такого замедления меньше не станет, просто замедленные запросы будут дольше стоять в очереди и мы просто уменьшим пропускную способность, толком ничего хорошего от этого не получив. Но возможно я просто не понял предлагаемую иедю.
В любом случае, спасибо за комментарий!
Попробую придумать какой-нибудь пример. Есть клиенты (конечные UI, узлы в цепочке вычислений, сервисы и пр.). Каждый клиент делает запрос на большой объём данных, а критично ему сразу получить, скажем, первые 100 строк (или там, пачек). Обращение за каждой очередной порцией данных помещается в очередь, откуда их должен достать процесс из тредпула и обработать, как вариант:
1) Продолжить выполнение SQL
2) Достать уже посчитанный ответ из кеша в ОЗУ
3) Достать ответ из временного хранилища данных сессии на диске
... и вернуть очередную порцию клиенту.
Кроме таких запросов на порции данных, в очередь попадают более критичные вычислительные задачи. Если мы немного диградируем, возможно даже на уровне сокетов, ту часть системы, которая принимает реквесты на получение 101-й и далее некритичных порций данных, разве мы не увеличим таким образом эффективность тредпула в части обработки более полезных задач? Но даже не об этом. Допустим, у нас нет других вычислений, остались только запросы на порции данных и их очень много. Если часть из них они сразу забьёт очередь, тогда остальным придётся сделать отказ. Клиент, который ещё возится с первой сотней строк, очень расстроиться, что ему прилетел отлуп. Если же растянуть поступление в очередь во времени, превратить в ленивцев на стороне СУБД, то у процессов из тредпула появляется больше шансов успеть справиться с нагрузкой без переполнения очередей и соответственно необходимости отказа. Да, может наступить момент, когда уже и это не поможет, но... это так, на подумать.
Если есть явное разделение приоритетов, лучше использовать fair share приоретизацию (в исходном посте рассказывается о нашей имплементации fair share тредпула) - на практике так получается поведение, которое существенно более соответствует пользовательскому ожиданию.
Почитал про fair share здесь, интересно, спасибо за наводку. В среднем наверно да, это более соответствует пользовательскому ожиданию. Если пользователь не бухгалтер, которому надо срочно посчитать и закрыть день, а маректолог со своими анализами кликов подождёт. Отдельному пользователю можно подкрутить ресурс? Чтоб не орала на весь офис: срочно выйдете все из базы! А то останетесь без зарплаты.
Улучшаем динамические таблицы YTsaurus с помощью алгоритмов