锐捷S6000C-48GT4XS-E设备CPU高
关键字：
DCM翻转、长时间运行
一、故障现象描述
3月4日下午17点44分客户一组S6000C-48GT4XS-E集群出现CPU使用达到95%，该集群自2015-12-02 18:06:53启机后就一直运行至今。根据客户反馈，该现象已经出现了有一段时间。
二、故障排查分析
-
5号下午，在客户的大力协助下，我们在现场对设备信息进行了收集。收集后分析，确认高CPU的问题现象是使用了dcm库的五个进程中的dcm_lib线程不断的在刷写日志。
Process 2570 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
51.06 0.122933 860 143 fsync
18.49 0.044519 309 144 poll
17.34 0.041752 292 143 ftruncate
4.52 0.010883 76 143 write
4.15 0.010000 35 287 gettimeofday
4.15 0.010000 70 143 _llseek
0.28 0.000682 5 143 send
0.00 0.000000 0 144 recv
------ ----------- ----------- --------- --------- ----------------
100.00 0.240769 1290 total
~ # strace -cp2570
Process 2570 attached - interrupt to quit
Process 2570 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.010000 1429 7 poll
0.00 0.000000 0 7 write
0.00 0.000000 0 14 gettimeofday
0.00 0.000000 0 7 ftruncate
0.00 0.000000 0 7 fsync
0.00 0.000000 0 7 _llseek
0.00 0.000000 0 7 send
0.00 0.000000 0 7 recv
------ ----------- ----------- --------- --------- ----------------
100.00 0.010000 63 total
~ # strace -cp2550
Process 2550 attached - interrupt to quit
Process 2550 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.008115 4058 2 poll
0.00 0.000000 0 2 write
0.00 0.000000 0 4 gettimeofday
0.00 0.000000 0 2 ftruncate
0.00 0.000000 0 2 fsync
0.00 0.000000 0 2 _llseek
0.00 0.000000 0 4 futex
0.00 0.000000 0 2 send
0.00 0.000000 0 2 recv
------ ----------- ----------- --------- --------- ----------------
100.00 0.008115 22 total
-
Dcm库中符合上述函数的地方只有一处，刷新报文统计日志的地方。收集到的日志文件中也包含故障进程的报文统计日志：
-rwxrwxrwx 1 root root 1338 Mar 5 13:33 stat-cli-server-619-20151202-183819
-rwxrwxrwx 1 root root 1337 Mar 5 13:33 stat-rg-tty-admin-620-19700101-000010
-rwxrwxrwx 1 root root 3068 Mar 5 13:33 stat-ssa_process-1792-20151202-183820
-rwxrwxrwx 1 root root 3277 Mar 5 13:33 stat-ssc_process-1807-20151202-183821
-rwxrwxrwx 1 root root 3104 Mar 5 13:33 stat-ssd_process-1814-20151202-183819
该日志更新机制使用定时超时机制进行定时，在定时器超时后进行日志更新。每次定时的时间都应该在半小时以上，且会慢慢延长更新间隔，不会出现频繁更新的情况。由于故障设备出现频繁刷写日志的情况，因此判断为定时器超时时间设置出现了问题。
三、故障根因说明
通过内部走读代码分析，我司DCM模块软件计算存在时钟翻转的问题，被内核读取时直接被设置为了10737418220毫秒（124天），当运行1489天后，理论timeout翻转为0，故障出现，从而促发了DCM模块超时处理逻辑持续触发并执行刷写统计信息到flash存储芯片中，因此导致CPU增高。
四、故障解决方案
升级B774P1以及以上版本
五、故障总结
-
当故障发生时，CPU会增高，同时刷写数据会降低flash寿命，根据当前S6000C-48GT4XS-E产品信息，设备将在227.8天后出现flash存储芯片不可写的情况，大概率导致设备无法继续运行。
-
补充故障涉及到的设备型号如下：
S6120系列、 S6100系列、 S6200系列、 S57H系列、 S6000C系列
S2910系列、 S29V3系列、 S1960系列、 DS5730系列、 NBS5710系列、 NBS5750系列
阅读剩余
版权声明：
作者：SE_You
链接：https://www.cnesa.cn/4074.html
文章版权归作者所有，未经允许请勿转载。
THE END
