原始文献 / 论坛帖 / Re: RFC: ship block chain 1-74000 with release tarballs?
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcointalk · 2010-11-26 17:32:01 UTC
我在一块很慢的 7 年老硬盘上测过，带宽和 CPU 明显不是瓶颈。初始下载用了 1 小时 20 分钟。
如果花的时间比这长得多，肯定超过 24 小时，那一定是从很慢的节点下载，或者你的连接比约 15KB/秒（120kbps）还慢得多，或者有别的问题。真发生的话，很想知道瓶颈看起来是什么。
大约每 10 分钟，最新区块发过来时，它就有机会换到更快的节点。最新区块广播时，它会向其他节点请求接下来的 500 个区块，并从发得最快的那个继续下载。至少应该是这样工作的。
引用自 jgarzik（2010 年 11 月 26 日 02:07:43 AM）（https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522）：引用自 satoshi（2010 年 11 月 25 日 05:51:39 PM）（https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438）：也许 Berkeley DB 有些可调参数，能启用或增大缓存。
下载时你需要 ACID（http://en.wikipedia.org/wiki/ACID）里的哪几条性质？
可能只需要多点读缓存。建索引时它要在 blk0001.dat 和 blkindex.dat 上到处随机读。它不能假设文件比内存小，虽然目前确实还小。缓存会有效，因为大多数依赖都是近期的。
应该有人去试试不同的 Berkeley DB 设置，看有没有能让下载明显变快的。如果发现了明显有效的，我们再敲定细节。
引用自（……）：往 BDB 加记录其实就是往日志文件末尾追加，直到你发 checkpoint。checkpoint 再更新主数据库文件。我们每 500 个区块 checkpoint 一次。
英文原文
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.
Quote from: jgarzik on November 26, 2010, 02:07:43 AM（https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522）Quote from: satoshi on November 25, 2010, 05:51:39 PM（https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438）Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the ACID（http://en.wikipedia.org/wiki/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.
QuoteAdding 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.