Ошибки «overloaded»

В статье описано, при каких условиях запрос к YDB завершается ошибкой OVERLOADED, и что делать дальше.

Ниже перечислены типичные причины. Проверить их можно по инструкции в разделе Диагностика. Как повторять запросы, не разгоняя нагрузку, описано в конце статьи.

YDB возвращает ошибки OVERLOADED в следующих случаях:

• Из-за перегруженной партиции таблицы:

  1. На партиции превышен лимит числа одновременно обрабатываемых транзакций. Для data-транзакций это обычно проявляется как превышение порога в 15000 in-flight запросов на шард.

  2. Шард отстаёт по завершению уже принятых транзакций. Это происходит, когда у него накапливается хвост незавершённых операций и новые запросы временно отклоняются, чтобы не увеличивать отставание.

  3. Локальная база данных шарда перегружена: например, слишком много транзакций уже находится в обработке, in-memory данные слишком выросли или compaction не успевает за нагрузкой. В этом случае шард может начать отклонять часть новых запросов, даже если лимит по числу in-flight транзакций на уровне data shard ещё не достигнут.

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

• Из-за того, что партиция таблицы временно находится не в рабочем состоянии:

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

• Из-за перегруженного CDC:

  1. Превышен лимит размера выходной очереди CDC: 10000 элементов или 125 МБ.

• Из-за перегруженного узла:

  1. Количество открытых сессий с узлом YDB достигло лимита в 1000. Это может указывать на проблему в логике приложения.

Диагностика

1. Откройте панель мониторинга Grafana DB overview.

2. В разделе API details проверьте, есть ли всплески частоты запросов со статусом OVERLOADED на диаграмме Soft errors (retriable).

   

3. Чтобы проверить, не связаны ли всплески ошибок OVERLOADED с превышением лимита в 15000 запросов на партицию таблицы:

   • Через UI:

     1. Во Встроенном UI перейдите на вкладку Databases и нажмите на базу данных.

     2. На вкладке Navigation убедитесь, что требуемая база данных выбрана.

     3. Откройте вкладку Diagnostics.

     4. Откройте вкладку Top shards.

     5. На вкладках Immediate и Historical отсортируйте таблетки по столбцу InFlightTxCount и проверьте, не превышают ли максимальные значения лимит в 15000 запросов.

   • Через систему мониторинга:

     1. Найдите дашборд, отображающий метрики базы данных.

     2. Выберите category = app, type = DataShard, sensor = SUM(DataShard/ImmediateTxInFly).

     3. Проверьте, не растут ли его значения до величин, близких к 15000 или превышающих этот порог.

4. Чтобы проверить, не связаны ли всплески ошибок OVERLOADED с отставанием принятых транзакций:

   1. Найдите дашборд, отображающий метрики базы данных.

   2. Выберите category = app, type = DataShard, sensor = MAX(DataShard/TxCompleteLag).

   3. Проверьте, не растут ли его значения до 300 секунд или превышающих этот порог.

5. Чтобы проверить, не связаны ли всплески ошибок OVERLOADED с перегрузкой локальной базы данных шарда:

   1. Найдите дашборд, отображающий метрики базы данных.

   2. Выберите category = executor, type = DataShard, sensor = MAX(RejectProbability).

   3. Проверьте, не появляются ли у него значения выше нуля. Рост этого сенсора означает, что local DB начала вероятностно отклонять часть новых запросов из-за перегрузки.

6. Чтобы проверить, не связаны ли всплески ошибок OVERLOADED со слишком частыми слияниями и разделениями таблеток, см. Избыточные разделения и слияния партиций таблиц.

7. Чтобы проверить, не связаны ли всплески ошибок OVERLOADED с превышением лимита в 1000 открытых сессий, см. диаграмму Session count by host на панели мониторинга Grafana DB status.

8. См. статью Перегруженные таблетки data shard.

Встроенные механизмы обработки ошибок

Если запрос к YDB возвращает ошибку OVERLOADED, повторите операцию с экспоненциальной задержкой (пауза между повторами всё длиннее — обычно в несколько раз) и джиттером (случайным разбросом интервала), чтобы не создавать синхронные волны повторных запросов. YDB SDK реализует политики повторов для временных ошибок; обзор и настройка — в разделе Обработка ошибок, примеры — в Выполнение повторных попыток.

Не переносите на OVERLOADED ту же тактику, что и при таймауте на клиенте: при обрыве по таймауту запрос на сервере может еще выполняться, а частые повторы усугубляют очередь. Подробнее — в статье Каскадный эффект при частых повторных попытках.