Klaytn State Trie Cache Series #4: Tuning Cache Size
See the list of articles here.
🇰🇷: Klaytn State Trie Cache Series #4: Cache Size Tuning 하기
Klaytn has been putting a lot of effort to improve the performance of our blockchain platform. In this series of articles, we want to walk you through the process of enhancing state trie cache performance.
- Identifying the Cache Problem
- Searching for the Optimal Cache
- Calculating state trie cache misses
- Tuning Cache Size
In our last post, we tested our hypothesis that the factors that influence cache misses are the changing state trie size (TotalAccounts, ActiveAccounts, TPS, trie node size) and cache size. But finding the optimal cache size by figuring out the changing state trie size requires a lot of research, so a more viable way to decrease cache misses was to find the optimal cache size for a given physical memory. In this article, we will take a look at how the optimal cache size can be found.
The following table shows the result for Fastcache before tuning, where it has the same cache size as Bigcache, and after tuning, with a bigger cache size to have a similar amount of free memory. After the experimentation, we found the proper cache size of Fastcache that has a similar amount of free memory as Bigcache. We then applied the proper cache size to after tuning.
Cache size is a selected value, whereas used memory and free memory are testing results.
After the above test, the physical memory was scaled based on the size of the Fastcache and the cache size was automatically allocated. Here is the algorithm for the said scaling:
if physicalMemMB < 20 * 1024 {
cacheSizeMB := 1 * 1024
} else if physicalMemMB < 100 * 1024 {
cacheSizeMB := physicalMemMB * 0.3
} else {
cacheSizeMB := physicalMemMB * 0.35
}In order to secure 10GB of free memory for memory sizes less than 20GB, we fixed the cache size to 1GB. For memories over 20GB and less than 100GB, 30% of the physical memory is being allocated, and there are about 10GB of free space for m5.2xlarge. For memories over 100GB, 35% of the physical memory is being allocated, and there are about 44.5GB of free space for c5.18xlarge.
The above test has been conducted with a lot of accounts and transactions, so it can still function with more memory allocations. But calling an API or a contract can lead to increased memory usage. So we ensured there was sufficient space in order to prevent OOM.
[Note] The server requirement for Klaytn is m5.2xlarge.
If we allocate cache size to Fastcache through the scaling logic, Fastcache size will be alloted as shown in the table above. The values shown in the table are based on an adequate number of TPS and accounts, so actual memory usage may be smaller than the above result. Increasing Fastcache size with the Klaytn Execution flag is also possible for a faster and more stable performance, but do keep in mind that OOM can occur.
In the Klaytn State Trie Cache Series, we demonstrated how we can improve the performance of state trie cache. We identified the problem with Klaytn’s existing cache and looked for an alternative. We also analyzed and verified the causes of cache misses of state trie cache and employed cache size tuning to find an adequate cache size for given physical memory.
This post is the last of the State Trie Cache series. If you have any further questions, leave them in the comment section below or post them in the Klaytn Forum. Thank you for reading and stay tuned!
