您在 MergeTree 表上达到了 parts_to_throw_insert 设置。您可以使用以下方法监视给定表的活动部件数量
select count(*) from system.parts where table = '<table_name>' and active == 1
向 Clickhouse 插入数据的首要要求是：您永远不应该每秒发送过多 INSERT 语句。理想情况下 - 每秒/每几秒插入一次。
因此，您可以每秒插入 100K 行，但只能使用一个大的批量 INSERT 语句。当您每秒向 *MergeTree 表发送数百/数千个插入语句时，您总会遇到一些错误，并且无法通过调整某些设置来更改它。
如果您无法将大量插入合并到外部的一个大的批量插入语句中 - 那么您应该在 *MergeTree 表之前创建缓冲表。
每个插入都会在
/var/lib/clickhouse/.../table_name/中创建一个文件夹。在该文件夹内，每列有 2 个文件 - 一个包含数据（压缩），另一个包含索引。数据在这些文件中按主键物理排序。这些文件夹称为“部件”。ClickHouse 在后台将这些较小的部件合并为较大的部件。它根据某些规则选择要合并的部件。合并两个（或多个）部件后，会创建一个更大的部件，并且旧部件会排队等待删除。您列出的设置允许微调合并部件的规则。合并过程的目标 - 是为每个分区留下一个大部件（或每个分区几个大部件，它们不值得合并，因为它们太大）。另请查看 评论。
如果您创建新部件的速度过快（例如，通过执行大量的小型插入），而 ClickHouse 无法以适当的速度合并它们（因此新部件的创建速度快于 ClickHouse 合并它们的速度） - 那么您会收到异常“合并处理速度明显慢于插入”。您可以尝试提高限制，但可能会遇到由于文件/目录数量过多（如 inode 限制）而导致文件系统问题的情况。
如果您同时插入到多个分区，则问题会因插入影响的分区数量而加剧。
您可以尝试使用列出的设置之一或使用 max_insert_block_size / max_block_size / insert_format_max_block_size / max_client_network_bandwidth 来调整 clickhouse 的行为。但是：更好的解决方案是只以预期速度插入数据。预期速度是：每 1-2 秒插入一次，每次插入包含 10K-500K 行数据。
因此，解决“合并处理速度明显慢于插入”的正确方法是调整每秒的插入次数和每次插入的行数。如果数据逐行传入，请使用批量插入将小的插入合并到一个较大的插入中。如果您有太多数据要一次插入，请限制巨大的插入。不要更改 clickhouse 的内部机制，除非您真的清楚地了解它们意味着什么。
如果您的数据传输速度超过每秒 500K 行 - 最有可能的是您需要在集群中增加服务器来处理该流量，而不是调整设置。
后台合并的速度通常取决于存储速度、使用的压缩设置、MergeTree 选项（合并算法 - 普通合并/聚合/求和/折叠等）以及使用的排序键。