Управление памятью кеша внешних метаданных
Начиная с Doris 4.1.4, управляемые кеши внешних метаданных можно ограничивать по оценочному объёму удерживаемой памяти. Это предотвращает неограниченный рост потребления кучи FE метаданными большой таблицы, одного Catalog или нескольких Catalog.
Используйте эту возможность, если:
- Таблицы Hive содержат достаточно много партиций или файлов, чтобы структуры партиций и списков файлов занимали большой объём памяти.
- Метаданные таблиц Iceberg, проекции партиций или манифесты имеют большой размер.
- Проекции партиций Paimon имеют большой размер.
- Один FE обслуживает несколько Catalog, и нужно не допустить, чтобы один Catalog занимал основную часть памяти кешей метаданных.
Набор управляемых элементов кеша и их имена различаются в Doris 4.1.x/4.2.x и текущей версии. Для кластера 4.1.x или 4.2.x переключитесь на версию 4.x этой страницы.
Эти ограничения распространяются только на управляемые кеши метаданных, перечисленные в этом документе. Они не задают жёсткий предел использования кучи FE. Временная память при загрузке, объекты метаданных, на которые ещё ссылаются выполняющиеся запросы, кеши SDK коннекторов и общая инфраструктура времени выполнения, например клиенты Catalog и пулы потоков, не учитываются в квоте.
Быстрый старт
Предварительные требования:
- Существующий внешний Catalog, например Hive, Iceberg или Paimon.
- Права на изменение конфигурации FE и целевого Catalog.
- Doris 4.1.4 или более поздней версии на каждом FE.
1. Настройте общее ограничение для FE
Задайте следующий параметр в fe.conf на каждом FE:
external_meta_cache_max_weight = 10%
После этого все управляемые кеши внешних метаданных на данном FE смогут суммарно использовать не более 10% максимального размера кучи JVM. Перезапустите FE после изменения этого параметра.
Можно также задать фиксированный размер:
external_meta_cache_max_weight = 8GB
2. Ограничьте один Catalog
Следующий пример ограничивает суммарный объём управляемых кешей метаданных в hive_ctl до 4 ГБ:
ALTER CATALOG hive_ctl SET PROPERTIES (
"meta.cache.max-weight" = "4GB"
);
После изменения Doris очищает инициализированные кеши этого Catalog и при следующем обращении создаёт их заново с новой конфигурацией.
meta.cache.max-weight действует, даже если общее ограничение для FE не настроено. В этом случае ограничивается только данный Catalog, а суммарное потребление памяти всеми Catalog на FE не ограничивается.
3. Ограничьте отдельные элементы кеша
Следующий пример задаёт ограничение для Catalog и отдельных элементов кеша Hive:
ALTER CATALOG hive_ctl SET PROPERTIES (
"meta.cache.max-weight" = "4GB",
"meta.cache.hive.file.max-weight" = "2GB",
"meta.cache.hive.partition_view.max-weight" = "1GB"
);
Для элементов file и partition_view установлены ограничения 2 ГБ и 1 ГБ соответственно. Их суммарное потребление не может превышать ограничение Catalog в 4 ГБ, а на сам Catalog по-прежнему распространяется общее ограничение FE.
Иерархия квот
Доступны три уровня ограничений памяти:
| Уровень | Где задаётся | Параметр | Формат | Значение по умолчанию | Область действия |
|---|---|---|---|---|---|
| FE | fe.conf | external_meta_cache_max_weight | Фиксированный размер или процент от максимального размера кучи JVM | 0; общая квота FE отсутствует | Все управляемые кеши внешних метаданных на текущем FE |
| Catalog | Свойство Catalog | meta.cache.max-weight | Фиксированный размер; должен быть положительным | Не задано; квота Catalog отсутствует | Все управляемые элементы в текущем Catalog |
| Элемент кеша | Свойство Catalog | meta.cache.<engine>.<entry>.max-weight | Фиксированный размер; должен быть положительным | Не задано; действуют только ограничения вышестоящих уровней | Один элемент кеша или группа кешей, относящихся к этому элементу |
Эффективное ограничение элемента равно минимальному из всех настроенных ограничений, которые на него распространяются.
| Ограничение FE | Ограничение Catalog | Ограничение элемента | Поведение |
|---|---|---|---|
| Не задано | Не задано | Не задано | Учёт памяти отключён; действуют только политики количества объектов и TTL |
| Задано | Не задано | Не задано | Все управляемые элементы на FE совместно используют квоту FE |
| Не задано | Задано | Не задано | Все управляемые элементы в Catalog совместно используют квоту Catalog |
| Не задано | Не задано | Задано | Ограничен только этот элемент; общего ограничения FE или Catalog нет |
| Задано | Задано | Задано | Действуют все три уровня; применяется самое строгое ограничение |
Правила проверки:
- Ограничение элемента не может превышать ограничение того же Catalog. Операция
CREATE CATALOGилиALTER CATALOGзавершается ошибкойmeta.cache.<engine>.<entry>.max-weight can not exceed meta.cache.max-weight. - Каждый FE вычисляет
external_meta_cache_max_weightотносительно собственной кучи JVM. На FE с разными размерами кучи один и тот же процент даёт разные ограничения в байтах.
Формат значений
Для фиксированных размеров поддерживаются следующие двоичные единицы без учёта регистра:
B, KB, MB, GB, TB, PB
Примеры значений: 512MB и 4GB. Фиксированный размер должен задаваться целым неотрицательным числом.
Только external_meta_cache_max_weight принимает процентное значение, например 10% или 12.5%. Процент вычисляется от максимального размера кучи JVM каждого FE.
Ноль имеет разное значение на разных уровнях:
| Параметр | Значение 0 |
|---|---|
external_meta_cache_max_weight | Отключает общую квоту FE, не отключая кеши |
meta.cache.max-weight | Недопустимо; ограничение Catalog должно быть положительным |
meta.cache.<engine>.<entry>.max-weight | Недопустимо; ограничение элемента должно быть положительным |
0% недопустимо. Чтобы отключить общую квоту FE, используйте обычное значение 0. Чтобы отключить элемент кеша, задайте для его свойства enable значение false или для ttl-second значение 0; использовать max-weight для этой цели нельзя.
Управляемые элементы кеша
Каждый управляемый кеш метаданных имеет механизм оценки размера. Как только на элемент начинает действовать ограничение FE, Catalog или самого элемента, для него включается управление по объёму памяти. Отдельной группы элементов, ограничиваемых только по количеству объектов, нет: если ни одно ограничение памяти не действует, каждый элемент использует только свои настройки enable, ttl-second и capacity.
Элементы кеша настраиваются с помощью meta.cache.<engine>.<entry>.{enable,ttl-second,capacity,max-weight}. В таблицах ниже перечислены токены <engine> и <entry>, значение ENTRY_NAME, отображаемое в information_schema.catalog_meta_cache_statistics, и значения по умолчанию. Только перечисленные токены <entry> поддерживают max-weight; любой другой ключ max-weight для известного движка приводит к ошибке CREATE CATALOG или ALTER CATALOG с сообщением Unknown metadata cache weight property.
Схема таблиц для каждого внешнего Catalog
<engine> | <entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|---|
default | schema | schema | Схема столбцов внешних таблиц для всех типов Catalog | true / external_cache_expire_time_seconds_after_access (86400 с) / max_external_schema_cache_num (10000) |
Устаревшее свойство Catalog schema.cache.ttl-second соответствует meta.cache.default.schema.ttl-second.
Hive
Движок hive используется в Catalog типа Hive и в кешах Hive Metastore для Catalog типа Hudi.
<entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|
table | hive-table | Объекты таблиц из Hive Metastore | true / 86400 с / 10000 |
partition_names | hive-partition-names | Списки имён партиций таблицы | true / 86400 с / 10000 |
partition | hive-partition | Объекты партиций, включая расположение и формат входных данных | true / 86400 с / 100000 |
column_stats | hive-column-stats | Статистика столбцов из Hive Metastore | true / 86400 с / 10000 |
file | hive-file | Списки файлов таблицы или партиции | true / 86400 с / 10000 |
partition_view | hive-partition-view | Структуры для отсечения партиций, построенные на основе имён партиций | true / 86400 с / 1000 |
Устаревшие свойства соответствуют унифицированным ключам следующим образом: schema.cache.ttl-second соответствует meta.cache.hive.table.ttl-second, partition.cache.ttl-second соответствует meta.cache.hive.partition_names.ttl-second, а file.meta.cache.ttl-second соответствует meta.cache.hive.file.ttl-second.
Catalog типа Hive Metastore, содержащий таблицы Iceberg, также использует перечисленные ниже элементы iceberg.
Iceberg
<entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|
table | iceberg-table | Загруженные метаданные таблицы Iceberg | true / meta.cache.iceberg.table.ttl-second (86400 с) / 1000 |
partition | iceberg-partition | Исходные данные партиций снимка таблицы | true / как у table / 1000 |
manifest | iceberg-manifest | Разобранное содержимое манифестов; используется при планировании сканирования только тогда, когда meta.cache.iceberg.manifest.enable имеет значение true (по умолчанию false) | true / без срока действия / 100000 |
partition_view | iceberg.mvcc-partition-view, iceberg.list-partitions-view | Две производные проекции партиций с общим бюджетом | true / 86400 с / 1000 |
Следующие кеши Iceberg не имеют токена <entry>. На них распространяются ограничения Catalog и FE, а их TTL определяется параметром meta.cache.iceberg.table.ttl-second:
ENTRY_NAME | Кешируемые данные |
|---|---|
iceberg-latest-snapshot | Идентификатор последнего снимка таблицы |
iceberg-format | Определённый формат файлов таблицы |
iceberg-comment | Комментарии к таблицам; создаётся только для REST Catalog с выдаваемыми учётными данными |
iceberg-equality-delete-field-ids | Идентификаторы полей удаления по равенству в снимке |
Когда iceberg.rest.session имеет значение user, кеши table, partition, partition_view, latest-snapshot и format не создаются, поскольку общий кеш позволил бы обойти авторизацию отдельных пользователей. REST Catalog с выдаваемыми учётными данными также не создаёт кеш table.
Paimon
<entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|
partition_view | paimon.partition-view | Проекции партиций, построенные на основе снимка таблицы | true / 86400 с / 1000 |
Следующие кеши Paimon не имеют токена <entry> и подчиняются только ограничениям Catalog и FE:
ENTRY_NAME | Кешируемые данные | TTL |
|---|---|---|
paimon-schema-at | Схема таблицы в определённом снимке | Без срока действия; лимит количества объектов 10000 |
paimon-latest-snapshot | Идентификатор последнего снимка таблицы | meta.cache.paimon.table.ttl-second (86400 с); лимит количества объектов 1000 |
meta.cache.paimon.table.ttl-second также управляет TTL кеша схем таблиц Paimon.
Hudi
Catalog типа Hudi отображает свои кеши под движком hudi, но это кеши Hive Metastore, которые настраиваются ключами meta.cache.hive.<entry>.*: table, partition_names, partition и column_stats.
MaxCompute
<engine> | <entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|---|
max_compute | partition | max-compute-partition | Списки партиций таблицы | true / 600 с / 10000 |
ADBC
<engine> | <entry> | ENTRY_NAME | Кешируемые данные | По умолчанию: включение / TTL / число объектов |
|---|---|---|---|---|
adbc | metadata | adbc-namespaces, adbc-table-names, adbc-table-schema | Пространства имён, имена таблиц и схемы таблиц; три кеша используют общий бюджет | true / 600 с / 1000 |
Doris
Catalog типа Doris отображает элементы schema и backends под движком doris; они настраиваются ключами meta.cache.doris.<entry>.*.
Примеры
Использование только ограничений Catalog
Если общее ограничение FE не задано, ограничьте каждый Catalog независимо:
ALTER CATALOG hive_prod SET PROPERTIES (
"meta.cache.max-weight" = "6GB"
);
ALTER CATALOG iceberg_ad_hoc SET PROPERTIES (
"meta.cache.max-weight" = "2GB"
);
Для этих Catalog установлены ограничения 6 ГБ и 2 ГБ соответственно, но общего ограничения на их суммарное потребление памяти на FE нет.
Ограничение списков файлов и структур партиций Hive
ALTER CATALOG hive_ctl SET PROPERTIES (
"meta.cache.max-weight" = "4GB",
"meta.cache.hive.file.max-weight" = "2GB",
"meta.cache.hive.partition_view.max-weight" = "1GB"
);
Списки файлов таблиц с большим количеством файлов и структуры для отсечения партиций таблиц с большим количеством партиций обычно занимают больше всего места среди элементов кеша Hive.
Ограничение метаданных Iceberg и включение кеша манифестов
ALTER CATALOG iceberg_ctl SET PROPERTIES (
"meta.cache.max-weight" = "4GB",
"meta.cache.iceberg.table.max-weight" = "1GB",
"meta.cache.iceberg.partition.max-weight" = "1GB",
"meta.cache.iceberg.manifest.enable" = "true",
"meta.cache.iceberg.manifest.max-weight" = "1GB"
);
Ограничение проекций партиций Paimon
ALTER CATALOG paimon_ctl SET PROPERTIES (
"meta.cache.max-weight" = "2GB",
"meta.cache.paimon.partition_view.max-weight" = "1GB"
);
Остальные кеши Paimon ограничены квотой Catalog в 2 ГБ.
Совместное использование ограничений памяти и политик TTL
Ограничения памяти можно использовать вместе с enable, ttl-second и capacity:
ALTER CATALOG hive_ctl SET PROPERTIES (
"meta.cache.hive.file.enable" = "true",
"meta.cache.hive.file.ttl-second" = "1800",
"meta.cache.hive.file.capacity" = "20000",
"meta.cache.hive.file.max-weight" = "2GB"
);
capacity по-прежнему ограничивает количество объектов, а max-weight добавляет ограничение памяти; вытеснение запускается при достижении любого из этих пределов. capacity=0 или ttl-second=0 по-прежнему отключает элемент.
Поведение при достижении ограничения
При отсутствии данных в кеше Doris:
- Загружает метаданные из внешнего источника.
- Оценивает объём удерживаемой памяти загруженного объекта и добавляет фиксированные накладные расходы на учёт в размере 512 байт.
- Атомарно проверяет квоты FE, Catalog и элемента.
- Если объект не удаётся принять в кеш, возвращает его текущему запросу без кеширования и запрашивает асинхронное освобождение редко используемых данных у других элементов. Сначала запрос получают элементы того же Catalog; при нехватке общей квоты FE затем привлекаются другие Catalog.
Отказ в приёме объекта в кеш не приводит к ошибке запроса. Объект не сохраняется, поэтому при последующих обращениях загружается снова, увеличивая задержку планирования запросов, пока асинхронное освобождение памяти не высвободит достаточную часть бюджета.
При попадании в кеш оценка не выполняется. Используются два вида механизмов оценки:
- Специализированные механизмы оценивают размер объектов Hive Metastore, списков файлов Hive, метаданных таблиц Iceberg, манифестов и производных проекций партиций Hive, Iceberg и Paimon.
- Универсальный механизм полностью обходит граф объектов остальных кешей с фиксированным лимитом обхода. Если лимит исчерпан или граф содержит классы, которые невозможно исследовать, оценка считается неполной.
При неполной оценке объект не принимается в кеш, чтобы избежать занижения его размера. Причины отказа записываются в LAST_WEIGHT_REJECT_REASON:
| Причина | Значение |
|---|---|
budget_exceeded | Квота FE, Catalog или элемента не позволяет разместить объект |
entry_too_large | Размер одного объекта превышает эффективное ограничение элемента |
incomplete_estimate:<detail> | Механизм оценки не смог надёжно определить размер объекта |
invalid_zero_estimate | Механизм оценки вернул ноль |
Квоты проверяются при приёме объекта в кеш, после его загрузки. Doris не резервирует место в куче перед обращением к внешнему источнику. Поэтому ошибка загрузки из удалённого источника или исключительно большой объект, исчерпавший кучу FE ещё до завершения создания, всё равно могут привести к ошибке текущего запроса. Эта возможность ограничивает память, удерживаемую после успешной загрузки; она не защищает от OOM при загрузке отдельного объекта метаданных.
Применение конфигурации и обновление кешей
- Перезапустите FE после изменения
external_meta_cache_max_weight. Значение нельзя менять, пока Catalog инициализированы. - Изменение
meta.cache.max-weightилиschema.cache.ttl-secondудаляет все кеши метаданных Catalog. Изменениеmeta.cache.<engine>.<entry>.*удаляет кеши соответствующего движка. При следующем обращении они создаются заново с новой конфигурацией. - Уже выполняющиеся запросы сохраняют загруженные ими объекты.
- Когда на Catalog типа Paimon действует ограничение FE или Catalog, собственный кеш SDK Paimon
CachingCatalogпо умолчанию отключается, чтобы избежать второго, неучтённого кеша метаданных. Явно заданное свойствоpaimon.cache-enabledимеет приоритет.
Ограничения памяти определяют, сохраняются ли объекты в кеше. Они не изменяют внешние метаданные и не заменяют REFRESH CATALOG, TTL или синхронизацию событий метаданных.
Мониторинг и диагностика нехватки памяти
Системная таблица catalog_meta_cache_statistics содержит отдельную строку для каждой комбинации FE, Catalog, движка кеша метаданных и элемента кеша. Следующие столбцы описывают управление памятью:
| Столбец | Значение | Характер значения во времени |
|---|---|---|
MAX_WEIGHT | Эффективное ограничение памяти элемента в байтах. -1 означает, что на элемент не распространяется ни одно ограничение FE, Catalog или самого элемента. | Конфигурация |
ESTIMATED_WEIGHT | Оценочное число байтов, зарезервированных элементом в данный момент. | Текущее значение на момент запроса |
WEIGHT_REJECT_COUNT | Количество отказов в приёме объектов в кеш по любой из перечисленных выше причин. | Накопительное значение для текущего экземпляра кеша |
LAST_WEIGHT_REJECT_REASON | Причина последнего отказа. | Последнее значение |
Накопительные счётчики обнуляются, когда кеши создаются заново после изменения свойства Catalog или перезапуска FE. Таблица не хранит историю, поэтому для отслеживания динамики периодически снимайте её показания. Строки с max_weight >= 0 соответствуют элементам с управлением по объёму памяти; сами ограничения задаются в fe.conf и свойствах Catalog.
При отказе в приёме объекта в кеш Doris также записывает предупреждение с ограниченной частотой: не чаще одного раза в минуту для каждого элемента:
Metadata cache entry 'hive-file' rejected a value by weight: reason=budget_exceeded, used=..., max=...
Если использование кучи FE велико и вы подозреваете, что причина в кешах внешних метаданных, выполните следующие шаги.
1. Проверьте, вносят ли управляемые кеши вклад в нехватку памяти
SELECT fe_host,
SUM(estimated_weight) AS estimated_weight,
SUM(weight_reject_count) AS weight_reject_count
FROM information_schema.catalog_meta_cache_statistics
WHERE max_weight >= 0
GROUP BY fe_host
ORDER BY fe_host;
Сравните суммарный зарезервированный объём с настроенным external_meta_cache_max_weight и с размером кучи FE. Это значение представляет собой оценку памяти, удерживаемой кешами, а не общий объём занятой кучи FE. В него не входят временная память при загрузке, объекты, на которые ссылаются выполняющиеся запросы, и кеши SDK коннекторов. Если использование кучи FE остаётся высоким при небольшом зарезервированном объёме, перейдите к шагу 6.
2. Найдите Catalog, создающие нагрузку
SELECT fe_host, catalog_name,
SUM(estimated_weight) AS estimated_weight,
SUM(weight_reject_count) AS weight_reject_count
FROM information_schema.catalog_meta_cache_statistics
WHERE max_weight >= 0
GROUP BY fe_host, catalog_name
ORDER BY estimated_weight DESC;
Сравните потребление каждого Catalog с его meta.cache.max-weight. Ищите Catalog, у которого зарезервированный объём близок к ограничению или на одном FE значительно больше, чем на остальных.
3. Изучите отдельные элементы кеша
SELECT engine_name, entry_name,
estimated_weight, max_weight,
weight_reject_count, last_weight_reject_reason
FROM information_schema.catalog_meta_cache_statistics
WHERE fe_host = '<fe_host>'
AND catalog_name = '<catalog_name>'
AND max_weight >= 0
ORDER BY estimated_weight DESC;
Элемент, у которого estimated_weight приближается к max_weight, занимает основную часть памяти Catalog. Рост weight_reject_count с причиной budget_exceeded указывает на нехватку квоты: объекты загружаются и возвращаются запросам, но не сохраняются, поэтому последующие обращения загружают их повторно. entry_too_large означает, что отдельный объект превышает ограничение элемента. incomplete_estimate не указывает на нехватку квоты; объект возвращается без кеширования.
4. Выберите способ управления
| Цель | Параметр | Когда вступает в силу |
|---|---|---|
| Ограничить суммарное потребление на одном FE | external_meta_cache_max_weight в fe.conf | После перезапуска FE |
| Изолировать один Catalog | meta.cache.max-weight | При следующем обращении после ALTER CATALOG |
| Не допустить преобладания одного элемента | meta.cache.<engine>.<entry>.max-weight | При следующем обращении после ALTER CATALOG |
| Предпочесть более свежие метаданные кешированию | Уменьшите meta.cache.<engine>.<entry>.ttl-second или задайте для meta.cache.<engine>.<entry>.enable значение false | При следующем обращении после ALTER CATALOG |
5. Что происходит после изменения
- Изменение свойства Catalog удаляет затронутые кеши; они создаются заново по мере обращения. Счётчики в системной таблице обнуляются.
- Уже выполняющиеся запросы сохраняют загруженные ими объекты.
- Уменьшение квоты увеличивает число промахов кеша. Ожидайте более частых загрузок внешних метаданных и увеличения задержки планирования, пока рабочий набор снова не начнёт помещаться в квоту.
6. Какие проблемы этот механизм не решает
Если использование кучи FE остаётся высоким при небольшом учтённом объёме памяти, причина находится за пределами квоты. Дальнейшее уменьшение max-weight не поможет. Проверьте следующие источники потребления памяти:
- Объекты метаданных, на которые ещё ссылаются выполняющиеся запросы.
- Кеши SDK коннекторов, например
CachingCatalogв Paimon при явно заданномpaimon.cache-enabled. - Пиковое потребление памяти при загрузке и материализации отдельного большого объекта метаданных, возникающее до приёма в кеш.
- Внутренние кеши FE, создаваемые вне управляемого владельца кешей Catalog и потому не отображаемые в системной таблице.
Справочник симптомов
| Симптом | Запрос | Интерпретация | Действие |
|---|---|---|---|
Использование кучи FE велико, а суммарный зарезервированный объём близок к external_meta_cache_max_weight | Шаг 1 | Управляемые кеши достигли общего ограничения FE | Уменьшите ограничение FE или самого большого Catalog либо увеличьте размер кучи FE |
| Использование кучи FE велико, но суммарный зарезервированный объём мал | Шаг 1 | Причина нехватки памяти находится за пределами квоты | Перейдите к шагу 6 |
Один Catalog близок к своему meta.cache.max-weight или занимает значительно больше памяти на одном FE | Шаг 2 | Его рабочий набор превышает выделенную долю | Увеличьте его ограничение, если позволяет куча, или добавьте ограничения отдельных элементов в нём |
weight_reject_count продолжает расти с причиной budget_exceeded | Шаг 3 | Объекты загружаются, но не сохраняются, и позднее загружаются повторно | Увеличьте квоту или уменьшите ограничения конкурирующих элементов |
weight_reject_count продолжает расти с причиной entry_too_large | Шаг 3 | Отдельные объекты превышают ограничение элемента | Увеличьте ограничение элемента или примите, что эти объекты возвращаются без кеширования |
weight_reject_count продолжает расти с причиной incomplete_estimate | Шаг 3 | Размер объекта невозможно надёжно оценить, поэтому он никогда не кешируется | Изменение квоты не поможет; запросы по-прежнему успешно выполняются без кеширования |
estimated_weight держится на уровне max_weight, а доля попаданий в кеш низкая | Шаг 3 | В элементе постоянно происходит вытеснение объектов в пределах квоты | Увеличьте ограничение элемента или сократите TTL, чтобы уменьшить рабочий набор |
Ограничения и особенности
max-weightзадаёт оценочный бюджет приёма объектов в кеш по объёму удерживаемой памяти. Оценки используют структурные константы и счётчики полезных данных; они не моделируют точное размещение объектов в работающей JVM. Результат не соответствует RSS операционной системы и не заменяет мониторинг кучи FE и GC.- Кешированные значения удерживаются сильными ссылками до вытеснения, истечения срока действия или инвалидации. Настройте квоту, если кеши метаданных не должны расти вместе с рабочим набором.
- Общая инфраструктура времени выполнения, например клиенты Catalog, экземпляры FileIO и пулы потоков, не учитывается ни в одном элементе.
- Несколько физических кешей могут использовать один токен
<entry>и, соответственно, общее ограничение элемента, например два кеша Icebergpartition_viewи три кеша ADBCmetadata. - Объекты с неполной оценкой никогда не кешируются. Если у элемента низкая доля попаданий в кеш одновременно с отказами
incomplete_estimate, кеширование неэффективно для этого типа объектов. - В новых свойствах, передаваемых через DDL, неизвестные ключи
max-weightдля известного движка строго отклоняются. Неизвестные ключи, сохранённые более ранней или более поздней версией, допускаются, чтобы Catalog мог инициализироваться после обновления.
Рекомендации
- Начните с общего ограничения FE, чтобы суммарное потребление памяти всеми Catalog не могло расти бесконечно.
- Добавьте ограничения Catalog для больших производственных Catalog, использующих один FE.
- Добавляйте ограничения отдельных элементов только для тех, которые потребляют основную часть памяти; каждому элементу собственная настройка не требуется.
- Оставляйте достаточно памяти в куче для планирования запросов и других кешей FE, не выделяя большую часть кучи JVM кешам внешних метаданных.
- Увеличьте квоту или уменьшите ограничения конкурирующих элементов, если один и тот же объект многократно загружается после отказов
budget_exceeded. - Используйте процентное значение при разных размерах кучи FE или фиксированный размер, если на каждом FE должно действовать одинаковое ограничение в байтах.