gethが求めるサーバスペック(aws編)
gethが求めるサーバスペック(aws編):
k8sの激しい脆弱性で青ざめている皆様おこんにちわ。@Derorisanこと村田です。
gethのノードを使いたいと思ったときには良い子はinfura.ioを使うのが一般的かと思いますが、軽い気持ちでawsのec2で立ち上げてみようと思いました。
・・・のがいけなかった。
fastmodeにてt3.mediumで試していたがぜんぜんsyncが終わらずに涙目になる結果に。
昔はラズパイてきなものでも楽勝だったのに・・・・
ということで、どのくらいのスペックが必要になっているのか検証してみました。
infura.ioの記事では2018/3にm5.xlargeからi3.xlargeに上げれば2倍処理できるからコスパ(・∀・)ｲｲ!!みたいな記事がありましたのでそのあたりのインスタンスで試します。
Optimizing Performance and Cost: Infura Benchmark Analysis
まぁ上記の通り予想外の事案なので、とりあえず良い感じに動くインスタンスを探そうと思います。
どうせすぐに要求スペックは変動してしまうと思うので、沼にハマりすぎないように注意！
まずはsyncされたデータを作りたいので2018/3月にinfura.ioが検証していたi3.xleargeで行う。
i3.xlargeはNVMeのEBSがついてくるのでそれのマウントから行う。
EBSボリュームが/extend-dataにマウントできたのでそこをgethのdatadirに指定する予定。
golangはamazon linux extraより入れる。
何も考えずにec2-userのホームディレクトリへ。
https://github.com/ethereum/go-ethereum/releases から今のところ最新のNo Nick (v1.8.19)をDLしてビルドする。
これでビルドできた。
おっとその前に
起動しよう。
数秒もすればStateとblockを落とし始める。
syncの状態を確認すると・・・
一番高いブロックhighestBlockが入っていれば稼働確認はOK。（https://etherscan.io/ などのlast Blockの数字と比べるとよいかも)
問題なのはpulledStatesとknownStatesで、こいつらは追いつけ追い抜けでどんどん上がっていく。
数日前に確認したら同期完了間近で250,000,000ぐらいの値を叩き出していた。
同期が完了するとeth.syncingがfalseを返すようになる。ログも急におとなしくなる。
現在2018/12/06 12:00頃である。
とりあえずコレで夕方まで放置！
1時間ほどが経過した13時ごろ。
14時ごろ
16時ごろ
Stateは250,000,000以上なのでまだまだ。Blockは追いついてきているのにねー。
ほんとは定時観測でState部分のデータを取りたかったんだけどやり直すのも時間かかるので許してネ。
24時間かからないぐらいで同期が追いつく気がするよ。
さてsyncが終わったi3.xlargeを別途ご用意しておりますので、それのデータを使ってt3.mediumあたりでgethを起動する。
syncが追いつかないと予想しているのでeth.synckingが値を返すようになるハズである。
あらかじめ用意しておいたi3.xlargeでのsyncデータをEBSにコピーしてアタッチして起動してみる。
こんな感じになっているはず。
gethをビルドして起動
2時間ほど前のデータなので、age=2h1m29sと出ている。fastmodeはsyncが終わるとfullmodeになってfullブロックも落とし始めるらしいので値が入っている。(よく知らない)
を想定通りeth.syncingが値を返すようになっている。
1時間ほど放置してみよう。
1時間半ほど放置したら、
となりsyncが終わってしまった。追いつかないのを想定していたんだけどっ？
すでにあるデータを利用したのでsyncできたが、ゼロからのsyncだとどのくらいかかるのか・・・(1週間ぐらいやったがだめでした。)
起動してからsyncが追いついて1時間ほど経過したメトリクス
EC2
EBS
う〜ん。なんかイマイチこう、ボトルネックがわからないよね。
(t3系なのでcpu creditがなくなっても自動で課金バーストします。)
追いつかないと思ったが一度syncされてしまえばt3.mediumでも稼働はするといったところか。
まぁとりあえず動く、クエリも問題なく戻ってくる。
上のt3.mediumを実行するときに使ったEBSのスナップショットから開始。
age=5h18m16sが、20分ほどでsyncされた。
体感もそりゃ早い。
EC2(t3.mediumのインスタンスタイプを変更して作ってしまったのでt3のときのデータが残っています。切れているところあたりからm5.xlarge)
EBS
i3.xlargeあたりのスペックを利用すると余裕を持った運用ができそう。辛抱強くやるのであればm系のlargeあたりでもよいかもしれないが、syncに時間がかかってしまう上、オートスケーリングやk8sなどを利用した場合、インスタンス(Pods)が入れ替わった際にsyncが終わるまで待つ必要がある。
それでも本番運用などしたい！ということであればEBSのスナップショットを取りながら新しいインスタンスは最新のソレから。みたいなことをするのがよさそう。
要するに最新ブロックまで追いつくのに必要なスペックと稼働するだけのスペックの差がハンパねぇってことですね。
ちなみにEFSでも試してみたがぜんぜん遅かったでござる。オススメしない。
ブロックのsyncよりもStatesのほうが時間がかかるので注意。
Blockだけ気にしていると値が追いつきそうで追いつかない状況が続く。まじでぐぬぬぬ感を味わうことになるのでご注意ください。
ラズパイでgethを動かしていたのはもう遠い昔の話、今はそんなんじゃ無理。（遠い目
maxpeersやcacheのオプションをいじると速くなるかもしれないが、どちらにせよあまったPCで云々とかの場合はご注意あれ。
i3.xlargeって0.366USD/時間かかるわけで、月額3万円ぐらいかかってしまうので、なにかに魅せられた人と、わざわざお金を払って自身でノードを管理したい人以外は、 https://infura.io/ を利用するか、geth syncmodeをlightにして利用しましょう。lightならばt3.mediumでもラクラク動きます。
※ infura.io は consensys とawsがやっているEthereumノードのホスティングサービス。今のところタダです。
k8sの激しい脆弱性で青ざめている皆様おこんにちわ。@Derorisanこと村田です。
gethのノードを使いたいと思ったときには良い子はinfura.ioを使うのが一般的かと思いますが、軽い気持ちでawsのec2で立ち上げてみようと思いました。
・・・のがいけなかった。
fastmodeにてt3.mediumで試していたがぜんぜんsyncが終わらずに涙目になる結果に。
昔はラズパイてきなものでも楽勝だったのに・・・・
ということで、どのくらいのスペックが必要になっているのか検証してみました。
infura.ioの記事では2018/3にm5.xlargeからi3.xlargeに上げれば2倍処理できるからコスパ(・∀・)ｲｲ!!みたいな記事がありましたのでそのあたりのインスタンスで試します。
Optimizing Performance and Cost: Infura Benchmark Analysis
目的
まぁ上記の通り予想外の事案なので、とりあえず良い感じに動くインスタンスを探そうと思います。どうせすぐに要求スペックは変動してしまうと思うので、沼にハマりすぎないように注意！
確認方法
環境
- aws オレゴンリージョン
- amazon linux 2: 4.14.77-81.59.amzn2.x86_64
- goのバージョン: amazon-linux-extras golang1.9 (go version go1.9.4 linux/amd64)
- geth のバージョン: v1.8.19
- 起動オプション:
./build/bin/geth --datadir=/extend-data/geth --syncmode=fast
やっていく
i3.xlearge
まずはsyncされたデータを作りたいので2018/3月にinfura.ioが検証していたi3.xleargeで行う。i3.xlargeはNVMeのEBSがついてくるのでそれのマウントから行う。
EBSマウント
[ec2-user@ip-10-242-0-241 ~]$ uname -a
Linux ip-10-242-0-241.us-west-2.compute.internal 4.14.77-81.59.amzn2.x86_64 #1 SMP Mon Nov 12 21:32:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[ec2-user@ip-10-242-0-241 ~]$ sudo parted -l
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
128 1049kB 2097kB 1049kB BIOS Boot Partition bios_grub
1 2097kB 8590MB 8588MB xfs Linux
Error: /dev/nvme0n1: unrecognised disk label
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 950GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
[ec2-user@ip-10-242-0-241 ~]$ sudo mkfs.xfs /dev/nvme0n1
meta-data=/dev/nvme0n1 isize=512 agcount=4, agsize=57983399 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=231933593, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=113248, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[ec2-user@ip-10-242-0-241 ~]$ sudo mkdir /extend-data
[ec2-user@ip-10-242-0-241 ~]$ sudo mount /dev/nvme0n1 /extend-data
[ec2-user@ip-10-242-0-241 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 15G 0 15G 0% /dev
tmpfs 15G 0 15G 0% /dev/shm
tmpfs 15G 412K 15G 1% /run
tmpfs 15G 0 15G 0% /sys/fs/cgroup
/dev/xvda1 8.0G 1.2G 6.9G 15% /
tmpfs 3.0G 0 3.0G 0% /run/user/1000
/dev/nvme0n1 885G 33M 885G 1% /extend-data
golangのインストール
golangはamazon linux extraより入れる。[ec2-user@ip-10-242-0-241 ~]$ sudo amazon-linux-extras install golang1.9 -y Installing golang Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Cleaning repos: amzn2-core amzn2extra-golang1.9 9 metadata files removed 4 sqlite files removed 0 metadata files removed Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 2.4 kB 00:00:00 amzn2extra-golang1.9 | 1.3 kB 00:00:00 (1/4): amzn2-core/2/x86_64/group_gz | 2.4 kB 00:00:00 (2/4): amzn2-core/2/x86_64/updateinfo | 56 kB 00:00:00 (3/4): amzn2extra-golang1.9/2/x86_64/primary_db | 3.9 kB 00:00:00 (4/4): amzn2-core/2/x86_64/primary_db | 23 MB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package golang.x86_64 0:1.9.4-1.amzn2.0.2 will be installed --> Processing Dependency: golang-src = 1.9.4-1.amzn2.0.2 for package: golang-1.9.4-1.amzn2.0.2.x86_64 --> Processing Dependency: golang-bin = 1.9.4-1.amzn2.0.2 for package: golang-1.9.4-1.amzn2.0.2.x86_64 --> Running transaction check ---> Package golang-bin.x86_64 0:1.9.4-1.amzn2.0.2 will be installed --> Processing Dependency: gcc for package: golang-bin-1.9.4-1.amzn2.0.2.x86_64 ---> Package golang-src.noarch 0:1.9.4-1.amzn2.0.2 will be installed --> Running transaction check ---> Package gcc.x86_64 0:7.3.1-5.amzn2.0.2 will be installed --> Processing Dependency: cpp = 7.3.1-5.amzn2.0.2 for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libubsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libtsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libquadmath.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libmpxwrappers.so.2()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libmpx.so.2()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libmpfr.so.4()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libmpc.so.3()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: liblsan.so.0()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libitm.so.1()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libcilkrts.so.5()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libatomic.so.1()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Processing Dependency: libasan.so.4()(64bit) for package: gcc-7.3.1-5.amzn2.0.2.x86_64 --> Running transaction check ---> Package cpp.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package glibc-devel.x86_64 0:2.26-28.amzn2.0.1 will be installed --> Processing Dependency: glibc-headers = 2.26-28.amzn2.0.1 for package: glibc-devel-2.26-28.amzn2.0.1.x86_64 --> Processing Dependency: glibc-headers for package: glibc-devel-2.26-28.amzn2.0.1.x86_64 ---> Package libatomic.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package libcilkrts.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package libitm.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package libmpc.x86_64 0:1.0.1-3.amzn2.0.2 will be installed ---> Package libmpx.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package libquadmath.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package libsanitizer.x86_64 0:7.3.1-5.amzn2.0.2 will be installed ---> Package mpfr.x86_64 0:3.1.1-4.amzn2.0.2 will be installed --> Running transaction check ---> Package glibc-headers.x86_64 0:2.26-28.amzn2.0.1 will be installed --> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers-2.26-28.amzn2.0.1.x86_64 --> Processing Dependency: kernel-headers for package: glibc-headers-2.26-28.amzn2.0.1.x86_64 --> Running transaction check ---> Package kernel-headers.x86_64 0:4.14.77-81.59.amzn2 will be installed --> Finished Dependency Resolution ~snip; [ec2-user@ip-10-242-0-241 ~]$ go version go version go1.9.4 linux/amd64
gethのビルド
何も考えずにec2-userのホームディレクトリへ。https://github.com/ethereum/go-ethereum/releases から今のところ最新のNo Nick (v1.8.19)をDLしてビルドする。
[ec2-user@ip-10-242-0-241 ~]$ wget https://github.com/ethereum/go-ethereum/archive/v1.8.19.tar.gz ~snip; [ec2-user@ip-10-242-0-241 ~]$ tar zxfv v1.8.19.tar.gz ~snip; [ec2-user@ip-10-242-0-241 ~]$ cd go-ethereum-1.8.19/ [ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ make geth build/env.sh go run build/ci.go install ./cmd/geth >>> /usr/lib/golang/bin/go install -v ./cmd/geth github.com/ethereum/go-ethereum/vendor/golang.org/x/sys/unix github.com/ethereum/go-ethereum/common/hexutil github.com/ethereum/go-ethereum/crypto/sha3 ~snip; Done building. Run "/home/ec2-user/go-ethereum-1.8.19/build/bin/geth" to launch geth.
gethの起動
おっとその前に/extend-data/gethディレクトリをほっておこう[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ sudo mkdir /extend-data/geth [ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ sudo chown ec2-user:ec2-user /extend-data/geth
[ec2-user@ip-10-242-0-241 go-ethereum-1.8.19]$ ./build/bin/geth --datadir=/extend-data/geth --syncmode=fast INFO [12-06|02:48:18.614] Maximum peer count ETH=25 LES=0 total=25 INFO [12-06|02:48:18.616] Starting peer-to-peer node instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4 INFO [12-06|02:48:18.616] Allocated cache and file handles database=/extend-data/geth/geth/chaindata cache=512 handles=512 ~snip;
WARN [12-06|02:48:33.918] Header broke chain ancestry peer=d7af2b1b359c1e65 number=2 hash=b495a1…4698c9 INFO [12-06|02:48:34.972] Imported new block headers count=384 elapsed=842.399ms number=384 hash=d3d5d5…c79cf3 age=3y4mo3w INFO [12-06|02:48:34.980] Imported new block receipts count=2 elapsed=81.303µs number=2 hash=b495a1…4698c9 age=3y4mo3w size=8.00B INFO [12-06|02:48:35.118] Imported new state entries count=1624 elapsed=192.602µs processed=1624 pending=20672 retry=0 duplicate=0 unexpected=0 INFO [12-06|02:48:35.136] Imported new block receipts count=4 elapsed=124.871µs number=6 hash=1f1aed…6b326e age=3y4mo3w size=1.10kB INFO [12-06|02:48:35.282] Imported new block receipts count=26 elapsed=313.617µs number=32 hash=88be69…60ae13 age=3y4mo3w size=1.18kB INFO [12-06|02:48:35.402] Imported new state entries count=768 elapsed=1.190ms processed=2392 pending=26243 retry=0 duplicate=0 unexpected=0 INFO [12-06|02:48:35.999] Imported new state entries count=787 elapsed=2.067ms processed=3179 pending=26495 retry=0 duplicate=0 unexpected=0 INFO [12-06|02:48:36.268] Imported new state entries count=1152 elapsed=2.651ms processed=4331 pending=26817 retry=0 duplicate=0 unexpected=0 INFO [12-06|02:48:36.816] Imported new state entries count=1152 elapsed=3.468ms processed=5483 pending=26124 retry=0 duplicate=0 unexpected=0
[ec2-user@ip-10-242-0-241 ~]$ go-ethereum-1.8.19/build/bin/geth attach --datadir=/extend-data/geth
Welcome to the Geth JavaScript console!
instance: Geth/v1.8.19-stable/linux-amd64/go1.9.4
modules: admin:1.0 debug:1.0 eth:1.0 ethash:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0
> eth.syncing
{
currentBlock: 195698,
highestBlock: 6834170,
knownStates: 826618,
pulledStates: 761756,
startingBlock: 0
}
問題なのはpulledStatesとknownStatesで、こいつらは追いつけ追い抜けでどんどん上がっていく。
数日前に確認したら同期完了間近で250,000,000ぐらいの値を叩き出していた。
同期が完了するとeth.syncingがfalseを返すようになる。ログも急におとなしくなる。
現在2018/12/06 12:00頃である。
とりあえずコレで夕方まで放置！
1時間ほどが経過した13時ごろ。
> eth.syncing
{
currentBlock: 3875877,
highestBlock: 6834321,
knownStates: 23398655,
pulledStates: 23353466,
startingBlock: 0
}
> eth.syncing
{
currentBlock: 4936260,
highestBlock: 6834321,
knownStates: 54538287,
pulledStates: 54393822,
startingBlock: 0
}
Stateは250,000,000以上なのでまだまだ。Blockは追いついてきているのにねー。
> eth.syncing
{
currentBlock: 5784354,
highestBlock: 6834321,
knownStates: 78447926,
pulledStates: 78395039,
startingBlock: 0
}
24時間かからないぐらいで同期が追いつく気がするよ。
t3.medium EBS io1 10000IOPS
さてsyncが終わったi3.xlargeを別途ご用意しておりますので、それのデータを使ってt3.mediumあたりでgethを起動する。syncが追いつかないと予想しているのでeth.synckingが値を返すようになるハズである。
あらかじめ用意しておいたi3.xlargeでのsyncデータをEBSにコピーしてアタッチして起動してみる。
こんな感じになっているはず。
[ec2-user@ip-10-242-1-67 ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 364K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/nvme0n1p1 8.0G 1.5G 6.6G 19% / tmpfs 389M 0 389M 0% /run/user/1000 /dev/nvme1n1 200G 148G 53G 74% /extend-data
[ec2-user@ip-10-242-1-67 go-ethereum-1.8.19]$ ./build/bin/geth --datadir=/extend-data/geth --syncmode=fast
INFO [12-06|05:51:38.911] Maximum peer count ETH=25 LES=0 total=25
INFO [12-06|05:51:38.912] Starting peer-to-peer node instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4
INFO [12-06|05:51:38.912] Allocated cache and file handles database=/extend-data/geth/geth/chaindata cache=512 handles=512
INFO [12-06|05:51:42.444] Initialised chain configuration config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: <nil> Engine: ethash}"
INFO [12-06|05:51:42.445] Disk storage enabled for ethash caches dir=/extend-data/geth/geth/ethash count=3
INFO [12-06|05:51:42.445] Disk storage enabled for ethash DAGs dir=/home/ec2-user/.ethash count=2
INFO [12-06|05:51:42.445] Initialising Ethereum protocol versions="[63 62]" network=1
INFO [12-06|05:51:42.489] Loaded most recent local header number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.489] Loaded most recent local full block number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.489] Loaded most recent local fast block number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=2h1m29s
INFO [12-06|05:51:42.495] Loaded local transaction journal transactions=0 dropped=0
INFO [12-06|05:51:42.496] Regenerated local transaction journal transactions=0 accounts=0
WARN [12-06|05:51:42.496] Blockchain not empty, fast sync disabled
INFO [12-06|05:51:42.627] New local node record seq=9 id=418734a7558f8c27 ip=127.0.0.1 udp=30303 tcp=30303
INFO [12-06|05:51:42.628] IPC endpoint opened url=/extend-data/geth/geth.ipc
INFO [12-06|05:51:42.628] Started P2P networking self=enode://a625ff5093e694d48c5efca9beac26dee818f1c3ada7c3353bde25edff21bb25159a3869c51e4505f1b1b6f50dde5c77624f44ab4be9ec18c77708422e164306@127.0.0.1:30303
INFO [12-06|05:51:46.958] New local node record seq=10 id=418734a7558f8c27 ip=34.219.58.204 udp=30303 tcp=30303
> eth.syncing
{
currentBlock: 6834508,
highestBlock: 6834923,
knownStates: 250942264,
pulledStates: 250942264,
startingBlock: 6834406
}
1時間ほど放置してみよう。
> eth.syncing
{
currentBlock: 6835252,
highestBlock: 6835254,
knownStates: 250942264,
pulledStates: 250942264,
startingBlock: 6835252
}
> eth.syncing false
すでにあるデータを利用したのでsyncできたが、ゼロからのsyncだとどのくらいかかるのか・・・(1週間ぐらいやったがだめでした。)
起動してからsyncが追いついて1時間ほど経過したメトリクス
EC2
EBS
う〜ん。なんかイマイチこう、ボトルネックがわからないよね。
(t3系なのでcpu creditがなくなっても自動で課金バーストします。)
追いつかないと思ったが一度syncされてしまえばt3.mediumでも稼働はするといったところか。
まぁとりあえず動く、クエリも問題なく戻ってくる。
m5.xlarge EBS io1 10000IOPS
上のt3.mediumを実行するときに使ったEBSのスナップショットから開始。[ec2-user@ip-10-242-1-67 ~]$ ./go-ethereum-1.8.19/build/bin/geth --datadir=/extend-data/geth --syncmode=fast
INFO [12-06|09:08:26.444] Maximum peer count ETH=25 LES=0 total=25
INFO [12-06|09:08:26.445] Starting peer-to-peer node instance=Geth/v1.8.19-stable/linux-amd64/go1.9.4
INFO [12-06|09:08:26.445] Allocated cache and file handles database=/extend-data/geth/geth/chaindata cache=512 handles=512
INFO [12-06|09:08:29.626] Initialised chain configuration config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: <nil> Engine: ethash}"
INFO [12-06|09:08:29.626] Disk storage enabled for ethash caches dir=/extend-data/geth/geth/ethash count=3
INFO [12-06|09:08:29.626] Disk storage enabled for ethash DAGs dir=/home/ec2-user/.ethash count=2
INFO [12-06|09:08:29.627] Initialising Ethereum protocol versions="[63 62]" network=1
INFO [12-06|09:08:29.662] Loaded most recent local header number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.662] Loaded most recent local full block number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.662] Loaded most recent local fast block number=6834406 hash=0f5295…7fe787 td=8157890197157576340349 age=5h18m16s
INFO [12-06|09:08:29.674] Loaded local transaction journal transactions=0 dropped=0
INFO [12-06|09:08:29.675] Regenerated local transaction journal transactions=0 accounts=0
WARN [12-06|09:08:29.675] Blockchain not empty, fast sync disabled
INFO [12-06|09:08:29.820] New local node record seq=9 id=418734a7558f8c27 ip=127.0.0.1 udp=30303 tcp=30303
INFO [12-06|09:08:29.821] Started P2P networking self=enode://a625ff5093e694d48c5efca9beac26dee818f1c3ada7c3353bde25edff21bb25159a3869c51e4505f1b1b6f50dde5c77624f44ab4be9ec18c77708422e164306@127.0.0.1:30303
INFO [12-06|09:08:29.823] IPC endpoint opened url=/extend-data/geth/geth.ipc
INFO [12-06|09:08:38.034] New local node record seq=10 id=418734a7558f8c27 ip=34.217.61.97 udp=30303 tcp=30303
INFO [12-06|09:09:29.821] Block synchronisation started
INFO [12-06|09:09:44.705] Imported new chain segment blocks=2 txs=324 mgas=15.908 elapsed=7.644s mgasps=2.081 number=6834408 hash=9d97eb…8e3add age=5h18m55s cache=2.18mB
INFO [12-06|09:09:54.412] Imported new chain segment blocks=4 txs=702 mgas=24.354 elapsed=9.697s mgasps=2.511 number=6834412 hash=30b7d6…31931a age=5h18m9s cache=5.59mB
INFO [12-06|09:10:04.607] Imported new chain segment blocks=7 txs=797 mgas=42.340 elapsed=10.195s mgasps=4.153 number=6834419 hash=0211af…430e5f age=5h16m53s cache=11.35mB
体感もそりゃ早い。
EC2(t3.mediumのインスタンスタイプを変更して作ってしまったのでt3のときのデータが残っています。切れているところあたりからm5.xlarge)
EBS
まとめ
sync中と追いついたあとの負荷が段違い
i3.xlargeあたりのスペックを利用すると余裕を持った運用ができそう。辛抱強くやるのであればm系のlargeあたりでもよいかもしれないが、syncに時間がかかってしまう上、オートスケーリングやk8sなどを利用した場合、インスタンス(Pods)が入れ替わった際にsyncが終わるまで待つ必要がある。それでも本番運用などしたい！ということであればEBSのスナップショットを取りながら新しいインスタンスは最新のソレから。みたいなことをするのがよさそう。
要するに最新ブロックまで追いつくのに必要なスペックと稼働するだけのスペックの差がハンパねぇってことですね。
ちなみにEFSでも試してみたがぜんぜん遅かったでござる。オススメしない。
Stateのsync
ブロックのsyncよりもStatesのほうが時間がかかるので注意。Blockだけ気にしていると値が追いつきそうで追いつかない状況が続く。まじでぐぬぬぬ感を味わうことになるのでご注意ください。
予想を上回る要求スペック
ラズパイでgethを動かしていたのはもう遠い昔の話、今はそんなんじゃ無理。（遠い目maxpeersやcacheのオプションをいじると速くなるかもしれないが、どちらにせよあまったPCで云々とかの場合はご注意あれ。
理由がないのであればinfura.io か lightmodeでの利用を！
i3.xlargeって0.366USD/時間かかるわけで、月額3万円ぐらいかかってしまうので、なにかに魅せられた人と、わざわざお金を払って自身でノードを管理したい人以外は、 https://infura.io/ を利用するか、geth syncmodeをlightにして利用しましょう。lightならばt3.mediumでもラクラク動きます。※ infura.io は consensys とawsがやっているEthereumノードのホスティングサービス。今のところタダです。
コメント
コメントを投稿