We use clickhosue version 21.12.2.17 before.It works well

But we found that after upgrade to 22.3.3, the memory of clickhouse used grow up daily .

I don't know if this is a memory overflow

here is the promethues metric 'ClickHouseMetrics_MemoryTracking'  duration last 15days

![image](https://user-images.githubusercontent.com/8294900/163744096-80270f73-becd-47ce-91b7-c6a96f13c1b6.png)

and I restarted cknode1 at 4.14 ,you can see it come down and rising again.

And here is some sql and result I have run for diagnosis。

![image](https://user-images.githubusercontent.com/8294900/163744418-251c86d8-832c-4aff-aa1a-6e565d47d196.png)

![image](https://user-images.githubusercontent.com/8294900/163744455-73813554-784a-4df6-803e-5ef49dbf1776.png)

![image](https://user-images.githubusercontent.com/8294900/163744529-50c4e359-feb7-4499-9449-0efc1c75942f.png)

![image](https://user-images.githubusercontent.com/8294900/163744587-c51e3ba3-6925-4591-b15d-bb0e0262af8c.png)

we use dict and MaterializedView . no living view.

we have tried  'system drop mark cache '  and change 'max_bytes_before_external_group_by' to '6g'.Not work

Is there anyting else  I can do?





LOG_TRACE(log, "Skipping writing part. Buffer is empty.");
        return;
    }
    if (part_tags.size() == S3_WARN_MAX_PARTS)
    {
        
        LOG_WARNING(log, "Maximum part number in S3 protocol has reached (too many parts). Server may not accept this whole upload.");
    }
    if (schedule)
    {
        UploadPartTask * task = nullptr;
        int part_number;
        {
            std::lock_guard lock(bg_tasks_mutex);
            task = &upload_object_tasks.emplace_back();
            ++num_added_bg_tasks;
            part_number = num_added_bg_tasks;
        }
        
        auto task_finish_notify = [&, task]()
        {
            std::lock_guard lock(bg_tasks_mutex);
            task->is_finised = true;
            ++num_finished_bg_tasks;
            
            
            
            bg_tasks_condvar.notify_one();
        };
        try