**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 (disk_ptr->supportsCache())
            {
                if (defined_disk_names.contains(disk_ptr->getName()))
                {
                    auto caches = disk_ptr->getCacheLayersNames();
                    disk_names_wrapped_in_cache.insert(caches.begin(), caches.end());
                }
            }
        }
        for (const auto & [disk_name, disk] : getContext()->getDisksMap())
        {
            if (disk->isBroken())
                continue;
            if (!defined_disk_names.contains(disk_name)
                && disk->exists(relative_data_path)
                && !disk_names_wrapped_in_cache.contains(disk_name))
            {
                for (const auto it = disk->iterateDirectory(relative_data_path); it->isValid(); it->next())
                {
                    if (MergeTreePartInfo::tryParsePartName(it->name(), format_version))
                    {
                        throw Exception(
                            ErrorCodes::UNKNOWN_DISK,
                            "Part {} ({}) was found on disk {} which is not defined in the storage policy",
                            backQuote(it->name()), backQuote(it->path()), backQuote(disk_name));
                    }