xy720 opened a new pull request, #68541:
URL: https://github.com/apache/doris/pull/68541
### What problem does this PR solve?
Related PR: #64650, #49721
This PR fixes an FE memory leak that survives restarts and upgrades. Stale
entries in `PartitionInfo.idToStoragePolicy` left by dropped partitions are
persisted in the image. Nothing ever releases them, even after #64650.
Before #64650, `PartitionInfo.dropPartition()` did not remove the partition
from `idToStoragePolicy`, so every dropped or replaced partition leaked one
entry.
Since #49721 made `idToStoragePolicy` a serialized field
(`IdToStoragePolicy`), the leaked entries are also written to the image and
reloaded on every FE restart.
#64650 stopped the leak from growing by fixing `dropPartition()`, but it
does not release entries that are already in the image.
Those entries belong to partitions that no longer exist, so no
`dropPartition()` call will ever remove them.
After upgrading, the FE still loads all of them into memory. Restarting does
not help either, because the entries are loaded back from the image.
The leak grows fastest on tables whose partitions are replaced often, e.g.
an async MTMV with `REFRESH AUTO ON COMMIT`. Every refresh runs INSERT
OVERWRITE, which replaces each refreshed partition and leaks one entry per
partition.
In our cluster, a single MTMV with ~100 partitions accumulated ~7.6 million
leaked entries (~740 MB retained heap). Several such MTMVs caused repeated FE
OOMs.
This PR releases the leaked memory when the image is loaded. `PartitionInfo`
now implements `GsonPostProcessable`. After deserialization, it removes every
`idToStoragePolicy` entry whose partition has no `idToDataProperty` entry.
How to reproduce:
1. On a version without #64650 (e.g. 3.1.x), create a partitioned table
and overwrite a partition repeatedly:
```sql
CREATE TABLE t (k INT, v INT)
PARTITION BY LIST (k) (PARTITION p1 VALUES IN ("1"))
DISTRIBUTED BY HASH(k) BUCKETS 1
PROPERTIES ("replication_num" = "1");
-- run N times
INSERT OVERWRITE TABLE t PARTITION (p1) VALUES (1, 1);
```
Each overwrite leaks one more entry in `idToStoragePolicy`, while the table
still has only one partition.
2. Wait for a checkpoint, so the leaked entries are written to the image.
3. Upgrade the FE to a version that contains #64650 and restart it. A heap
dump shows that `idToStoragePolicy` of `t` still holds N+1 entries. More
overwrites no longer add entries, but the leaked ones are never released.
With this PR, the leaked entries are released when the image is loaded, and
FE logs `removed N stale storage policy entries of dropped partitions`.
### Release note
Fix an FE memory leak where storage policy entries of dropped partitions,
persisted in the image by older versions, were never released and could cause
FE OOM.
### Check List (For Author)
- Test
- [ ] Regression test
- [x] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- Behavior changed:
- [x] No.
- [ ] Yes.
- Does this need documentation?
- [x] No.
- [ ] Yes.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
--
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]
