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

DataPartsVector & broken_parts_to_detach,
    DataPartsVector & duplicate_parts_to_remove,
    ThreadPool & pool,
    size_t num_parts,
    std::queue<std::vector<std::pair<String, DiskPtr>>> & parts_queue,
    bool skip_sanity_checks,
    const MergeTreeSettingsPtr & settings)
{
    
    pool.setMaxThreads(std::min(static_cast<size_t>(settings->max_part_loading_threads), num_parts));
    size_t num_threads = pool.getMaxThreads();
    std::vector<size_t> parts_per_thread(num_threads, num_parts / num_threads);
    for (size_t i = 0ul; i < num_parts % num_threads; ++i)
        ++parts_per_thread[i];
    
    
    std::vector<std::vector<std::pair<String, DiskPtr>>> threads_parts(num_threads);
    std::set<size_t> remaining_thread_parts;
    std::queue<size_t> threads_queue;
    for (size_t i = 0; i < num_threads; ++i)
    {
        remaining_thread_parts.insert(i);
        threads_queue.push(i);
    }
    while (!parts_queue.empty())
    {
        assert(!threads_queue.empty());
        size_t i = threads_queue.front();
        auto & need_parts = parts_per_thread[i];
        assert(need_parts > 0);