ClickHouse 中出现 DB::Exception: Too many parts 错误

在 ClickHouse 中出现 DB::Exception: Too many parts 错误，通常是由于表中数据分片（parts）数目凌驾系统限制，导致归并（merge）操作无法及时处置惩罚。以下是渐渐办理方案：

---

1. 理解问题缘故原由

• MergeTree 表引擎特性：ClickHouse 的 MergeTree 引擎表会将数据划分为多个 parts，后台线程定期归并小 parts 成大 part。如果写入速度远快于归并速度，parts 数目会累积。
  
• 直接缘故原由：当前表有 600 个 parts（平均大小 10.82 MiB），凌驾默认阈值（通常为 300）。
  

---

2. 暂时应急措施

手动触发归并

1. OPTIMIZE TABLE your_table FINAL;

复制代码

• 作用：强制归并所有 parts，但大概耗时较长，生产环境需谨慎。
  
• 注意：FINAL 关键字会强制归并，即使数据已经归并过。
  

---

3. 优化写入策略

减少小批量写入频率

• 保举批量大小：单次插入数据量建议在 100MB~1GB 之间（根据硬件调整）。
  
• 示例：将每秒写入 100 次 1MB 的数据，改为每 10 秒写入 1 次 100MB 的数据。
  

利用 Buffer 表缓冲写入

1. CREATE TABLE your_table_buffer AS your_table
2. ENGINE = Buffer(default, your_table, 16, 10, 100, 10000, 1000000, 10000000, 100000000);

复制代码

• 作用：通过内存缓冲表累积小批量写入，批量刷入目标表。
  

---

4. 调整归并参数

修改 merge_tree 配置（在 config.xml 或 users.xml）

1. <merge_tree>
2.     <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
3.     <max_parts_in_total>1000</max_parts_in_total>  <!-- 调高阈值 -->
4.     <parts_to_delay_insert>500</parts_to_delay_insert>  <!-- 插入延迟阈值 -->
5.     <parts_to_throw_insert>600</parts_to_throw_insert>  <!-- 插入报错阈值 -->
6. </merge_tree>

复制代码

• 关键参数：
  
  
  
  • max_parts_in_total: 允许的最大 parts 总数。
    
  • parts_to_delay_insert: 到达此数目后，新插入会耽误。
    
  • parts_to_throw_insert: 到达此数目后，新插入会报错。
    
  
  

增加后台归并线程数

1. <background_pool_size>16</background_pool_size>       <!-- 默认 16 -->
2. <background_schedule_pool_size>16</background_schedule_pool_size>

复制代码

• 注意：根据 CPU 核心数调整，制止过度占用资源。
  

---

5. 优化表结构

调整分区粒度

1. CREATE TABLE your_table (
2.     ...
3. ) ENGINE = MergeTree()
4. PARTITION BY toYYYYMM(date_column)  -- 按月度分区，而非按天
5. ORDER BY (timestamp, id);

复制代码

• 作用：减少分区数目，降低每个分区的 parts 数目。
  

利用 TTL 主动清理旧数据

1. ALTER TABLE your_table MODIFY TTL date_column + INTERVAL 30 DAY;

复制代码

• 作用：主动删除逾期数据，减少 parts 总数。
  

---

6. 监控与维护

查询当前 parts 状态

1. SELECT
2.     table,
3.     count() AS parts_count,
4.     formatReadableSize(sum(bytes)) AS total_size
5. FROM system.parts
6. WHERE active
7. GROUP BY table;

复制代码

定期检查归并状态

1. SELECT
2.     database,
3.     table,
4.     elapsed,
5.     progress,
6.     is_mutation
7. FROM system.merges;

复制代码

---

7. 高级方案（可选）

利用 Kafka 引擎表 + Materialized View

1. CREATE TABLE your_kafka_source
2. ENGINE = Kafka()
3. SETTINGS ...;
5. CREATE MATERIALIZED VIEW your_mv TO your_table AS
6. SELECT * FROM your_kafka_source;

复制代码

• 作用：通过 Kafka 引擎表批量消费数据，减少写入频率。
  

---

总结

• 立刻执行：手动 OPTIMIZE TABLE 缓解问题。
  
• 短期调整：调高 max_parts_in_total 阈值。
  
• 长期根治：优化写入批量大小、利用 Buffer 表或 Kafka 管道。
  
• 预防措施：监控 parts 数目，调整分区策略和 TTL。
  

通过组合利用这些方法，可有效制止 Too many parts 错误，确保 ClickHouse 稳定运行。

优化 ClickHouse 的 `background_pool_size` 需要联合硬件资源、工作负载类型和监控指标渐渐调整。以下是分步指南：
---
### **1. 理解参数作用**
- **`background_pool_size`** 控制后台线程池的大小，用于处置惩罚归并（Merge）、物化视图刷新、数据插入（Insert）等后台任务。
- 线程不敷会导致任务积压（如归并耽误、写入卡顿）；过多大概导致资源争用（CPU/IO）或上下文切换开销。
---
### **2. 检察当前状态**
#### **检查后台任务积压**
```sql
SELECT
    database,
    table,
    elapsed,
    progress
FROM system.merges;  -- 检察归并任务进度和耗时
SELECT * FROM system.metrics
WHERE metric IN ('BackgroundPoolTask', 'BackgroundSchedulePoolTask');  -- 等候执行的任务数
```
- 如果 `elapsed` 值高或任务堆积，大概是线程不敷。
#### **监控系统指标**
```sql
SELECT
    value AS threads_num,
    'background_pool_size' AS param
FROM system.settings
WHERE name = 'background_pool_size';
```
- 对比当前线程数与实际负载。
---
### **3. 设置建议值**
#### **初始建议值**
- **CPU 核心数**：通常设置为物理 CPU 核心数的 **50%~100%**。
  - 比方：16 核 CPU → 初始值设为 `8~16`。
- **存储类型**：
  - **HDD**：守旧设置（制止 IO 争用）。
  - **SSD/NVMe**：可适当调高（IO 吞吐更高）。
#### **写入/归并密集型场景**
- 高频写入或大分区归并时，可渐渐增加线程数（比方从 `16` 调整到 `24`），但需观察资源瓶颈。
---
### **4. 调整并验证**
#### **修改配置**
在 `config.xml` 或 `users.xml` 中调整：
```xml
<background_pool_size>24</background_pool_size>
```
重启 ClickHouse 服务收效。
#### **验证结果**
- **任务积压减少**：检查 `system.merges` 和 `system.metrics`。
- **资源利用率**：监控 CPU、IO 利用率（制止长期凌驾 80%）。
- **查询性能**：确保前台查询未因资源争用而变慢。
---
### **5. 高级优化**
#### **区分任务优先级**
- 利用 `background_processing_pool_size`（社区版需手动调整）分离归并和插入任务。
- 通过 `SET max_threads = ...` 限制单个查询资源，制止后台任务被壅闭。
#### **联合其他参数**
- **`max_background_merges`**：控制归并任务并发数（默认 16）。
- **`number_of_free_entries_in_pool_to_execute_mutation`**：控制突变任务触发阈值。
---
### **6. 监控工具**
- **Prometheus + Grafana**：集成 `ClickHouse Exporter` 监控后台任务队列、CPU/IO。
- **内置表**：定期检查 `system.asynchronous_metrics` 和 `system.events`。
---
### **示例配置**
```xml
<!-- 针对 32 核 SSD 服务器，高写入场景 -->
<background_pool_size>24</background_pool_size>
<max_background_merges>16</max_background_merges>
<number_of_free_entries_in_pool_to_execute_mutation>8</number_of_free_entries_in_pool_to_execute_mutation>
```
---
### **总结**
- 从默认值开始，渐渐调整并观察监控指标。
- 均衡后台任务和前台查询的资源占用。
- 磁盘 IO 或 CPU 瓶颈时，优先优化硬件或数据分布（如分区键设计）。
通过以上步骤，可有效优化 `background_pool_size` 提升 ClickHouse 后台任务处置惩罚效率。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告