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

~MergeTreeWriteAheadLog();
    void addPart(DataPartInMemoryPtr & part);
    void dropPart(const String & part_name);
    std::vector<MergeTreeMutableDataPartPtr> restore(const StorageMetadataPtr & metadata_snapshot, ContextPtr context);
    using MinMaxBlockNumber = std::pair<Int64, Int64>;
    static std::optional<MinMaxBlockNumber> tryParseMinMaxBlockNumber(const String & filename);
    void shutdown();
private:
    void init();
    void rotate(const std::unique_lock<std::mutex> & lock);
    void sync(std::unique_lock<std::mutex> & lock);
    const MergeTreeData & storage;
    DiskPtr disk;
    String name;
    String path;
    std::unique_ptr<WriteBuffer> out;
    std::unique_ptr<NativeWriter> block_out;
    Int64 min_block_number = std::numeric_limits<Int64>::max();
    Int64 max_block_number = -1;
    BackgroundSchedulePool & pool;
    BackgroundSchedulePoolTaskHolder sync_task;
    std::condition_variable sync_cv;
    size_t bytes_at_last_sync = 0;
    bool sync_scheduled = false;
    bool shutdown_called = false;
    mutable std::mutex write_mutex;
    Poco::Logger * log;
};
}