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

part->name, drop_range.getPartName());
        }
        parts_to_remove.emplace_back(part);
    }
    bool clear_without_timeout = true;
    
    
    
    auto inactive_parts_to_remove_immediately = getDataPartsVectorInPartitionForInternalUsage({DataPartState::Outdated, DataPartState::Deleting}, drop_range.partition_id, &lock);
    
    removePartsFromWorkingSet(txn, parts_to_remove, clear_without_timeout, lock);
    for (auto & part : inactive_parts_to_remove_immediately)
    {
        if (!drop_range.contains(part->info))
            continue;
        part->remove_time.store(0, std::memory_order_relaxed);
        parts_to_remove.push_back(std::move(part));
    }
    return parts_to_remove;
}
void MergeTreeData::restoreAndActivatePart(const DataPartPtr & part, DataPartsLock * acquired_lock)
{
    auto lock = (acquired_lock) ? DataPartsLock() : lockParts();    
    if (part->getState() == DataPartState::Active)
        return;
    addPartContributionToColumnAndSecondaryIndexSizes(part);
    addPartContributionToDataVolume(part);
    modifyPartState(part, DataPartState::Active);
}
void MergeTreeData::forgetPartAndMoveToDetached(const MergeTreeData::DataPartPtr & part_to_detach, const String & prefix, bool restore_covered)