初始产块节点升级2.0.3的设置推荐
We want to thank Starteos for helping us translate this article. The english version can be found here. This could not have been done without you.
介绍
6周前，发布了EOSIO 2.0.0版本。在新版本发布之后，多家产块节点和备选节点与B1联手测试，以保证EOS主网在安全的情况下进行升级；避免冒险在运行缓慢的节点上运载过重的区块（指的是CPU和NET的使用情况）时，节点与链同步的成本过高。
这个帖子里探讨的两个参数，可以帮助产块节点随意调节所产区块的重量。在2.0.4版本中，各项性能会得到更好的优化，可以帮助产块节点生成更多完整的区块，更快地发送区块，并在资源耗尽时立即产块。
这些优化后的改进可以使CPU速度较快的产块节点与CPU速度较慢的节点相比，生产同样重量的区块只需花费更短的时间。同时可以激励节点升级硬件(更快地生产区块，意味着可以更早地释放区块 — — 最终可以保证被分叉的区块数量减少)。
方法
以下测试是与 atticlab, flytomars以及eoscannon.协作完成的。
我们一直在测试不同的配置，同时也在观察在这段时间内，每个节点处理的操作数量。测试的目的主要是为了找到节点升级到2.0.3的最佳参数配置：
- cpu-effort-percent
- last-block-cpu-effort-percent
我们跟踪了微分叉（从产块节点A到产块节点B交接过程中丢掉的区块）的数量同时还有接收区块的延迟。我们分析了分叉的情况，以分析导致这一问题的根源以及原因所在。
我们在旧的硬件上增加了数个节点，以观察这些机器是如何在调整产块节点上的CPU工作量的同时，跟上传入的区块。这一尝试，是为了确保，在不进行造价昂贵的升级的情况下，DAPP、交易所和研究人员会因为无法处理的区块而服务器过载(如果出现这样的问题，以上参数是可以更改的)。
出于同样的原因，我们在其中一台旧机器上，在没有使用过滤器的情况下启用了已经停用的v1 history插件(见表3)，(这允许节点处理 /v1/history/get_controlled_accounts 和 /v1/history/get_key_accounts 钱包方等发起的请求)。
使用的硬件
- Atticlabs producer on Intel i9–9900K @ 5.1 GHz
- E5–2660 @ 2.7GHz (released 8 years ago)
- X5670 @ 3.2 GHz (released 10 years ago)
结论
下面显示的结果来自于使用双Intel Xeon X5760命名的机器。我们确实看到了在同步两台旧机器(E5–2660和X5670)时出现的相似的差异。
一旦节点赶上头部区块之后，我们观察了从特定节点接收区块的延迟。通过这种方式，在我们追踪传入区块延迟的同时，和该产块节点一起协作。通过使用eosmechanics标准，我们可以识别出CPU最快的节点。
在下表中，我们可以查看从Atticlab接收区块的延迟。
所有这些测试的最后一个块cpu-effort-percent都设置为20：
不出所料，接收区块所需的时间取决于区块的重量。
以下，使用不推荐大家使用的v1历史记录插件进行测试：
可以看出，当节点沿头部跟进而不是同步追赶进度时，启用eos-vm-oc可以带来更优的性能提升。
根据Eosmechanics基准测试，使用X5670在丛林测试网上产块会产生以下结果：
摘要
将cpu-effort-percentage设置为40％，甚至是50%看起来也是非常安全的，只要将运行缓慢的计算机配置为使用eos-vm-oc-enable = 1的配置，一切运行的都很顺畅。 没有其他节点拥有像Atticlab一样快的CPU — — 所以对于大多数节点来说，达到60%甚至70%是最安全的(这可以随着时间的推移而增加)。
根据不同的需求和用例，还可以配置其他优化项来帮助运行缓慢的机器保持与头部区块的同步。
升级到2.0.3将有助于缓解微分叉，以及稳定和优化整条链的性能。这很容易理解，因为运行wasm-runtime = eos-vm-jit可以降低cpu工作量比率，同时生成具有相同重量的区块。然后可以更早地释放这些区块。这使得下一个产块节点有更多的时间来接收和处理传入区块。
这些测试结果使我们相信，现在是EOS主网上的产块节点升级到2.0.3并运行wasm-runtime = EOS -vm-jit的时候了，只要我们将cpu-工作量比率和last-block-cpu-effort-percent百分比从默认值(80)降低即可。这个操作可以大大优化现有的性能。
目前，绝大多数的操作都是由少数几个产块节点来处理的。升级到2.0.3 — 然后升级到2.0.4应该可以解决这个问题 — 这意味着提高了性能和主网的稳定性。
展望未来，跟踪和调整每个产块节点的个体表现将非常容易，以确保我们在不产生太大重量的区块下平衡工作量。 只要我们确保在切换产块节点时就对其进行监视（Sw / eden的老铁们将很乐意帮兄弟一把）。 我们可以帮忙生成性能报告，帮助优化配置或回答你的所有问题。
请记住，不要在产块节点上启用eos-vm-oc。
随着2.0.3版本的发布，我们相信这次升级现在可以以一种安全的方式来处理，以提高EOS 主网的稳定性和性能。
期待看到在成功升级到2.0.3之后，主网可以达到的性能记录，以及2.0.4版本中的新功能将如何更好地提高稳定性！
配置节点可以从以下数值开始。
cpu-effort-percent = 50
last-block-cpu-effort-percent = 20
Eosswedenorg
sw/eden — South West Eden
Block Producer Located in Sweden.
Telegram: https://t.me/eossweden
Website: Https://eossweden.org/
Twitter: https://twitter.com/EosSweden
