**Describe the bug**

Since we upgraded to 20.10.3.30, one of our clickhouse cluster takes much more time to start. (Up to 50 minutes, and before it took ~3 minutes)
The log file is filled with
>  <Debug> DiskLocal: Reserving 1.00 MiB on disk `default`, having unreserved 16.90 TiB

Additionally, the memory consumption increases, linearly, a lot (up to arround 230 G for us) and then drop back to normal values once clickhouse finished starting up. During that loading phase, a single CPU core is used at 100%.
If that memory is not available for the machine, clickhouse gets OOMed by the kernel.


**How to reproduce**
* Issue appeared after we upgraded to ClickHouse server version 20.10.3.30

* How could I find wich of our tables may be responsible for that ?


**Expected behavior**
A fast startup :)

{
            ++iter;
        }
    }
    if (have_parts_with_version_metadata)
        transactions_enabled.store(true);
    
    
    
    auto active_parts_range = getDataPartsStateRange(DataPartState::Active);
    auto prev_it = active_parts_range.begin();
    auto end_it = active_parts_range.end();
    bool less_than_two_active_parts = prev_it == end_it || std::next(prev_it) == end_it;
    if (!less_than_two_active_parts)
    {
        (*prev_it)->assertState({DataPartState::Active});
        auto curr_it = std::next(prev_it);
        while (curr_it != data_parts_by_state_and_info.end() && (*curr_it)->getState() == DataPartState::Active)
        {
            (*curr_it)->assertState({DataPartState::Active});
            
            if ((*curr_it)->info.partition_id != (*prev_it)->info.partition_id)
            {
                ++prev_it;
                ++curr_it;
                continue;
            }
            if ((*curr_it)->contains(**prev_it))
            {
                deactivate_part(prev_it);