Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1431
  • 博文数量: 1
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 20
  • 用 户 组: 普通用户
  • 注册时间: 2019-03-13 18:49
文章分类
文章存档

2019年(1)

我的朋友
最近访客

分类: C#/.net

2019-03-20 15:40:38

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 19.0px; font: 13.0px 'Helvetica Neue'; color: #000000} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 19.0px; font: 13.0px 'Helvetica Neue'; color: #000000; min-height: 15.0px} p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 19.0px; font: 13.0px 'Helvetica Neue'; color: #00a2ff} span.s1 {color: #000000} span.s2 {color: #00a2ff}

## **记AELF区块链网络的一次内存持续增长问题排查**


背景:测试同学运行AElf单节点过程中,发现节点突然不再出块,经查看日志发现 Worker(交易执行进程) 全部掉线,无法继续执行交易,从而导致节点挂掉。


aelf的GitHub链接:


初步定位问题:出现这个问题很奇怪,因为节点和所有 Worker 在同一台服务器上,网络通信应该不会有问题,再者发现,主节点、所有 Woker 和 Lighthouse 几乎在同一时间全部掉线。然后继续排查,通过 zabbix监控找到了问题,服务器在一个时间点内存几乎被耗尽,通过观察时间,发现与节点出现异常时间吻合。


复现问题:我们重点对内存使用进行测试。测试发现,随着节点长时间运行,进程占用服务器内存在不断增加,尤其在持续发了大量交易后,内存使用增长明显,并且停止发交易后,内存也并不会下降。


下面是具体的复现步骤:

首先介绍服务环境,我们使用Ubuntu 16.04.5 LTS,dotnet core 版本为2.1.402


节点刚开始运行的情况:内存使用大约为90M

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145333766.png)

然后对节点持续发大量交易,我们可以通过监控看到节点交易池堆积大量交易并不断在执行


![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145444758.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

持续一段时间后,内存占用已经达到1G


![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145521141.png)

此时停止发交易,等待交易执行,我们通过监控看到交易池中的交易已都被执行。


![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145601669.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

等待一段时间后,此时我们继续观察内存占用,发现内存使用还是不会减少,一直保持1G 的水平


 


 


分析问题:


接下来我们使用lldb分析我们的节点。


 


首先在服务器上安装 lldb


sudo apt-get install lldb


找到本机位置


find /usr -name


启动 lldb并附加到进程


sudo lldb –p 13067


加载


plugin load /usr/share/dotnet/shared/


setclrpath /usr/share/dotnet/shared/   


首先分析下对象


dumpheap -stat

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145711396.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

我们可以看到有大量的以下对象


AElf.Kernel.TransactionHolder


System.String


AElf.Common.Address


System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash,AElf.Common],[AElf.Kernel.TransactionHolder,AElf.Kernel.TxHub]]


AElf.Kernel.Transaction


AElf.Common.Hash


Google.Protobuf.ByteString


System.Byte[]


 


我们再看下大于1024字节对象

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145749754.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

可以看有4个对象同类型的对象比较大


System.Collections.Concurrent.ConcurrentDictionary`2+Node[[AElf.Common.Hash, AElf.Common],[AElf.Kernel.TransactionHolder, AElf.Kernel.TxHub]][]


 


再进一步查看MethodTable对应的对象

![在这里插入图片描述](https://img-blog.csdnimg.cn/2019032014581485.png)

可以看到有8个对象,其中4个较大,挑选其中一个查看对象信息,发现里面存储了573437个值。


![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145853835.png)

基于以上分析结果,排查对应源代码,定位到类:AElf.Kernel.TxHub。该类主要作用是存储交易池交易数据。该类包含8个ConcurrentDictionary用于存储交易数据,而TransactionHolder类中有存储了Hash、Transaction 等类型,与上面内存分析的结果吻合。再继续看内部逻辑,发现所有交易进入交易池后一直存储在TxHub中,不再进行释放。到此为止基本上定位问题所在。


 


待问题修复后重复上面步骤进行验证,效果比较明显,待交易池交易执行完毕后,内存占用有明显下降,最终内存占用如下

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190320145923973.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

继续看下内存中对象的情况,可以看到对象总数也有了明显的下降。


![在这里插入图片描述](https://img-blog.csdnimg.cn/2019032014595596.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,代写论文、pos_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RvMmJldHRlcg==,size_16,color_FFFFFF,t_70)

但是仍存在内存少量增长的现象,并且有大对象驻留内存的情况,此问题会进一步跟进分析。

阅读(569) | 评论(0) | 转发(0) |
0

上一篇:没有了

下一篇:没有了

给主人留下些什么吧!~~