Piece cache篇部分用户farm缓存速度过慢解决方法(有公网IPV4或者公网IPV6的前提)

Guides and FAQs
1

如果你没有公网IP请参考这篇文章
方法很简单
在第一次同步缓存的时候可能很慢,完成同步可以要好几天

Piece cache 简介

缓存是在farm的输出里面 如下部分

2024-11-12T14:41:16.205619Z  INFO subspace_farmer::farmer_cache: Piece cache sync 6.64% complete
2024-11-12T14:41:23.441913Z  INFO subspace_farmer::farmer_cache: Piece cache sync 6.74% complete
2024-11-12T14:41:31.216118Z  INFO subspace_farmer::farmer_cache: Piece cache sync 6.84% complete
2024-11-12T14:41:36.317267Z  INFO subspace_farmer::farmer_cache: Piece cache sync 6.94% complete

缓存的大小会越来越大,每次缓存变大就会有部分数据过期,同时重P,同时第一次绘制的时候也需要缓存来加速

缓存的存储方法:

如果你是用的官方默认软件那么缓存会分割在每个你的地块部分
比如我有8个地块 缓存目前大小80个G
那么我每个地块的文件夹缓存部分可能存有10个G左右
如果你用的是官方的集群
那么缓存就是统一放在你指定的一个文件夹里面,这里的缓存你可以直接复制给别人用,非常方便

缓存加速方法

目前的加速方法就是通过连接数来找更多人拉取更多数据,更快

--in-connections 3000 `
--out-connections 3000 `
--pending-in-connections 3000 `
--pending-out-connections 3000 `

直接在farm启动的时候添加这4个参数
windows例子:

.\farm farm `
--reward-address sug1MFpGUj5txtB43R2gyTWh7EyafZX4641SJ6KyZaMdgrmPJ `
--node-rpc-url ws://192.168.50.237:5845 `
--in-connections 3000 `
--out-connections 3000 `
--pending-in-connections 3000 `
--pending-out-connections 3000 `
path=D:\1,size=6.5Tib `
path=E:\1,size=6.5Tib `
path=F:\1,size=6.5Tib `
path=G:\1,size=6.5Tib `
path=H:\1,size=6.5Tib `
path=I:\1,size=6.5Tib `
path=J:\1,size=6.5Tib `
path=K:\1,size=6.5Tib `
path=L:\1,size=6.5Tib `
path=M:\1,size=6.5Tib `
path=N:\1,size=6.5Tib `
path=O:\1,size=6.5Tib `

在添加后,基本就可以全速下行拉取缓存了

image
image1818×1216 378 KB

记住 缓存完毕后必须把这几个参数删除,或者调低,把3000改成30都可以或者就用官方默认的

如果不删除对路由器压力大,同时有运营商警告风险
删除后的启动参数例子

.\farm farm `
--reward-address sug1MFpGUj5txtB43R2gyTWh7EyafZX4641SJ6KyZaMdgrmPJ `
path=D:\1,size=6.5Tib
path=E:\1,size=6.5Tib
path=F:\1,size=6.5Tib
path=G:\1,size=6.5Tib
path=H:\1,size=6.5Tib
path=I:\1,size=6.5Tib
path=J:\1,size=6.5Tib
path=K:\1,size=6.5Tib
path=L:\1,size=6.5Tib
path=M:\1,size=6.5Tib
path=N:\1,size=6.5Tib
path=O:\1,size=6.5Tib

在跑缓存的时候,如果上行过高,可以用路由器等工具限制一下上行

image
image781×708 44 KB

因为我在测试中如果只拉in参数,设置下行连接数的时候,效果并不好,out和in的参数数量一致效果才是最好的

请一定在要缓存完毕后结束这个参数,不然对路由器非常不好

2

Please do not recommend things like this to users, 500 should be your limit, not 3000. It will likely hurt more than help.

4

I have reminded that this parameter should not be used for an extended period; after the first piece cache is completed, it needs to be reverted to the default configuration.

5

It should never be set to 3000, even during initial sync

6

Sorry, please forgive me. Many Chinese users get stuck at the Piece cache step for more than 3 days, and some even take a day to complete just 2%. I’ve tried many methods, and the only one that can speed it up right now is this approach. I’m not sure if this setting is useful, but I checked using the performance manager, and the actual number of connections is much lower than this value. I set it to 3000, but the actual number of connections is only a few hundred.

7

I did see piece cache getting stuck for 3 hours myself today, then it mystically moved on on its own. I’m investigating how that could happen and will fix once I know why.

If you have a few hundred connections in practice anyway, why not configuring it to that from the beginning then?

8

If I use the default configuration, the actual connections are only in the tens or even lower, and the same goes for the node. I don’t know the reason.

9

That is why I suggest trying 500 instead, but not higher.