924060929 commented on PR #4061:
URL: https://github.com/apache/doris-website/pull/4061#issuecomment-5448165198
One additional suggestion: the main operator question is not only what each
field means, but what to do when FE memory is under pressure. Could we add a
dedicated section such as **Troubleshoot and control memory pressure** with a
short operational runbook?
Suggested flow:
1. **Check whether managed metadata caches are materially contributing to
the pressure.** Query the current per-FE global reservation and configured
limit. Explicitly remind users that this is estimated retained-cache weight,
not total FE heap, and that load-time temporary memory and count-bounded
entries are outside it.
2. **Locate the responsible Catalogs.** Provide the Catalog-level summary
query grouped by `FE_HOST, CATALOG_NAME`, and explain how to identify a Catalog
close to its limit or disproportionately large on one FE.
3. **Drill down to entries.** Query `ENGINE_NAME, ENTRY_NAME,
ESTIMATED_WEIGHT, MAX_WEIGHT, EVICTION_WEIGHT, WEIGHT_REJECT_COUNT,
LAST_WEIGHT_REJECT_REASON` for the target Catalog. Explain that increasing
rejection/eviction can indicate quota pressure or an oversized candidate.
4. **Choose the appropriate control:**
- set `external_meta_cache_max_weight` for an FE-wide bound (requires FE
restart);
- set `meta.cache.max-weight` to isolate one Catalog;
- set `meta.cache.<engine>.<entry>.max-weight` when one supported entry
dominates;
- reduce TTL or disable an entry when fresher metadata is preferred over
caching.
5. **Explain what happens after a change.** Catalog-property changes clear
the initialized Catalog cache group and rebuild it lazily; in-flight queries
keep their existing objects. A lower quota can increase misses and external
metadata load latency.
6. **State what this mechanism cannot solve.** If FE heap remains high while
accounted weight is low, investigate unaccounted/count-bounded caches, metadata
objects still referenced by running queries, connector SDK caches, and
load/materialization peaks instead of simply lowering `max-weight`.
A compact “symptom → query → interpretation → action” table would make this
much more useful during an incident than distributing the information across
configuration, observability, and caveat sections.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
