【银河麒麟高级服务器操作系统实例】虚拟化平台系统服务中断现象分析及处理建议

本文主要是介绍【银河麒麟高级服务器操作系统实例】虚拟化平台系统服务中断现象分析及处理建议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

服务器环境以及配置

【机型】虚机

处理器：	Kunpeng-920
内存：	40G

【内核版本】

4.19.90-23.8.v2101.ky10.aarch64

【OS镜像版本】

银河麒麟操作系统 Kylin-Server-10-SP1-Release-Build20-20210518-arm64

【第三方软件】

智能运维系统、mysql数据集群

现象描述

环境描述：Cas虚拟化平台，三台运行智能运维系统和mysql数据库集群的，银河麒麟虚拟机跑在一台物理机上。

故障现象：反馈智能运维系统登录页面提示500。初步排查，发现虚机B系统日志显示在系统出现软中断，并持续15分钟时间。虚机C系统日志也有软中断报错，虚机A系统日志无21号日志，因此无法判断是否有软中断报错，影响智能运维系统服务中断。

现象分析

分析B虚机系统messages日志，可以看到，xxx开始输出“watchdog: BUG: soft lockup - CPU#29 stuck”软中断相关堆栈日志信息，持续到xxx停止输出，日志信息输出时间在15分钟左右。查看Call trace相关堆栈信息，主要集中在，调用smp_call_function_many+0x348/0x3a0这个函数过程中产生，如图1：

图1

分析C虚机系统messages日志，也有相关软中断堆栈信息输出，日志信息输出时间在5分钟左右。查看Call trace相关堆栈信息，同样集中在，调用smp_call_function_many+0x348/0x3a0这个函数过程中产生，如图2：

图2

进一步分析，smp_call_function_many这个call trace堆栈函数的功能和产生的原因。可知，它的功能是在多个CPU上执行一个函数，smp_call_function_many函数发生soft lockup的原因是CPU在一段时间内没有响应中断，可能是由于CPU卡住或者CPU负载过高导致的。

分别分析查看，故障时间段，虚拟机B和C，系统sar性能日志，可知，内存使用率不高，性能瓶颈，不在内存使用，如图3和图4：

图3 虚拟机B内存使用率

图4 虚拟机C内存使用率

分析CPU使用情况和系统负载，可知，故障时间段内，CPU使用率比较高，%system和%iowait占用高，说明CPU处理内核态执行进程时间较长，CPU用于等待I/O操作时间较长，硬盘存在IO性能瓶颈。系统负载也高。如图5-图8：

图5 虚拟机B CPU使用率

图6 虚拟机C CPU使用率

图7 虚拟机B 系统负载

图8 虚拟机C 系统负载

分析系统磁盘IO使用情况，可知，故障时间段内，dev8-0系统磁盘、dev8-16和dev8-32应用磁盘的await，每次IO请求消耗时间大，有异常。%util ，I/O请求占用的CPU百分高，IO处理慢。说明磁盘IO存在比较严重性能问题，会影响系统正常IO读写，如图9和图10：

图 9 虚拟机B 磁盘IO

图10 虚拟机C 磁盘IO

分析结果

综上，系统日志和系统性能分析情况，可见，系统产生软中断，是因为故障时间段内，系统负载高，导致CPU没有正常响应中断请求。系统软中断，不是导致智能运维系统中断的原因。从sar性能日志，分析的情况，可知，CPU使用率较高，系统负载高，iowait较高，%util和await较高，这些性能相关指标，分析下来基本都指向磁盘IO性能出现问题。

结合智能运维系统厂商的问题分析情况，出故障时间段虚拟机A/B/C三台机器均出现网络连通性问题。怀疑，故障时间段内，虚机系统的状态，有暂停或卡死的可能性。