Bitcointalk · RFC: ship block chain 1-74000 with release tarballs?

中本聪,2010 年 11 月 26 日

SN-3669 已核对来源,附原文与上下文。

阅读语言
中文译文

我在一块慢速的 7 年老硬盘上测过,带宽和 CPU 显然不是瓶颈。初始下载用了 1 小时 20 分钟。

倘若远超这个时间——当然 24 小时肯定算远超——那一定是从很慢的节点下载,或者你的连接比每秒约 15KB(120kbps)慢得多,或者有别的地方出了问题。出现那种情况时,最好能知道瓶颈看起来在哪里。

约莫每 10 分钟最新区块送达时,它都有机会切换到更快的节点。最新区块广播时,它会向其他节点请求接下来的 500 个区块,并从发送最快的一个继续下载。至少,它本该这样工作。

下载期间你需要 ACID 的哪些性质?

兴许仅仅需要更多的读缓存。它必须随机地读遍 blk0001.dat 和 blkindex.dat 来建索引。它不能假设文件比内存小,虽然目前仍是这样。缓存会相当有效,因大多数依赖都是新近的。

理应有人用不同的 Berkeley DB 设置做实验,看看有没有能让下载显著加快的配置。倘若真发现了什么,我们再落实细节。

添加 BDB 记录不过是向日志文件追加,直到你发出一次检查点。检查点随后更新主数据库文件。

我们每 500 个区块检查点一次。

ORIGINAL · 英文原文
I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck.  Initial download took 1 hour 20 minutes.

If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong.  It would be nice to know what appears to be the bottleneck when that happens.

Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node.  When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest.  At least, that's how it should work.

Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the ACID properties do you need, while downloading?
It may only need more read caching.  It has to read randomly all over blk0001.dat and blkindex.dat to index.  It can't assume the file is smaller than memory, although it currently still is.  Caching would be effective, since most dependencies are recent.

Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster.  If something substantial is discovered, then we can work out the particulars.

Quote
Adding BDB records is simply appending to a log file, until you issue a checkpoint.  The checkpoint then updates the main database file.
We checkpoint every 500 blocks.
来源
Bitcointalk 原始链接 ↗ 记录编号 SN-3669