有些规定从最终用户角度讲是完全合理的，但对系统开发和实施者却是无奈的，比如资源利用率。系统如果太空闲，那就是资源浪费，如果太繁忙，那就是业务性能不行或者评估错误。本文介绍一个因这类无奈的要求引发的一次GBase 8a性能异常。
目录导航
现象
2月18日，现场反馈某个关键业务这2天已经超过50%的比例无法按时完成。
排查
查看当前业务耗时
查看调度节点 show processlist，几十个业务SQL都在几百秒，包括一些LOAD加载入库任务，一个最长的insert select已经到1万秒。查看计算节点SQL，发现部分节点SQL出于flush commit阶段。
正常应在60秒以内，大部分10秒以内。
查看慢节点系统资源使用情况
查看SQL耗时最长的几个计算节点iostat，发现磁盘IO持续100%繁忙。查看其它计算节点，均会有少量时间空闲或者50-80%不等程度的繁忙，而不是持续100%繁忙。
查看慢节点历史资源使用情况
查看sar日志，发现从2月11日之前，磁盘基本出于10-50%短期繁忙，然后有接近30%的空闲。之后几天，繁忙程度和持续时间在不断增加，到2月16日已经出现了持续繁忙的现象。
查看SWAP，发现32G已经被使用完毕。而该机器有300GB+的物理内存。
查看慢节点磁盘使用情况
通过iotop,发现节点最大的磁盘读写吞吐量确实是gbased进程，在几十到几百MB/s，其它进程很小，在KB/s级别。
查看慢节点SWAP使用信息
通过TOP，查看各进程SWAP使用情况。发现gbased仅使用了几百MB，而有一个不属于数据库的进程XXX，使用了30G的SWAP，同时，该进程使用了180GB的物理内存。
分析
询问客户，反馈该进程是一个【背景】进程，部署在每个数据库节点上。该进程的用途只有一个，让系统繁忙起来，不能长时间空闲，包括cpu、内存、磁盘使用率不能持续太低。
这些服务器接入了云管理平台，如果使用率太低，则说明负载不足，硬件评估偏差大，资源浪费高，是要被问责的。
客户为了避免因这个被问责，就部署了这个【背景】进程，强行占用系统资源，避免资源利用过于空闲的情况发生。
处理
将【背景】进程停掉后，性能恢复正常。
总结
在纯云环境，需要的资源可以动态调整，但在本地物理机环境，不同时间系统负荷差异较大。比如周表，月表等。一天内也有闲时和忙时。而这个资源利用率标准的严格执行，导致了这个无奈的处理方案，并出现了本次性能异常的结果。