load average基础
top命令中load average显示的是最近1分钟、5分钟和15分钟的系统平均负载。
系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中:
- 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用’wait’)
- 没有被停止(例如:等待终止)
在Linux中,进程分为三种状态,一种是阻塞的进程blocked process,一种是可运行的进程runnable process,另外就是正在运行的进程running process。
进程可运行状态时,它处在一个运行队列run queue中,与其他可运行进程争夺CPU时间。 系统的load是指正在运行和准备好运行的进程的总数。比如现在系统有2个正在运行的进程,3个可运行进程,那么系统的load就是5。load average就是一定时间内的load数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的,如果每个CPU的任务数大于5,那么就表示这台机器的性能有严重问题。
CPU使用率高并不总是意味着CPU工作繁忙,它有可能是正在等待其他子系统。在进行性能分析时,将所有子系统当做一个整体来看是非常重要的,因为在子系统中可能会出现瀑布效应。衡量CPU 系统负载的指标是load,load 就是对计算机系统能够承担的多少负载的度量,简单的说是进程队列的长度。简单的例子比如食堂有五个窗口,当有小于五个学生来打饭,五个窗口都能及时处理,但是当学生个数超过5个,必然会出现等待的学生。请求大于当前的处理能力,会出现等待,引起load升高。
Load Average 就是一段时间(1min,5min,15min)内平均Load。平均负载的最佳值是1,这意味着每个进程都可以在一个完整的CPU 周期内完成。
问题现象
经反馈发现,虚机环境CentOS系统的CPU负载超过正常水平,并持续升高,经过一晚的时间,负载提升至1000+的水平。

环境信息
- 12c32G vCenter 虚机 * 3台
- 部署Kubernetes + OpenStack
问题定位
- 通过top查看各CPU使用率,发现CPU各核使用率并不高,说明CPU性能并不是导致拥塞的瓶颈。
1 | 查看CPU各核使用率 |

- 计算通常不会存在瓶颈,一般性能瓶颈出在IO处。接下来需要确认是否由于IO问题,导致拥塞,引起负载升高。
1 | IO监控命令 |
- 检测发现IO不存在瓶颈,推测可能程序有问题,未正常退出导致cpu load average异常升高。这里先寻找哪个进程有问题,命令如下:
1 | 查看所有线程 |
- 检查发现cephcsi线程数过多,且都处于S(休眠)状态,统计数量与load average一致,故load average升高由cephcsi线程未正常退出导致。

- 追踪定位cephcsi线程未正常退出原因,该线程为rook-ceph创建,提供cephfs服务,检查ceph状态。
1 | 查看ceph状态概况 |


- 发现cephfs异常,根据报错信息
1 mds daemon damaged从网上寻找到如下解决办法:
1 | ceph mds repaired 0 |
Ceph部分组件用途
- MDS:Ceph元数据服务器,跟踪文件层次结构并存储只供CephFS使用的元数据。Ceph块设备和RADOS网关不需要元数据。MDS不直接给client提供数据服务。
- CephFS:提供了一个任意大小且兼容POSlX的分布式文件系统。CephFS 依赖Ceph MDS 来跟踪文件层次结构,即元数据。
- CSI CephFS plugin:用来提供CephFS存储卷和挂载存储卷。
- cephfs问题修复后,重启相关pod,cpu load average问题未出现。

