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

{
        std::lock_guard lock{mutex};
        auto it = temp_dirs.find(disk);
        if (it == temp_dirs.end())
            it = temp_dirs.emplace(disk, std::make_shared<TemporaryFileOnDisk>(disk, "tmp/")).first;
        return it->second->getPath();
    }
private:
    void attachIfAllPartsRestored()
    {
        if (!num_parts || (parts.size() < num_parts))
            return;
        /
        std::sort(
            parts.begin(),
            parts.end(),
            [](const MutableDataPartPtr & lhs, const MutableDataPartPtr & rhs) { return lhs->info.min_block < rhs->info.min_block; });
        storage->attachRestoredParts(std::move(parts));
        parts.clear();
        temp_dirs.clear();
        num_parts = 0;
    }
    std::shared_ptr<MergeTreeData> storage;
    BackupPtr backup;
    size_t num_parts = 0;
    MutableDataPartsVector parts;
    std::map<DiskPtr, std::shared_ptr<TemporaryFileOnDisk>> temp_dirs;
    mutable std::mutex mutex;
};
void MergeTreeData::restorePartsFromBackup(RestorerFromBackup & restorer, const String & data_path_in_backup, const std::optional<ASTs> & partitions)