> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Превышен лимит памяти при выполнении запроса

> Устранение ошибок превышения лимита памяти при выполнении запроса

export const Image = ({img, alt, size}) => {
  return <Frame>
      <img src={img} alt={alt} />
    </Frame>;
};

{frontMatter.description}

<div id="troubleshooting-out-of-memory-issues">
  ## Превышен лимит памяти при выполнении запроса
</div>

Новичку ClickHouse часто кажется почти магией: любой запрос выполняется очень быстро,
даже на самых больших датасетах и в самых сложных сценариях. Однако
в реальных условиях эксплуатации неизбежно проверяются на прочность даже возможности ClickHouse. Запросы, превышающие лимит памяти,
могут возникать по ряду причин. Чаще всего это большие JOIN или
агрегации по полям с высокой мощностью. Если производительность критически важна и такие
запросы действительно нужны, мы часто рекомендуем пользователям просто масштабировать ресурсы — это
ClickHouse Cloud делает автоматически и без лишних усилий, чтобы ваши запросы
оставались отзывчивыми. Однако мы понимаем, что в самоуправляемых сценариях
это не всегда просто, и к тому же максимальная производительность может быть не нужна.
В этом случае у пользователей есть несколько вариантов.

<div id="aggregations">
  ### Агрегации
</div>

Для ресурсоемких агрегаций или сортировок пользователи могут использовать настройки
[`max_bytes_before_external_group_by`](/ru/reference/settings/session-settings#max_bytes_before_external_group_by)
и [`max_bytes_before_external_sort`](/ru/reference/settings/session-settings#max_bytes_ratio_before_external_sort) соответственно.
Первая из них подробно рассматривается [здесь](/ru/reference/statements/select/group-by#group-by-in-external-memory).

Иными словами, эти настройки позволяют выполнять агрегации с выгрузкой на диск при
превышении порога памяти. Это неизбежно скажется на производительности запроса, но
поможет избежать OOM. Вторая настройка помогает решать аналогичные
проблемы при ресурсоемкой сортировке. Это может быть особенно важно в
распределенных окружениях, где координирующий узел получает отсортированные ответы
от дочерних сегментов. В этом случае координирующему серверу может потребоваться отсортировать
набор данных, размер которого превышает доступный ему объем памяти. С помощью [`max_bytes_before_external_sort`](/ru/reference/settings/session-settings#max_bytes_ratio_before_external_sort)
можно разрешить сортировке выгружаться на диск. Эта настройка также полезна в
случаях, когда пользователь использует `ORDER BY` после `GROUP BY` с `LIMIT`,
особенно если запрос распределенный.

<div id="joins">
  ### JOIN
</div>

Для JOIN пользователи могут выбирать разные алгоритмы `JOIN`, что позволяет
снизить требуемый объем памяти. По умолчанию используется hash join, который
обеспечивает наиболее полную поддержку возможностей и часто показывает лучшую производительность.
Этот алгоритм загружает правую таблицу `JOIN` в хеш-таблицу в памяти, по которой
затем выполняется сопоставление строк из левой таблицы. Поэтому для минимизации
использования памяти меньшую таблицу следует размещать справа. Однако у этого подхода
по-прежнему есть ограничения в сценариях, где объем памяти становится узким местом. В таких случаях
можно включить алгоритм `partial_merge` через настройку
[`join_algorithm`](/ru/reference/settings/session-settings#join_algorithm).
Этот вариант [алгоритма sort-merge](https://en.wikipedia.org/wiki/Sort-merge_join)
сначала сортирует правую таблицу по блокам и создает для них индекс min-max.
Затем он сортирует части левой таблицы по ключу JOIN и выполняет JOIN с
правой таблицей. Индекс min-max используется для пропуска ненужных блоков
правой таблицы. Этот вариант потребляет меньше памяти, но за счет снижения производительности.
Развивая эту идею дальше, алгоритм `full_sorting_merge` позволяет выполнять `JOIN`,
когда правая сторона очень велика, не помещается в память и lookup-операции невозможны,
например в случае сложного подзапроса. В таком случае и правая, и левая стороны
сортируются на диске, если они не помещаются в памяти, что позволяет выполнять JOIN
для больших таблиц.

<Image img="https://mintcdn.com/private-7c7dfe99-mintlify-fbfa8bee/ql4_TXk6qnx8EBQC/images/knowledgebase/memory-limit-exceeded-for-query.png?fit=max&auto=format&n=ql4_TXk6qnx8EBQC&q=85&s=1201b653aa673e8a782ddb902d39457f" size="md" alt="Алгоритмы JOIN" width="1024" height="768" data-path="images/knowledgebase/memory-limit-exceeded-for-query.png" />

Начиная с версии 20.3, ClickHouse поддерживает значение auto для настройки `join_algorithm`.
Оно указывает ClickHouse использовать адаптивный подход к JOIN: предпочтение
отдается алгоритму hash join до тех пор, пока не будут превышены ограничения
по памяти, после чего выполняется попытка использовать алгоритм partial\_merge.
Наконец, применительно к JOIN мы рекомендуем читателям учитывать поведение
распределенных JOIN и способы минимизировать потребление памяти при их выполнении.
Дополнительную информацию можно найти [здесь](/ru/reference/statements/in#distributed-subqueries).