Geth磁盘和内存性能分析

Question

一周前，我使用以下参数开始了geth节点的同步：

--fast --cache=1024 --rpc --rpcaddr "0.0.0.0" --ws --wsaddr "0.0.0.0" --wsorigins="*"

我所得到的结果是，在运行一周后，它已经花费了69.9049 GB。快速同步总共需要39.1735 GB (更多关于ChainData尺寸增长w/快同步的信息)，所以正常使用geth一周需要30.7314 GB。

本表显示了磁盘上特定点上空闲空间的演变情况：

| DATE          | SIZE(GB)    | DIFF (GB)   |
|---------------|-------------|-------------|
| 27/12/17 8:30 | 93.23209763 |             |
| 28/12/17 8:30 | 46.39630127 | 46.83579636 |
| 29/12/17 8:30 | 41.57238007 | 4.823921204 |
| 30/12/17 8:30 | 36.69866943 | 4.873710632 |
| 31/12/17 8:30 | 31.91919327 | 4.779476166 |
| 1/1/18 8:30   | 27.54598618 | 4.373207092 |
| 2/1/18 8:30   | 25.38702011 | 2.158966064 |
| 3/1/18 8:30   | 23.32711411 | 2.059906006 |

这是进化的图表：

使用这些结果~3GB/天(~90 3GB/月)，在VPS中保持生产节点的同步似乎非常困难，而不需要执行重新同步化来清理空间或在磁盘空间中花费大量资金。

你和我有相似的结果吗？

你知道有没有优化它的方法吗？

geth计划优化这种行为吗？

更新#1:

关于Geth的行为，佩特·斯齐拉吉评论了以下关于“走样”的问题：为什么我的链数据大小高达400向上？

在初始同步之后，Geth切换到“完全同步”，在这里，继续点的所有历史状态形式都被保留。如果重新同步，则只下载最新的状态。带区块链数据的最新状态值约为50 is，但由于还没有状态修剪，在同步之后，数据就会不断积累。

更新2：

目前，我在与最近的块同步时遇到了问题。由于最近几天交易数量的增加，业绩似乎恶化了。运行一个小时后，它只导入了228个块：

chain_1  | INFO [01-09|10:05:48] Imported new chain segment               blocks=1 txs=256 mgas=7.973 elapsed=15.996s mgasps=0.498 number=4852965 hash=219fed…eed6cc
chain_1  | INFO [01-09|11:05:54] Imported new chain segment               blocks=1 txs=338 mgas=7.993  elapsed=28.800s mgasps=0.278 number=4853193 hash=44e3bd…1bb02f

假设每15秒大约生成一个新块。涉及每小时生成240个块，这意味着每小时节点将落后于网络12个块。

我认为问题是因为缺少ram，因为它正在使用整个系统ram加上3.00GB的交换

作为一个结论，似乎现在一个VPS的两个处理器在2.2GHz和4GB的RAM似乎不足以让一个节点与geth同步运行在一个坞内。

有没有人经历过类似的行为？

你也有同样的问题吗？

注:节点的详细特征：

Digital Ocean droplet:

# cat /proc/cpuinfo | grep "processor\|model name"
processor   : 0
model name  : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
processor   : 1
model name  : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz

# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.9G        3.7G        112M        108K         85M         26M
Swap:          8.0G        3.7G        4.3G

# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

# df -klh | grep "^/dev/"
/dev/vda1        58G   18G   41G  31% /
/dev/vda15      105M  3.4M  102M   4% /boot/efi
/dev/sda         99G   83G   12G  89% /mnt/mounted-drive

# docker version
Client:
 Version:   17.12.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    c97c6d6
 Built: Wed Dec 27 20:11:19 2017
 OS/Arch:   linux/amd64

Server:
 Engine:
  Version:  17.12.0-ce
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   c97c6d6
  Built:    Wed Dec 27 20:09:53 2017
  OS/Arch:  linux/amd64
  Experimental: false

# docker ps | grep geth
f9cdb05cd876        ethereum/client-go:v1.7.3   "geth --fast --cache…"   2 hours ago         Up 2 hours          0.0.0.0:8545-8546->8545-8546/tcp, 0.0.0.0:30303->30303/tcp, 30303-30304/udp   installpath_chain_1

    command:
      --fast --cache=1024 --rpc --rpcaddr "0.0.0.0" --ws --wsaddr "0.0.0.0" --wsorigins="*"

Answer 1

冗余

首先要考虑的是，区块链是关于分散化和稳定性的。但VPS完全是关于集权的。想象一下，如果有一些超级VPS，运行在某个虚拟CPU的单个核心上的每台服务器。你，和我，然后每个人都把他们的锁链和钥匙储存在那里。突然就来了..。小偷，海啸，断电密码都死了。

结果:你的钱包和节点很容易被破坏，或者被关闭。

I/O:

第二件事-- geth与CPU没有太大的关联，你可以很容易地在几个低端核心上运行它。它主要依赖于I/O --对DB存储的快速访问产生了RAMdisk的思想，而本机希望挖掘“成为第一个”的愿望--第一个将结果和实际块提升到大多数节点--需要疯狂的吞吐量和很大的延迟。你必须：

• 提供尽可能多的小包裹
• 到尽可能多的节点
• 尽可能快。

这就建议使用一些直接的10G光纤，并在此基础上运行节点。把它放到VM中更像是把你关进监狱，请求跑马拉松。是的也许你可以..。

结果:你的钱包将失去同步，发送错误的过时数据，滥用互联网和其他。

质量

便宜的东西是坏的，昂贵的东西是好的，也许，不总是这样。但不仅是成本效益--这有点过时了。还有“事物的质量”和“时代的稳定”这两个术语。因此，在VPS中添加geth只能描述您的恶意，并且希望“使用，而不是支付和支持它”。这一切都与ethereum区块链、社区和用户有关，它们为您提供了一个使用的值。因此，让区块链决定你的命运，根据你的做法，支持和投资它;-)

结果:廉价的硬件会烧掉，或者有人会为VPS支付更多的费用，他们只会把你从插头上剪掉，或者提高租金。

结论

购买您自己的好硬件，投资于区块链；保持本地和性能；忽略集中式钱包、交换和其他大型存储点(与大规模故障和单人“访问所有权”22相关)--我也是为您这么做的！或者现在退出使用菲亚特和中央银行，这将是你最好的VPS。

Answer 2

简而言之，当节点同步时，它执行事务，即程序代码，执行时需要读写数据(变量、数组等)。数据存储在磁盘上，读写访问通常是随机的(依赖于代码事务所包含的内容)。作为更大的块链，更多的区域执行随机读\写。我不确定，但我认为当区块链增长时同步会变慢。因此，同步的第一个问题是IO。在同步节点时，平均每秒有1.2K的读操作和0.15K的写入操作(SSD)。我试着先使用HDD，但是同步太慢了，我读到很多人根本无法与HDD同步他们的节点。我的问题是，在生产中，我只有硬盘。

我用两个步骤解决了我的问题：

1. 我用好的硬件(大的SSD，好的CPU)进行同步。
2. 我将区块链目录复制到HDD的目标主机。
3. 利润

我不能说任何关于RAM的内容，因为我有32 it的内存，也没有监控它。您可以通过geth进程和docker提供有关RAM使用的更多信息。

Answer 3

我对geth节点同步的体验：

直到最近，我才能够运行一个geth完整节点，同步到大约460万个块的阻塞高度。我使用的是2011年苹果MacBook Pro的8GB内存和足够大的SSD。我还在并行符中运行了一个奇偶校验节点，它执行得更快，同步速度更快。我更喜欢平等，但我也需要从发展的角度出发。在我看来，我的MacBook Pro不够快，无法与geth同步，我以前就放弃了HDD同步。那个时候的geth链文件夹大约是280 at !！最后，我又制作了一个完整节点的副本，目前正试图在更快的(Apple)硬件上安装它。

Import/Export:

我把geth导出到一个文件中进行了导出。它大约是17 is。但是，geth的进口并不是很好。几个小时后，我在大约260万个街区内中止了geth导入过程。也许，导出和导入多个较小的部分(比如一次100.000块)是个好主意，我找不到时间来解决这个问题。值得一试。

geth节点缓存：

将更多的缓存分配给geth客户端并不能真正帮助我解决问题。现在卡住了大约260万块的内存，它使用了大约10 it的RAM，并保留了531 (！)GB的虚拟内存。我通常分配1024或2048 MB的缓存，但是geth无论如何都会流到它想要的任何东西。

geth二进制文件的

性能

今天，我尝试使用另一个编译好的二进制文件geth1.7.3稳定。(v1.7.3-稳定/达尔文-amd64 64/go1.9.2)

mjdillon在几天前写到过: https://github.com/ethereum/go-ethereum/issues/15001

我正在运行从ethereum下载的geth二进制文件，而不是使用brew酿造的geth二进制文件。我可能会从头开始构建，没有任何包管理器或包装，直接从源。