问题背景 #

我们的监控服务器CPU使用率间歇性达到100%，导致渲染Grafana仪表板时频繁出现**"Internal server error"**错误。当前机器仅运行Docker及三个子容器：cadvisor、graphite、grafana。

机器规格详情 #

• 操作系统版本：Ubuntu 16.04 LTS Release 16.04 (xenial)
• 内核版本：4.4.0-103-generic
• Docker版本：17.09.0-ce
• CPU：4核
• 内存：4096 MB（注：已将内存从4GB提升至更高配置，但CPU高使用率问题仍未解决）
• 网络适配器：mgnt
• 存储驱动：overlay2，底层文件系统extfs，支持d_type，Native Overlay Diff为true
• 内存交换限制：2.00GB

关键观察 #

从cAdvisor获取的进程片段显示：kworker和ksoftirqd进程状态持续从'D'（不可中断睡眠）切换至'R'（运行中）再到'S'（可中断睡眠）。

咨询问题 #

1. 当前机器规格是否适配当前的Docker容器部署？
2. 如何将CPU使用率降至正常水平，解决Grafana仪表板报错问题？

问题分析与解决方案 #

针对你遇到的问题，结合你的环境信息和观察到的内核进程波动，我整理了以下分析和实操方案：

一、机器规格适配性判断 #

4核CPU + 已升级的内存配置，对于仅运行cadvisor、graphite、grafana这三个监控容器的场景来说，理论上是完全足够的。出现CPU间歇性拉满的情况，并非硬件规格不够，而是存在内核调度、容器资源抢占或监控组件配置的瓶颈点。

二、CPU使用率优化步骤 #

1. 定位CPU高负载的具体来源

首先得搞清楚到底是哪个进程或容器在抢占CPU资源：

• 当CPU达到100%时，用top -H查看线程级别的占用情况，重点关注kworker/ksoftirqd对应的线程，以及三个容器的进程；
• 用docker stats实时监控容器的CPU使用率，看是否有某个容器（比如Graphite在处理大查询时）瞬间拉满CPU；
• 用iostat -x 1检查磁盘I/O负载，如果%util接近100%，说明磁盘I/O等待导致kworker频繁处理I/O队列，间接拉高CPU。

2. 给Docker容器设置资源限制

即使机器总资源足够，未限制容器的CPU使用可能导致单个容器抢占所有核心：

• 给每个容器设置CPU配额和调度权重，比如给Grafana和Graphite分配合理的资源（避免无限制抢占）：

  # 修改docker run命令（以Grafana为例）
  docker run -d --name grafana --cpus="1.5" --cpu-shares=1024 grafana/grafana
  

  • --cpus：限制容器最多使用的CPU核心数（比如1.5核，根据实际负载调整）
  • --cpu-shares：设置CPU调度优先级（值越高，在资源竞争时获得的CPU越多）

3. 优化Graphite的查询与存储配置

Graphite是监控场景中最容易出现CPU瓶颈的组件，尤其是查询大量历史数据时：

• 调整storage-schemas.conf，优化数据保留策略，比如缩短低频指标的存储周期，减少不必要的数据计算；
• 限制Grafana仪表板的默认查询时间范围，避免用户一次性查询几天甚至几周的全量数据；
• 开启Graphite的内存缓存，减少重复查询的计算开销。

4. 升级内核与Docker版本

你当前使用的内核（4.4.0-103）和Docker（17.09.0-ce）版本都比较老旧，存在已知的overlay2驱动、内核调度相关的bug：

• 升级Ubuntu 16.04的内核到官方支持的最新稳定版本（比如4.4.0-210-generic），修复内核层面的进程调度问题；
• 升级Docker到兼容Ubuntu 16.04的LTS版本（比如19.03.x系列），优化容器的资源隔离和调度逻辑。

5. 降低cAdvisor的采集频率

cAdvisor默认的采集频率（10秒一次）可能过高，频繁的指标采集会占用主机CPU：

• 修改cAdvisor的启动参数，设置--housekeeping_interval=30s，降低采集频率，减少资源消耗。

三、总结 #

当前机器规格完全适配你的部署需求，问题出在资源调度和组件配置层面。建议按「定位负载来源→限制容器资源→优化Graphite配置→升级软件版本」的顺序逐步排查优化，应该能有效解决CPU间歇性拉满和Grafana报错的问题。

内容的提问来源于stack exchange，提问作者gpullen