**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 :)

(*it)->name, (*it)->version.removal_tid_lock);
            addPartContributionToColumnAndSecondaryIndexSizes(*it);
            addPartContributionToDataVolume(*it);
            modifyPartState(it, DataPartState::Active); 
            restored_active_part = true;
        };
        auto it_middle = data_parts_by_info.lower_bound(part->info);
        
        if (it_middle != data_parts_by_info.begin())
        {
            auto it = std::prev(it_middle);
            if (part->contains(**it) && is_appropriate_state((*it)->getState()))
            {
                
                if ((*it)->info.min_block != part->info.min_block)
                    update_error(it);
                if ((*it)->getState() != DataPartState::Active)
                    activate_part(it);
                pos = (*it)->info.max_block + 1;
                restored.push_back((*it)->name);
            }
            else if ((*it)->info.partition_id == part->info.partition_id)
                update_error(it);
            else
                error = true;
        }
        else
            error = true;
        
        for (auto it = it_middle; it != data_parts_by_info.end() && part->contains(**it); ++it)