---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ydb.tech/docs/en/troubleshooting/performance/schemas/overloaded-shards.md?version=main
  - https://ydb.tech/docs/ru/troubleshooting/performance/schemas/overloaded-shards.md?version=main
sourcePath: ru/core/troubleshooting/performance/schemas/overloaded-shards.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt

# Перегруженные таблетки data shard

Таблетки [data shard](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#data-shard), обслуживающие [строковые таблицы](https://ydb.tech/docs/ru/concepts/datamodel/table.md?version=main#row-oriented-tables), могут быть перегружены по следующим причинам:

* Таблица создана без указания параметра [AUTO_PARTITIONING_BY_LOAD](https://ydb.tech/docs/ru/concepts/datamodel/table.md?version=main#AUTO_PARTITIONING_BY_LOAD).

    В этом случае YDB не разбивает перегруженные таблетки data shard.

    Таблетки data shard являются однопоточными и обрабатывают запросы последовательно. Каждая таблетка data shard может принимать на выполнение до 10000 операций. Принятые запросы ожидают своей очереди на выполнение. Таким образом, чем длиннее очередь, тем выше задержка.

    Если таблетка data shard уже содержит 10000 операций в своей очереди, новые запросы будут возвращать ошибку «overloaded». Повторите такие запросы, используя экспоненциально растущий перерыв, см. [Ошибки «overloaded»](https://ydb.tech/docs/ru/troubleshooting/performance/queries/overloaded-errors.md?version=main).

* Таблица создана с параметром [AUTO_PARTITIONING_MAX_PARTITIONS_COUNT](https://ydb.tech/docs/ru/concepts/datamodel/table.md?version=main#AUTO_PARTITIONING_MAX_PARTITIONS_COUNT) и уже достигла лимита на число партиций.

* Неэффективный [первичный ключ](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#primary-key), который вызывает дисбаланс в распределении запросов по таблеткам data shard. Типичным примером является использование монотонно увеличивающегося первичного ключа при загрузке данных, что может привести к перегрузке «последней» партиции. Например, это может произойти с автоматически увеличивающимся первичным ключом, использующим тип данных [Serial](https://ydb.tech/docs/ru/yql/reference/types/serial.md?version=main).

## Диагностика

<!-- The include is added to allow partial overrides in overlays  -->
<!-- source: ru/troubleshooting/performance/schemas/_includes/overloaded-shards-diagnostics.md -->
1. Используйте Встроенный UI или Grafana, чтобы проверить, не перегружены ли узлы YDB:

    - На панели мониторинга Grafana **[DB overview](https://ydb.tech/docs/ru/reference/observability/metrics/grafana-dashboards.md?version=main#dboverview)** проанализируйте диаграмму **Overloaded shard count**.

        ![](_assets/overloaded-shards-dashboard.png)

        Диаграмма отображает перегруженные таблетки data shard в кластере YDB, но она не показывает таблицы, в которых есть перегруженные таблетки.

        {% note tip %}

        Настройте уведомления в Grafana о перегрузках таблеток data shard.

        {% endnote %}

    - Во [Встроенном UI](https://ydb.tech/docs/ru/reference/embedded-ui/index.md?version=main):

        1. Перейдите на вкладку **Databases** и выберите базу данных.

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

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

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

        1. На вкладках **Immediate** и **Historical** отсортируйте таблетки по колонке **CPUCores** и проанализируйте информацию.

        ![](_assets/partitions-by-cpu.png)

        Кроме того, информация о перегруженных таблетках представлена в виде системной таблицы. Дополнительные сведения см. в разделе [История перегруженных партиций](https://ydb.tech/docs/ru/dev/system-views.md?version=main#top-overload-partitions).

1. Чтобы точно определить проблему со схемой, используйте [Встроенный UI](https://ydb.tech/docs/ru/reference/embedded-ui/index.md?version=main) или [YDB CLI](https://ydb.tech/docs/ru/reference/ydb-cli/index.md?version=main):

    - Во [Встроенном UI](https://ydb.tech/docs/ru/reference/embedded-ui/index.md?version=main):

        1. На вкладке **Databases** нажмите на базу данных.

        1. На вкладке **Navigation** выберите требуемую базу данных.

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

        1. На вкладке **Describe** перейдите на страницу `root > PathDescription > Table > PartitionConfig > PartitioningPolicy`.

            ![Describe](_assets/describe.png)

        1. Проанализируйте значения **PartitioningPolicy**:

            - `SizeToSplit`
            - `SplitByLoadSettings`
            - `MaxPartitionsCount`

            Если в таблице не отображаются вышеперечисленные параметры, см. [Рекомендации по конфигурации таблиц](https://ydb.tech/docs/ru/troubleshooting/performance/schemas/overloaded-shards.md?version=main#table-config).

        {% note info %}

        Эта информация также отображается на вкладке **Diagnostics > Info**.

        {% endnote %}


    - В [YDB CLI](https://ydb.tech/docs/ru/reference/ydb-cli/index.md?version=main):

        1. Чтобы получить информацию о проблемной таблице, выполните следующую команду:

            ```bash
            ydb scheme describe <table_name>
            ```

        2. В выводе команды проанализируйте **Auto partitioning settings**:

            - `Partitioning by size`
            - `Partitioning by load`
            - `Max partitions count`

            Если в таблице не указаны эти параметры, см. [Рекомендации по конфигурации таблиц](https://ydb.tech/docs/ru/troubleshooting/performance/schemas/overloaded-shards.md?version=main#table-config).

1. Проанализируйте, монотонно ли увеличиваются значения первичного ключа:

    - Проверьте тип данных столбца первичного ключа. Типы данных `Serial` используются для автоматического увеличения значений.

    - Проверьте логику приложения.

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

    Если значения первичного ключа действительно увеличиваются монотонно, см. [Рекомендации для несбалансированного первичного ключа](https://ydb.tech/docs/ru/troubleshooting/performance/schemas/overloaded-shards.md?version=main#pk-recommendations).
<!-- endsource: ru/troubleshooting/performance/schemas/_includes/overloaded-shards-diagnostics.md -->

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

### Для конфигурации таблиц {#table-config}

Рассмотрите следующие решения для устранения перегрузки таблеток data shard:

* Если в проблемной таблице не включено партиционирование по нагрузке, включите его.

    {% note tip %}

    Партиционирование по нагрузке отключено, если на вкладке **Diagnostics > Info** во **Встроенном UI** или в выводе команды `ydb scheme describe` отображается строка `Partitioning by load: false`.

    {% endnote %}

* Если количество партиций в таблице достигло максимального лимита, увеличьте максимальный лимит партиций таблицы.

    {% note tip %}

    Чтобы определить количество партиций в таблице, см. значение `PartCount` на вкладке **Diagnostics > Info** во **Встроенном UI**.

    {% endnote %}

Обе операции можно выполнить с помощью запроса [`ALTER TABLE ... SET`](https://ydb.tech/docs/ru/yql/reference/syntax/alter_table/set.md?version=main).

### Для несбалансированного первичного ключа {#pk-recommendations}

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

{% note info %}

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

{% endnote %}