TurboGeth(Erigon) でetherum archive node を HDD で建てる試み(HDD おそすぎた. SSD 使いましょう)
2021/06/10 追記: Erigon に名前が変わりました.
https://torquem.ch/
過去の Uniswap の残高の履歴とか調べたいので archive node を建てたい.
geth とかで archive node sync だと 7 TB + CPU 処理いっぱい? で全然 sync が終わらないので TurboGeth を試してみます.
データベースの構造変える + マルチスレッド実行で効率化を図っているっぽい.
ストレージは 2021/03 時点で 1.5 TB ほど使います.
#TurboGeth 2020.12.01 is full synced on HDD!!! (is a double HDD in Raid0 with 64GB ram) . It took 161h 51m 35sec Here is the first HDD synced block: pic.twitter.com/aNg6yEFOZx
— funnyking.eth zkHODLER (@PaoloRebuffo) December 11, 2020
HDD でも 1 週間ほどで sync できるっぽいようですが... 単体 HDD では 2~3 週間経っても終わりませんでした. RAID-0 stripe ならいけるのかも
環境
- Threadripper 1900X + 64 GB mem
- Ubuntu 18.04
- nfs 越し NAS HDD(~80 MB/s)
ビルド
最新 golang 入れていればとくに問題なく make
でビルドできます.
動かす
./tg
だけです. 必要に応じて --datadir
でストレージ場所を指定しましょう.
default で, geth でいう archive node モード(--syncmode full --gcmode archive
)で動きます.
--syncmode
, --gcmode
のオプションはなくて, turbogeth では --storege-mode
が用意されています.
RPC daemon
JSON-RPC の機能は別バイナリで提供されています.
詳細は turbogeth の README.md 参照ください.
turbo-geth-2021.03.01/build/bin/rpcdaemon --private.api.addr=localhost:9090 --http.api=web3,eth,debug,net
のようにして起動します!
(デフォルトでは geth rpc と同じ port 8545 が RPC 用に提供される)
NFS 経由では失敗
NFS 越し HDD では [7/14 IntermediateHashes]
のところでタイムアウト関連? で NFS kernel が死んでしまいうまくいきませんでした.
[57636.632622] INFO: task tg:4596 blocked for more than 120 seconds.
[57636.632626] Tainted: P OE 4.15.0-140-generic #144-Ubuntu
[57636.632627] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[57636.632629] tg D 0 4596 4557 0x00000000
[57636.632632] Call Trace:
[57636.632640] __schedule+0x24e/0x890
[57636.632644] schedule+0x2c/0x80
[57636.632646] io_schedule+0x16/0x40
[57636.632649] wait_on_page_bit_common+0xd8/0x160
[57636.632652] ? page_cache_tree_insert+0xe0/0xe0
[57636.632654] __filemap_fdatawait_range+0xfa/0x170
[57636.632657] filemap_write_and_wait_range+0x4b/0x90
[57636.632665] nfs_file_fsync+0x46/0x200 [nfs]
[57636.632668] vfs_fsync_range+0x51/0xb0
[57636.632670] do_fsync+0x3d/0x70
[57636.632671] SyS_fdatasync+0x13/0x20
[57636.632674] do_syscall_64+0x73/0x130
[57636.632676] entry_SYSCALL_64_after_hwframe+0x41/0xa6
[57636.632678] RIP: 0033:0x7fa90488c0c7
[57636.632679] RSP: 002b:00007da85b7fdb10 EFLAGS: 00000293 ORIG_RAX: 000000000000004b
[57636.632681] RAX: ffffffffffffffda RBX: 0000000000000010 RCX: 00007fa90488c0c7
[57636.632682] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000010
[57636.632683] RBP: 00007da85b7fdba0 R08: 0000000000000000 R09: 0000000000000006
[57636.632684] R10: 0000000000a5e000 R11: 0000000000000293 R12: 00007fa8d0001bb0
[57636.632684] R13: 00007fa8d0001bb0 R14: 0000000000000000 R15: 00007da8480011c8
[75692.239082] perf: interrupt took too long (2505 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
普通の HDD
普通の HDD 4 TB x 1 で試しましたが, 2 週間経ってもおわりません...
SSD(NVMe)
Gen3x4 な NVMe 2 TB だと 3 日ほどで sync しました!
2021/04/21 時点では 1.1 TB ほどの容量でした.
sync してしまえばあとはそんなに読み書き発生しないと思いますので TBW 高くない SSD でもよいと思いますが, chia plot しているなら, plot 用の DC 向け SSD と兼用するとよさそうです(eBay で 3.5 TB で 5~6 万円くらい)
まとめ
おとなしく SSD 使いましょう. 最低限 2 TB いります.
HDD 使うのであれば, 手元で (software)RAID 構成にすればいけるかもしれません.
NFS 経由はデータサイズ大きいためかカーネルでエラーになりました.
(CIFS ならいけるか?)
Author And Source
この問題について(TurboGeth(Erigon) でetherum archive node を HDD で建てる試み(HDD おそすぎた. SSD 使いましょう)), 我々は、より多くの情報をここで見つけました https://qiita.com/syoyo/items/0c4ec06ee1c1d790d369著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .