TechatKlaytn技术系列：确认产生Cache问题的原因

Klaytn State Trie Cache Series #1:?确认产生Cache问题的原因

Klaytn为了提高区块链平台的性能，做了许多方面的努力。我们将通过下列文章介绍 state trie cache性能改善过程。

??确认Cache问题的原因

??寻找最佳的Cache

??计算State trie cache miss

??进行?Cache Size Tuning

本篇将介绍进行Klaytn有关测试时出现的问题以及这些问题的来源-Go语言GC(Garbage Collector)。在进行Klaytn有关测试时，出现了下列问题。

<img alt="Image for post" class="t u v hy aj"?src="https://miro.medium.com/max/964/0*KSFKadBeRExUlkA6" width="482" height="321" srcSet="https://miro.medium.com/max/552/0*KSFKadBeRExUlkA6 276w, https://miro.medium.com/max/964/0*KSFKadBeRExUlkA6 482w" sizes="482px"/>

利用Prometheus提供的API测试内存使用量

在Klaytn binary中，以3500 TPS处理transaction时，大约需要用到100G的内存。我们为了确认具体是哪里在消耗大量内存，利用 Go语言所提供的内存分析工具，进行了确认。

??go tool pprof cn-mem0.prof

File: kcn

Build ID: 7b45b11c163a99518095ffb64083e4aa61fd321f

Type: inuse_space

Time: Mar 26, 2020 at 8:56am (KST)

Entering interactive mode (type "help" for commands, "o" for options)

(pprof) top

Showing nodes accounting for 41.91GB, 96.33% of 43.50GB total

Dropped 382 nodes (cum <= 0.22GB)

Showing top 10 nodes out of 77

flat flat% sum% cum cum%

30GB 68.97% 68.97% 30GB 68.97% github.com/allegro/bigcache/queue.NewBytesQueue

5.65GB 12.98% 81.95% 5.65GB 12.99% github.com/allegro/bigcache.(*cacheShard).set

1.53GB 3.52% 85.47% 1.53GB 3.52% reflect.New

1.25GB 2.87% 88.35% 2.60GB 5.97% github.com/klaytn/klaytn/ser/rlp.decodeBigInt

通过内存分析工具，我们可以看到每个部分所消耗的内存。在上述结果中，可以通过?Showing nodes accounting for 41.91GB, 96.33% of 43.50GB total看到kcn binary占了43.5GB，还可以看到其中的96.33%，即41.91GB具体用在哪里。不仅如此，通过30GB 68.97% github.com/allegro/bigcache/queue.NewBytesQueue，可以看到有30GB(68.97%)用于bigcache上。

这两个测试结果中，我们发现了问题。根据Prometheus所提供的内存使用library，kcn大约占了100GB，但内存分析结果(43.50GB total)表明，kcn binary只占了43.5GB。我们无法确认其余56.5GB(=100GB - 43.5GB)的内存去了哪里。

于是我们猜测应该是Bigcache占据了大部分内存。为了确认Bigcache是否占据了内存，我们在相同环境的2台服务器上设置了不同的cache size进行测试，设置分别为30GB和0GB。2台服务器的top和内存分析结果如下。

(Top命令结果是GiB，Prometheus所提供的library的结果是GB，两者为相同的量)

Cypress sync test

AWS Instance : m5.8xlarge

memory size: 128G

cache size: 30G, 0G

<img alt="Image for post" class="t u v hy aj" src="https://miro.medium.com/max/1484/1*BUBXxboSlBArnNSfLo4KDw.png" width="742" height="366" srcSet="https://miro.medium.com/max/552/1*BUBXxboSlBArnNSfLo4KDw.png 276w, https://miro.medium.com/max/1000/1*BUBXxboSlBArnNSfLo4KDw.png 500w" sizes="500px"/>

<img alt="Image for post" class="t u v hy aj" src="https://miro.medium.com/max/1484/1*KydRE8pnP0G5-3s5h9KVSw.png" width="742" height="366" srcSet="https://miro.medium.com/max/552/1*KydRE8pnP0G5-3s5h9KVSw.png 276w, https://miro.medium.com/max/1000/1*KydRE8pnP0G5-3s5h9KVSw.png 500w" sizes="500px"/>

top命令结果(左：cache 30G；右：cache 0GB)

<img alt="Image for post" class="t u v hy aj" src="https://miro.medium.com/max/2156/1*pKdGJgwuIBTPgAjBH_JLNQ.png" width="1078" height="564" srcSet="https://miro.medium.com/max/552/1*pKdGJgwuIBTPgAjBH_JLNQ.png 276w, https://miro.medium.com/max/1000/1*pKdGJgwuIBTPgAjBH_JLNQ.png 500w" sizes="500px"/>

<img alt="Image for post" class="t u v hy aj" src="https://miro.medium.com/max/2156/1*0VudYV4vE8HnwT0bXF6CiQ.png" width="1078" height="564" srcSet="https://miro.medium.com/max/552/1*0VudYV4vE8HnwT0bXF6CiQ.png 276w, https://miro.medium.com/max/1000/1*0VudYV4vE8HnwT0bXF6CiQ.png 500w" sizes="500px"/>

Go Memory Profiling结果(左：cache 30G；右：cache 0GB)

我们可以看到，被分配Bigcache的服务器其Top和内存分析结果中内存使用量分别为70GB和35GB，有35GB的内存追踪不到。而没有分配Bigcache的服务器其 Top和内存分析结果中内存使用量分别为5GB和2GB，有3GB 的内存追踪不到。

通过以上测试，我们可以推断，若使用Bigcache，会占用大于分配额的内存。而就算不使用Bigcache，也会出现3GB左右的遗漏。当然，GC(Garbage Collector)的运作，可能令不管使用什么样的Go程序都有机会出现内存分析结果和实际使用量的误差。

而且，我们通过这篇文章可以得知，长时间占据大量的heap内存，并在分配时使用pointer的话，会消耗非常大的内存。

<img alt="Image for post" class="t u v hy aj" src="https://miro.medium.com/max/3200/0*E7gDbvMeS8E_YPgO" width="1600" height="572" srcSet="https://miro.medium.com/max/552/0*E7gDbvMeS8E_YPgO 276w, https://miro.medium.com/max/1104/0*E7gDbvMeS8E_YPgO 552w, https://miro.medium.com/max/1280/0*E7gDbvMeS8E_YPgO 640w, https://miro.medium.com/max/1400/0*E7gDbvMeS8E_YPgO 700w" sizes="700px"/>

GC(Garbage Collector)可寻找程序动态分配的内存中不再运作的部分，收回该部分的内存并分配给其他区域。为此，Go语言的GC(Garbage Collector)会对没有运作的区域进行确认，看是否被分配了内存。这时，用于确认的标志就是pointer，如果某个区域有很多pointer或占据了大量内存，GC在搜查过程中会消耗较大内存。

话句话说，在运行GC(Garbage Collector)之前，内存使用量为44GB，一旦开始运行，内存使用量就会增加100GB。再加上进行内存分析的时间刚好在GC完成运转后，所以只看到了运转前的内存使用量，即44GB。由于Klaytn分配的Bigcache量很大，所以GC一直在消耗更多的内存。

这类情况会导致系统突然出现内存不足的情况。因为Klaytn需要长时间运转，必须避免由于占用过多内存导致系统突然崩溃的情况。在下一篇文章内，我们将会介绍解决该内存遗漏问题的过程。

关于Klaytn

项目名称: Klaytn

英文缩写: KLAY

官方网站: https://www.klaytn.com/

项目简介：Klaytn是以服务为中心的企业级分布式信任区块链平台，通过高效的“混合”设计，结合了公有链（分布式数据和控制、分布式治理）和私有链（低延迟、高可扩展性）的最优功能。Klaytn与全球众多知名品牌的参与合作，通过共同的不懈努力，创建可靠的去中心化业务平台。Klaytn治理委员会是一个由跨国企业和组织组成的联盟，负责运营共识节点网络，推动生态系统发展。Kakao 的区块链开发部门「Ground X」已正式推出 Klaytn，并可用于商业用途。

—-

编译者/作者：Klaytn爱好者

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。