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

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

​

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

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

​

Агрегации

Для ресурсоемких агрегаций или сортировок пользователи могут использовать настройки max_bytes_before_external_group_by и max_bytes_before_external_sort соответственно. Первая из них подробно рассматривается здесь.

Иными словами, эти настройки позволяют выполнять агрегации с выгрузкой на диск при превышении порога памяти. Это неизбежно скажется на производительности запроса, но поможет избежать OOM. Вторая настройка помогает решать аналогичные проблемы при ресурсоемкой сортировке. Это может быть особенно важно в распределенных окружениях, где координирующий узел получает отсортированные ответы от дочерних сегментов. В этом случае координирующему серверу может потребоваться отсортировать набор данных, размер которого превышает доступный ему объем памяти. С помощью max_bytes_before_external_sort можно разрешить сортировке выгружаться на диск. Эта настройка также полезна в случаях, когда пользователь использует ORDER BY после GROUP BY с LIMIT, особенно если запрос распределенный.

​

JOIN

Для JOIN пользователи могут выбирать разные алгоритмы JOIN, что позволяет снизить требуемый объем памяти. По умолчанию используется hash join, который обеспечивает наиболее полную поддержку возможностей и часто показывает лучшую производительность. Этот алгоритм загружает правую таблицу JOIN в хеш-таблицу в памяти, по которой затем выполняется сопоставление строк из левой таблицы. Поэтому для минимизации использования памяти меньшую таблицу следует размещать справа. Однако у этого подхода по-прежнему есть ограничения в сценариях, где объем памяти становится узким местом. В таких случаях можно включить алгоритм partial_merge через настройку join_algorithm. Этот вариант алгоритма sort-merge сначала сортирует правую таблицу по блокам и создает для них индекс min-max. Затем он сортирует части левой таблицы по ключу JOIN и выполняет JOIN с правой таблицей. Индекс min-max используется для пропуска ненужных блоков правой таблицы. Этот вариант потребляет меньше памяти, но за счет снижения производительности. Развивая эту идею дальше, алгоритм full_sorting_merge позволяет выполнять JOIN, когда правая сторона очень велика, не помещается в память и lookup-операции невозможны, например в случае сложного подзапроса. В таком случае и правая, и левая стороны сортируются на диске, если они не помещаются в памяти, что позволяет выполнять JOIN для больших таблиц.

Начиная с версии 20.3, ClickHouse поддерживает значение auto для настройки join_algorithm. Оно указывает ClickHouse использовать адаптивный подход к JOIN: предпочтение отдается алгоритму hash join до тех пор, пока не будут превышены ограничения по памяти, после чего выполняется попытка использовать алгоритм partial_merge. Наконец, применительно к JOIN мы рекомендуем читателям учитывать поведение распределенных JOIN и способы минимизировать потребление памяти при их выполнении. Дополнительную информацию можно найти здесь.