请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

  思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 431|回复: 7

Memory issue summary

[复制链接]
发表于 2018-11-18 15:22:55 | 显示全部楼层 |阅读模式
本帖最后由 guangxil 于 2018-11-20 13:55 编辑

周五关闭了一个H3C开的关于Memory的case。正好借此机会简单总结一下Memory的问题,已经排查故障的简单步骤。

首先Memory的问题简单分为如下几类:
a、High Memory/Memory Leak
b、Memory fragmentation
c、Memory Error log
d、Hardware Issue


A、对于High Memory,客户看到Memory使用率达到80%~90%通常就会开case说自己的设备有High Memory的问题,请求排查。
           对于这类问题,首先要分为两部分去看。第一类是客户购买设备时自身选择的内存就比较小,所以有比较高的使用率是很正常的情况。所以这时候要询问客户这个内存时从什么时候就开始有比较高使用率。第二类就是内存的使用率从一开始比较低慢慢涨到比较高的使用率。

对于第一类,通常比较高的使用率就是正常的,大部分内存被两个进程所占用,一个是*Init*,另一个是*dead*

E.g.
------------------ show processmemory -----------------
Processor Pool Total: 1580036448Used: 1302478048 Free:  277558400
I/O Pool Total:  321912832 Used:   54958272 Free:  266954560

PID TTY  Allocated     Freed    Holding    Getbufs   Retbufs Process
   0   0 1498873556 175420576 1270929668     30244   58140545 *Init*

对这两个进程进行简单的解释一下。
*Init*进占用的情况是在设备启动的时候就确定了,它与我们的配置和使用的feature相关。Feature用的越多,它占用的资源越多。
*dead*进程占用很多资源。这个通常也不是一个问题:他并不是一个实际的进程,是统计其他进程使用完准备回收的memory
关于这个进程的更多内容可以在www.cisco.com搜索Cisco IOS Software Releases,文档中有比较详细的介绍。
总结:遇到这样的问题,我们主要关注在它现在应用,memory利用率的baseline可能就是现在这样,我们可以通过对比其他类似设备的memory利用情况来说明这一点。


对于第二类,这个High Memory就是通常说的Memory leak了。基本的排查手段可以使用两次show process memory对比来简单确定。对比来找到Holding的内存资源比较多,并且增长比较快的进程。
E.g.

In Jun 30th
------------------ show processmemory ------------------
Total: 237265920, Used: 83551124,Free: 153714796
PID TTY Allocated      Freed    Holding   Getbufs    Retbufs Process
  0   0      84280       1848  10965984          0          0 *Init*         
  0   0       1024  53426952       1024          0          0 *Sched*         
  0   0 1740233508 1704409220      15968   5536148          0 *Dead*
92   0  592203404 2245984752   63439220  24457292   23857704 SNASwitch  


In Aug 8th
R0005_7507CIPApp#sh proc m
Total: 237265920, Used: 216038080,Free: 21227840
PID TTY Allocated      Freed    Holding   Getbufs    Retbufs Process
  0   0      84280       1848  10965984          0          0 *Init*
  0   0       1024  54390360       1024          0          0 *Sched*
  0   0 1930898652 1894688808      16224   5536148          0 *Dead
92   0 2617671252 3446440932  189007408  38669748   32208952 SNA Switch

这个我们就能找到问题的根源进程。找到这个进程如果自己不知道下一步该如果处理,可以联系TAC帮忙协助。


在有些情况下,我们不太方便作对比的时候,我们看见某些进程holding的memory明显很高。E.g.

------------------ show processmemory ------------------
Processor Pool Total:  181720432 Used:  181023936 Free:     696496      
I/O Pool Total:   37748224 Used:   10388928 Free:   27359296  
PID TTY Allocated      Freed    Holding   Getbufs    Retbufs Process
  0   0   41942944  10068384   28183916          0          0 *Init*         
   0   0      77640    122252      77640          0          0 *Sched*         
  0   0     447772   2631464      93080     178568    178568 *Dead*        
   1  0  161145148    1778856 159440664          0        0Chunk Manager

这里chunk Manager进程自己就占了80-90% Processor memory的资源这一定是不正常的。

B、Memory fragmentation的问题。
内存分片或者减内存碎片,他的意思是我们内存中有很多剩余资源(free中的数值),但是可用的最大内存比较小(largest中的数值)通过show memory statistics来观察。内存分片本身是不可避免的,free和largest的数值在一个数量级上差别不大就不是什么问题,但如果他们查了一个数量级,那么就是我们关心的内存分片的问题了。

E.g.


------------------ show memorystatistics ------------------

         Head   Total(b)     Used(b)     Free(b)  Lowest(b)  Largest(b)

Processor  22A1CE0  85685024  32175212    53509812    51268036   51253856

  I/O    7400000   12574720  8442784     4131936     3437736    4061760

上面差别不大,没有问题。

#sh mem              

Head    Total(b)    Used(b)     Free(b)   Lowest(b) Largest(b)

Processor  43FE59A0 188851808   24544280  164307528     675236    3628224

     I/O 3F400000   12582912    8312444   4270468       7904      961052


这种情况就是我们关心的内存碎片问题,原因为Bug#CSCsd97829。

其实在实际做case中真正由于内存碎片而导致问题的case很少,有很多case中 log虽然报了Cause: Memory fragmentation但是fragmentation并不是主因,而主因是memory leak。
C、Memory Error log问题

这种情况并不是一个单独的导致问题的成因,通常是伴随前两种情况的”附属品”。还有就是这种情况通常也会有traceback值。Traceback是查找问题原因最重要的一个信息,这样的问题只能联系TAC协助处理了。
D、Hardware issue对于硬件的问题大家应该都知道怎么处理,暂不介绍了。
对于上面有任何不足的地方,敬请留言指正和补充。谢谢。部分总结来自DL的同事,感谢同事的干货分享!
感谢!





  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
 楼主| 发表于 2018-11-18 15:26:42 | 显示全部楼层
下周如果有时间就简单summary一下另一个比较常见的High CPU的问题。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2018-11-18 18:35:41 | 显示全部楼层
  学习了,谢谢楼主分享,等着继续学习。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
 楼主| 发表于 2018-11-19 00:28:13 | 显示全部楼层
cpmld-199 发表于 2018-11-18 18:35
学习了,谢谢楼主分享,等着继续学习。

谢谢关注,但愿下周末不太忙
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2018-11-19 08:47:52 | 显示全部楼层
学习了     。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2018-11-19 10:05:12 | 显示全部楼层
guangxil 发表于 2018-11-18 15:26
下周如果有时间就简单summary一下另一个比较常见的High CPU的问题。

学习学习,之前遇到3750CPU每过一周就会彪掉99%,没法用,只能重启,虽然网上有人有这问题也解决了,但好像对我这不实用,
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2018-11-20 13:37:43 | 显示全部楼层
Great sharing!
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2018-11-20 20:11:58 | 显示全部楼层
THANK YOU FOR SHARE !  学习了

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2018-12-12 18:37 , Processed in 0.103171 second(s), 48 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表