可以说很丢人了，(Geth)下载以太坊区块的准确姿势到底是怎么样的

[johnsneakers]

试了 N 遍 N+M 次不同下载姿势(full,fast..) ,要么是 geth 奔溃代码报错，要么是莫名其妙 killed

前 400 万区块下载没问题，到 400 万以后 geth 进程莫名其妙就 killed 掉了， 搞了很久查了很多问题都没解决, 最好想到监控进程续命大法:geth 一挂掉我就再启动。 现在是越接近最新区块高度挂的频率越高，实在无法忍受我把 geth 从原来的 1.7.3 版本换到 1.7.2 版本。好了，现在又有新问题了，进程不崩了，currentBlock 开始不涨了，换成 knownStates 和 pulledStates 这两个值蜜汁变化(开始是 0 慢慢开始在涨，涨到 100 多万我没管， 过了一会儿回来发现怎么又是 80 万。 可以说很丢人了， 一个钱包同步都搞死了， 有没有大佬指点一下

[lucas56]

直接下载二进制文件放到 /usr/bin 加上 --fast --cache 参数，崩溃问题与硬盘有关系

[johnsneakers]

@lucas56 我就是这样搞得， 我也是觉得很硬盘关系！ 从 linode 换到 aliyun 然后又换回来 。。。一样 现在不崩了 ，但是 currentblock 就是一直不涨了，。 请教你个问题，我当前区块高度已经超过我钱包那次交易的高度， 为什么查询余额还是 0 呢， 是因为没下完的原因？

[lucas56]

崩溃分两种，一种是资源占用满了，被服务商 kill 了，一种是硬盘问题，你看日志，是哪种情况，还有同步尽量用本地磁盘，别用云硬盘

[lucas56]

同步节点文件设置了吗

[tailf]

云服务器的磁盘都有读写速度限制，如果短时间写过高，阿里云会让机器假死。

[johnsneakers]

@lucas56 我的是这种： https://github.com/ethereum/go-ethereum/issues/14693 但是么他那么夸张几秒就被干掉

同步节点？你说是的 enode, 我现在用的美国区的 linode 也需要吗？

[ciga]

推荐一个适合新手的以太坊 DApp 开发教程： http://xc.hubwiz.com/course/5a952991adb3847553d205d1?affid=v2ex7878