morningman opened a new pull request, #69557:
URL: https://github.com/apache/doris/pull/69557
### What problem does this PR solve?
Issue Number: None
Related PR: #66717, #67726
Problem Summary:
**In short.** This brings the weight columns of
`information_schema.catalog_meta_cache_statistics` from branch-4.x #66717 to
master. Master shows four of the ten: this PR adds `WEIGHT_BOUNDED`,
`EVICTION_WEIGHT`, `CATALOG_MAX_WEIGHT`, `CATALOG_ESTIMATED_WEIGHT`,
`GLOBAL_MAX_WEIGHT` and `GLOBAL_ESTIMATED_WEIGHT` with the 4.x names, types and
meanings, and makes a cache entry without a weight bound report `-1` in every
weight column, as 4.x does, instead of `0` in `ESTIMATED_WEIGHT` and
`WEIGHT_REJECT_COUNT`.
**Background.** External catalogs can bound the memory of their metadata
caches: an FE-global limit (`external_meta_cache_max_weight`), a catalog limit
(`meta.cache.max-weight`) and per-entry limits. `catalog_meta_cache_statistics`
is how users watch those caches. On branch-4.x (#66717) the view tells, per
entry, whether it is weight bounded, what it holds and has evicted, and how
full its catalog and the FE-global budget are. Master (#67726) re-implemented
the governance on the connector cache framework and exposed only `MAX_WEIGHT`,
`ESTIMATED_WEIGHT`, `WEIGHT_REJECT_COUNT` and `LAST_WEIGHT_REJECT_REASON`.
**The problem, and what it cost.** Monitoring queries written for 4.x fail
on master with an unknown column as soon as they name one of the other six, and
so do the weight scenarios of 4.x's `test_paimon_table_meta_cache` and
`test_iceberg_table_meta_cache`. There is also no way on master to see how much
of a catalog or of the FE-global budget is used, or how many bytes were evicted
to make room. And an entry without a weight bound reports `ESTIMATED_WEIGHT =
0` and `WEIGHT_REJECT_COUNT = 0`, which reads like an empty but bounded cache.
**How this PR fixes it.**
- `MetaCacheBudgetManager.EntryBudget` exposes the catalog limit the entry
is admitted under (the smaller of the catalog and FE-global limits, as the
admission check uses it), the bytes charged to its catalog, the FE-global limit
and the bytes charged to it. A limit that does not exist is `-1`.
- `ScopedMetaCache` adds the reserved bytes of each value it removes by
eviction, by Caffeine (capacity or expiry) or to make room in the budget, to an
eviction-weight counter before the reservation is released. Invalidation and
replacement do not count.
- `ScopedMetaCache.CacheMetrics`, `MetaCacheEntryStats`, `SchemaTable` and
`MetadataGenerator` carry the six values. The columns are appended after
`LAST_WEIGHT_REJECT_REASON`. For an entry without a weight bound, every weight
column is `-1`.
- The BE scanner knows the six columns. An FE that does not know them
rejects the request, and the scanner then asks for the leading 28 columns, then
24, as it already did for the four earlier weight columns.
`SELECT *` positions still differ from 4.x, because master's base columns
also have `EVICTION_RATE`; queries that name their columns now work on both.
**Results.**
| | master | this PR |
|---|---|---|
| `SELECT weight_bounded, catalog_max_weight ... FROM
catalog_meta_cache_statistics` | fails: unknown column | works, as on 4.x |
| Entry of a catalog with `meta.cache.max-weight = 128MB` | `MAX_WEIGHT =
134217728` only | also `CATALOG_MAX_WEIGHT = 134217728`, the catalog's and the
FE-global charges, the evicted bytes |
| Entry without any weight bound | `ESTIMATED_WEIGHT = 0`,
`WEIGHT_REJECT_COUNT = 0` | `-1` in every weight column |
| New BE, FE without the six columns | n/a | the BE falls back to the
leading 28 columns |
Tests:
- `MetaCacheWeightGovernanceTest`: an entry without a weight bound reports
`-1` everywhere; the catalog and FE-global limits and charges of bounded
entries, with and without an FE-global limit; a budget reclaim and a capacity
eviction add the evicted reservation to the eviction weight, an invalidation
does not. Restoring master's `0` for unbounded entries, or dropping the
eviction accounting, turns these tests red.
- `FeMetaCacheEntryTest` checks the fe-core view of an unbounded and of a
bounded entry; `HudiConnectorHmsCacheTest` now expects `-1` for its unbounded
entry.
- Regression: `test_paimon_table_meta_cache` gets the weight scenario of 4.x
on master's entry names (a catalog with `meta.cache.max-weight = 128MB` next to
an unbounded one); `test_iceberg_table_meta_cache` puts its first catalog under
a catalog limit and checks the budget hierarchy of its bounded entries, as 4.x
does; the new `test_remote_doris_meta_cache_weight` covers the `doris` engine
without any external service.
- Manually: a BE from this PR against an FE without the six columns returns
the rows (the FE rejects the 34 columns, the BE retries with 28).
Original author: @CalvinKirs
### Release note
`information_schema.catalog_meta_cache_statistics` adds the columns
`WEIGHT_BOUNDED`, `EVICTION_WEIGHT`, `CATALOG_MAX_WEIGHT`,
`CATALOG_ESTIMATED_WEIGHT`, `GLOBAL_MAX_WEIGHT` and `GLOBAL_ESTIMATED_WEIGHT`.
A metadata cache entry without a weight bound now reports `-1` instead of `0`
in `ESTIMATED_WEIGHT` and `WEIGHT_REJECT_COUNT`.
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [x] Regression test
- [x] Unit Test
- [x] Manual test (add detailed scripts or steps below)
With an FE built before this PR and a BE built from it, `SELECT ...
FROM information_schema.catalog_meta_cache_statistics` returns the rows; the FE
log shows the rejected 34-column request.
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason <!-- Add your reason? -->
`test_paimon_table_meta_cache` and `test_remote_doris_meta_cache_weight`
were run against a local cluster and generated their `.out` files.
`test_iceberg_table_meta_cache` needs the hive3 environment and was not run
locally; its new check uses assertions only.
- Behavior changed:
- [ ] No.
- [x] Yes. <!-- Explain the behavior change -->
A metadata cache entry without a weight bound reports `-1` instead of
`0` in `ESTIMATED_WEIGHT` and `WEIGHT_REJECT_COUNT`. Upgrade BE before FE: an
older BE cannot fill the six new columns.
- Does this need documentation?
- [ ] No.
- [x] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
The page of `catalog_meta_cache_statistics` should list the six
columns (doc PR to follow).
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR should
merge into -->
--
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]
