--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ydb.tech/docs/en/troubleshooting/performance/queries/overloaded-errors.md?version=main - https://ydb.tech/docs/ru/troubleshooting/performance/queries/overloaded-errors.md?version=main sourcePath: ru/core/troubleshooting/performance/queries/overloaded-errors.md --- > **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt # Ошибки «overloaded» В статье описано, при каких условиях запрос к YDB завершается ошибкой `OVERLOADED`, и что делать дальше. Ниже перечислены типичные причины. Проверить их можно по инструкции в разделе [Диагностика](#diagnostics). Как повторять запросы, не разгоняя нагрузку, описано в конце статьи. YDB возвращает ошибки `OVERLOADED` в следующих случаях: * Из-за перегруженной партиции таблицы: 1. На партиции превышен лимит числа одновременно обрабатываемых транзакций. Для data-транзакций это обычно проявляется как превышение порога в 15000 in-flight запросов на шард. 2. Шард отстаёт по завершению уже принятых транзакций. Это происходит, когда у него накапливается хвост незавершённых операций и новые запросы временно отклоняются, чтобы не увеличивать отставание. 3. Локальная база данных шарда перегружена: например, слишком много транзакций уже находится в обработке, in-memory данные слишком выросли или compaction не успевает за нагрузкой. В этом случае шард может начать отклонять часть новых запросов, даже если лимит по числу in-flight транзакций на уровне data shard ещё не достигнут. Как правило, эти причины возникают из-за одних и тех же первопричин: неравномерного распределения нагрузки, слишком высокой частоты записи или недостатка ресурсов. * Из-за того, что партиция таблицы временно находится не в рабочем состоянии: 1. Партиция может разделяться или объединяться, перезапускаться, ещё не завершить служебный переход в рабочее состояние или находиться в другом промежуточном состоянии, в котором новые запросы временно не принимаются. * Из-за перегруженного [CDC](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#cdc): 1. Превышен лимит размера выходной очереди CDC: 10000 элементов или 125 МБ. * Из-за перегруженного узла: 1. Количество открытых сессий с узлом YDB достигло лимита в 1000. Это может указывать на проблему в логике приложения. ## Диагностика {#diagnostics} 1. Откройте панель мониторинга Grafana **[DB overview](https://ydb.tech/docs/ru/reference/observability/metrics/grafana-dashboards.md?version=main#dboverview)**. 1. В разделе **API details** проверьте, есть ли всплески частоты запросов со статусом `OVERLOADED` на диаграмме **Soft errors (retriable)**. ![](_assets/soft-errors.png) 1. Чтобы проверить, не связаны ли всплески ошибок `OVERLOADED` с превышением лимита в 15000 запросов на партицию таблицы: * Через UI: 1. Во [Встроенном UI](https://ydb.tech/docs/ru/reference/embedded-ui/index.md?version=main) перейдите на вкладку **Databases** и нажмите на базу данных. 1. На вкладке **Navigation** убедитесь, что требуемая база данных выбрана. 1. Откройте вкладку **Diagnostics**. 1. Откройте вкладку **Top shards**. 1. На вкладках **Immediate** и **Historical** отсортируйте таблетки по столбцу **InFlightTxCount** и проверьте, не превышают ли максимальные значения лимит в 15000 запросов. * Через систему мониторинга: 1. Найдите дашборд, отображающий метрики базы данных. 1. Выберите `category = app`, `type = DataShard`, `sensor = SUM(DataShard/ImmediateTxInFly)`. 1. Проверьте, не растут ли его значения до величин, близких к 15000 или превышающих этот порог. 1. Чтобы проверить, не связаны ли всплески ошибок `OVERLOADED` с отставанием принятых транзакций: 1. Найдите дашборд, отображающий метрики базы данных. 1. Выберите `category = app`, `type = DataShard`, `sensor = MAX(DataShard/TxCompleteLag)`. 1. Проверьте, не растут ли его значения до 300 секунд или превышающих этот порог. 1. Чтобы проверить, не связаны ли всплески ошибок `OVERLOADED` с перегрузкой локальной базы данных шарда: 1. Найдите дашборд, отображающий метрики базы данных. 1. Выберите `category = executor`, `type = DataShard`, `sensor = MAX(RejectProbability)`. 1. Проверьте, не появляются ли у него значения выше нуля. Рост этого сенсора означает, что local DB начала вероятностно отклонять часть новых запросов из-за перегрузки. 1. Чтобы проверить, не связаны ли всплески ошибок `OVERLOADED` со слишком частыми слияниями и разделениями таблеток, см. [Избыточные разделения и слияния партиций таблиц](https://ydb.tech/docs/ru/troubleshooting/performance/schemas/splits-merges.md?version=main). 1. Чтобы проверить, не связаны ли всплески ошибок `OVERLOADED` с превышением лимита в 1000 открытых сессий, см. диаграмму **Session count by host** на панели мониторинга Grafana **[DB status](https://ydb.tech/docs/ru/reference/observability/metrics/grafana-dashboards.md?version=main#dbstatus)**. 1. См. статью [Перегруженные таблетки data shard](https://ydb.tech/docs/ru/troubleshooting/performance/schemas/overloaded-shards.md?version=main). ## Встроенные механизмы обработки ошибок {#builtin-error-handling} Если запрос к YDB возвращает ошибку `OVERLOADED`, повторите операцию с экспоненциальной задержкой (пауза между повторами всё длиннее — обычно в несколько раз) и джиттером (случайным разбросом интервала), чтобы не создавать синхронные волны повторных запросов. YDB SDK реализует политики повторов для временных ошибок; обзор и настройка — в разделе [Обработка ошибок](https://ydb.tech/docs/ru/reference/ydb-sdk/error_handling.md?version=main), примеры — в [Выполнение повторных попыток](https://ydb.tech/docs/ru/recipes/ydb-sdk/retry.md?version=main). Не переносите на `OVERLOADED` ту же тактику, что и при **таймауте на клиенте**: при обрыве по таймауту запрос на сервере может еще выполняться, а частые повторы усугубляют очередь. Подробнее — в статье [Каскадный эффект при частых повторных попытках](https://ydb.tech/docs/ru/troubleshooting/performance/queries/retry-cascade.md?version=main).