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"?src="https://miro.medium.com/max/964/0*KSFKadBeRExUlkA6" 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" src="https://miro.medium.com/max/1484/1*BUBXxboSlBArnNSfLo4KDw.png" 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" src="https://miro.medium.com/max/1484/1*KydRE8pnP0G5-3s5h9KVSw.png" 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" src="https://miro.medium.com/max/2156/1*pKdGJgwuIBTPgAjBH_JLNQ.png" 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" src="https://miro.medium.com/max/2156/1*0VudYV4vE8HnwT0bXF6CiQ.png" 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的话，会耗损很是大的内存。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
