首页 > 系统相关 >Exadata存储节点大量nvmecli进程,导致系统出现卡顿现象

Exadata存储节点大量nvmecli进程,导致系统出现卡顿现象

时间:2023-11-21 21:26:09浏览次数:34  
标签:存储 09 -- 导致系统 nvmecli 节点 2023 Exadata 08

1、故障概要

同事在执行Exadata巡检时,发现客户Exadata环境中的celadm01存储节点存在卡顿的现象。相同的命令,在其他的存储节点很快就返回输出结果,而celadm01这台存储节点需要很长时间才返回输出结果。

 

2、故障分析

(1). 检查主机负载情况。发现celadm01这台存储节点的负载(load average)高达几万,远远高于其他几台存储节点。

 

(2). 同事在该存储节点执行了top命令,未发现有异常进程独占CPU的情况,但发现该存储节点的进程数高达3万多,真正running的进程只有几个,剩余的进程基本上都处于sleeping状态,具体如下所示。

top - 06:56:56 up 594 days, 10:46,  1 user,  load average: 27093.61, 27092.08, 27086.28

Threads: 31029 total,   3 running, 30797 sleeping,   0 stopped,   0 zombie

%Cpu(s):  5.0 us,  4.2 sy,  0.0 ni, 90.1 id,  0.0 wa,  0.6 hi,  0.0 si,  0.0 st

KiB Mem : 13148553+total, 43384912 free, 64332044 used, 23768580 buff/cache

KiB Swap:  2097084 total,  2097084 free,        0 used. 61548536 avail Mem

正常情况下,存储节点的进程数应该在1000个左右,当前这台存储节点上的进程数已经远远超过正常范围。

 

(3). 分析ps命令输出,发现如下类似的进程占绝大多数,具体如下所示。

 

 

可以看出,当前主机上存在大量的进程正在执行nvmecli --identify --device=/dev/nvme3n1 --detail命令,从这个命令可以推测系统想获取/dev/nvme3n1这块闪存的信息,但这块闪存很可能出现了硬件故障,导致无法获取相关的信息,所以nvmecli命令一直卡着。最终,导致主机上的进程越来越多。

 

(4). 从目前的情况来看,celadm01存储节点已经异常,建议重启该节点的存储服务,但同事在关闭存储服务时,该存储节点的主机自动重启了。

2023-10-27T17:27:48+08:00  critical "CELLSRV shutdown failure. Cell was power cycled."

主机自动重启后,该存储节点恢复正常。

 

(5). 查看存储软件的日志。

     2_1      2023-09-22T14:08:30+08:00  critical "Flash disk entered confinement offline status. ....

     2_2      2023-09-22T14:08:34+08:00  critical "Flash disk entered poor performance status. ....

     2_3      2023-09-23T02:28:16+08:00  critical "Flash disk failed.  Status        : FAILED  ...

     3_1      2023-09-22T14:17:49+08:00  warning  " Processes may be in an uninterruptible sleep (D) state......

     3_2      2023-09-23T02:21:50+08:00  info     " The following processes may be in an uninterruptible sleep (D) state:   Command  kworker/u80:0    Tree     PID  PPID  Command    18859

     3_3      2023-09-23T02:22:50+08:00  info     " The following processes may be in an uninterruptible sleep (D) state:   Command  /usr/lib/systemd/systemd-udevd     Tree     PID  PPID

     3_4      2023-09-23T02:23:50+08:00  info     " The following processes may be in an uninterruptible sleep (D) state:   Command  nvmecli --identify --device=/dev/nvme3n1 --detail   

     3_5      2023-09-23T02:24:50+08:00  info     " The following processes may be in an uninterruptible sleep (D) state:   Command  nvmecli --identify --device=/dev/nvme3n1 --detail   

     3_6      2023-09-23T02:25:50+08:00  info     " The following processes may be in an uninterruptible sleep (D) state:   Command  nvmecli --identify --device=/dev/nvme3n1 --detail   

从存储软件的日志可以看出:

2023-09-22T14:08分,有一块闪存出现故障,进入poor performance状态,9分钟后,有一个进程进入D状态,这个进程很可能就是检测闪存信息的nvmecli命令。

2023-09-23T02:21开始,又出现多个进程进入D状态,这些进程中有多个进程是执行nvmecli命令检测闪存信息。最终,在2023-09-23T02:28分,闪存进入FAILED状态。

 

 

3、建议

个人认为这应该是存储软件的一个BUG,既然存储软件识别出这块闪存已经出现故障,就不应该再生出这么多检测闪存状态的进程。但搜索MOS资料库,未找到已知的BUG,建议升级存储软件。

 

标签:存储,09,--,导致系统,nvmecli,节点,2023,Exadata,08
From: https://www.cnblogs.com/missyou-shiyh/p/17847632.html

相关文章