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

if (num_parts == 0 && parts_from_wal.empty())
    {
        resetObjectColumnsFromActiveParts(part_lock);
        LOG_DEBUG(log, "There are no data parts");
        return;
    }
    DataPartsVector broken_parts_to_detach;
    DataPartsVector duplicate_parts_to_remove;
    if (num_parts > 0)
        loadDataPartsFromDisk(
            broken_parts_to_detach, duplicate_parts_to_remove, pool, num_parts, parts_queue, skip_sanity_checks, settings);
    if (!parts_from_wal.empty())
        loadDataPartsFromWAL(broken_parts_to_detach, duplicate_parts_to_remove, parts_from_wal, part_lock);
    for (auto & part : broken_parts_to_detach)
    {
        auto builder = part->data_part_storage->getBuilder();
        part->renameToDetached("broken-on-start", builder); 
        builder->commit();
    }
    for (auto & part : duplicate_parts_to_remove)
        part->remove();
    auto deactivate_part = [&] (DataPartIteratorByStateAndInfo it)
    {
        const DataPartPtr & part = *it;
        part->remove_time.store(part->modification_time, std::memory_order_relaxed);
        auto creation_csn = part->version.creation_csn.load(std::memory_order_relaxed);
        if (creation_csn != Tx::RolledBackCSN && creation_csn != Tx::PrehistoricCSN && !part->version.isRemovalTIDLocked())
        {