Каскадный эффект при частых повторных попытках

В статье разобран типичный антипаттерн: агрессивные повторы запроса при клиентском таймауте, когда предыдущие экземпляры запроса все еще работают на сервере и конкурируют за ресурсы.

Такой сценарий часто сочетается с ростом задержек и ответами OVERLOADED при перегрузке шардов; см. Ошибки «overloaded» и Перегруженные таблетки data shard.

Статья объясняет, почему «уменьшить таймаут и повторять запросы чаще» при перегрузке ухудшает ситуацию, а не улучшает её.

Каскадный эффект возникает, когда клиент начинает часто повторять запросы, у которых время выполнения превышает установленный таймаут.

Механизм возникновения

Время выполнения запроса превышает таймаут клиента. Клиент начинает повторять запросы, но оригинальные запросы продолжают выполняться на сервере. Каждый следующий повторный запрос выполняется дольше предыдущего, так как сервер обрабатывает больше запросов одновременно. В какой-то момент задержка запросов постоянно превышает таймаут клиента. Клиент продолжает повторять запросы, увеличивая нагрузку и ещё больше повышая задержку.

Особенности YDB

В акторной модели YDB отмена запросов, которые уже выполняются, имеет ограничения. Особенно это проявляется при клиентских таймаутах — когда клиент закрывает gRPC стрим до получения ответа, запрос может продолжать выполняться на сервере.

Восстановление нормальной работы

Шард может восстановить нормальную работу только при временном полном снятии нагрузки, перезапуске шарда или разделении шарда по нагрузке.

Рекомендации

• После таймаута на клиенте не запускайте тот же запрос в цикле с коротким интервалом: серверная работа может продолжаться, очередь растет, задержка и число таймаутов увеличиваются.

• После явной временной ошибки (в том числе OVERLOADED) действуйте по рекомендациям в Ошибки «overloaded» о повторах без разгона нагрузки. Убедитесь по метрикам или нагрузке, что система не в режиме устойчивой перегрузки.

• Для политик retry в SDK см. Обработка ошибок и Выполнение повторных попыток.