7年前の遅いドライブでテストしたが、帯域幅と CPU は明らかにボトルネックではなかった。初回ダウンロードは 1時間 20分かかった。
それよりはるかに長く、特に 24時間もかかるなら、非常に遅いノードからダウンロードしているか、接続速度が約 15KB/秒（120kbps）よりかなり遅いか、何か他に問題があるはずだ。そのような場合にボトルネックが何であるように見えるかわかると良いのだが。
最新のブロックが送信される 10分程度ごとに、より速いノードに切り替える機会があるはずだ。最新のブロックがブロードキャストされると、他のノードに次の 500 ブロックを要求し、最も速く送信するノードからダウンロードを継続する。少なくとも、そのように動作するはずだ。
ジェフ・ガージックの投稿（2010年11月25日 17:07 UTC）サトシ・ナカモトの投稿（2010年11月25日 08:51 UTC）Berkeley DB の設定を調整して、キャッシュメモリーを有効化または増加できるかもしれない。
ダウンロード中に、ACID (http://en.wikipedia.org/wiki/ACID) プロパティのどれが必要ですか？
より多くの読み取りキャッシュが役立つかもしれない。インデックスを作成するために blk0001.dat と blkindex.dat 全体をランダムに読み取る必要がある。ファイルがメモリーより小さいと仮定することはできないが、現在はまだそうだ。ほとんどの依存関係が最近のものなので、キャッシュは効果的だろう。
誰かが異なる Berkeley DB 設定で実験して、ダウンロードを大幅に速くするものがないか確認すべきだ。大幅な改善が見つかれば、詳細を詰めることができる。
BDBレコードの追加は、チェックポイントを発行するまで、単にログファイルに追記するだけだ。チェックポイントがメインデータベースファイルを更新する。500ブロックごとにチェックポイントしている。