当处理大量小插入到（非复制的）mergetree中时，这就是已知的问题。
这是一个错误，我们需要调查和修复。
对于解决方法，应按建议以较大的批发送插入：大约每秒一批：https://clickhouse.tech/docs/en/introduction/performance/#performance-插入数据时。

clickhouse为这个缓冲区提供了特殊类型的表。它存储在内存中，允许许多小的插入而不会出现问题。我们有近200种不同的插入每秒-它工作得很好。
缓冲表：

CREATE TABLE logs.log_buffer (rid String, created DateTime, some String, d Date MATERIALIZED toDate(created))
ENGINE = Buffer('logs', 'log_main', 16, 5, 30, 1000, 10000, 1000000, 10000000);

主表：

CREATE TABLE logs.log_main (rid String, created DateTime, some String, d Date) 
ENGINE = MergeTree(d, sipHash128(rid), (created, sipHash128(rid)), 8192);

手册内容：https://clickhouse.yandex/docs/en/operations/table_engines/buffer/

我也遇到过类似的问题，尽管不是因为每秒插入20次导致服务器达到高平均负载、内存消耗和cpu使用率。我创建了一个缓冲表来缓冲内存中的插入，然后定期将它们刷新到“实”磁盘表中。就像魔术一样，一切都很顺利：loadavg、内存和cpu使用率降到了正常水平。好的一点是，您可以对缓冲区表运行查询，并从内存和磁盘中获取匹配的行，这样客户机就不会受到缓冲区的影响。看到了吗https://clickhouse.tech/docs/en/engines/table-engines/special/buffer/

或者，您可以使用https://github.com/nikepan/clickhouse-bulk：它将缓冲多个插入，并根据用户策略将它们一起刷新。

clickhouse合并引擎的设计并不意味着同时进行小的写操作。据我所知，mergetree合并了 parts 根据分区将数据写入表中，然后重新组织 parts 为了更好的聚合阅读。如果我们经常写些小文章，你会遇到另一个例外 Merge ```
Error: 500: Code: 252, e.displayText() = DB::Exception: Too many parts (300). Merges are processing significantly slow

当您试图理解为什么会抛出上述异常时，您的想法会更清楚。ch需要合并数据，并且对于可以存在多少部分有一个上限！批处理中的每一次写入都作为一个新部分添加，然后最终与分区表合并。

SELECT
table, count() as cnt
FROM system.parts
WHERE database = 'dbname' GROUP BY table order by cnt desc

上面的查询可以帮助您监视部件，在编写部件将如何增加并最终合并的过程中进行观察。
我最好的选择是缓冲数据集并定期将其刷新到db，但这意味着没有实时分析。
使用缓冲区是好的，但是请考虑以下几点：
如果服务器异常重启，缓冲区中的数据将丢失。
final和sample不适用于缓冲表。这些条件被传递到目标表，但不用于处理缓冲区中的数据
向缓冲区添加数据时，其中一个缓冲区被锁定(所以没有阅读）
如果复制了目标表，则在写入缓冲区表时，复制表的某些预期特性将丢失(无重复数据消除）
请通读，这是一个特例引擎：https://clickhouse.tech/docs/en/engines/table-engines/special/buffer/