From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Scalability issues
Date: Fri, 27 Jul 2012 11:59:42 +0200 [thread overview]
Message-ID: <CAPg+sBiT15KfRyBSeH15RKTcAPbq3Q12+8=w2dK8QncrWbD=sQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
And now to the list...
On Jul 27, 2012 6:21 AM, "grarpamp" <grarpamp@gmail•com> wrote:
>
> Update: this class of machine just became useless for bitcoin.
> When blk0002.dat was created to store more blocks, all forward
> progress processing blocks turned into losing ground by 20 or so
> a day. Guessing both datfiles were being accessed at once resulting
> in disk based overload. I've not seen any other mentions of crypto
> in this thread so I'm not sure how well new hardware would perform.
> Going shopping I guess.
I doubt the encryption is the problem. I have a much more recent machine
(i7 with 8 GiB RAM), and my blockchain is on a (userspace!) encrypted
filesystem. However, I do not notice any measurable slowdown from doing so.
You are however using a filesystem (ZFS) that is uses its own filesystem
caching implementation to reach some performance, and is known to be very
memory-hungry at that. Furthermore, I believe it is known to have
performance issues on 32-bit architectures. The bdb backend Bitcoin uses
does many I/O operations, and writes them synchronously to disk, killing
whatever caching your filesystem provides. For those who run a large
database on ZFS, I believe it is advised to put ZFS's intent log on a
separate SSD-backed device, to get fast synchronous writes.
That said, some improvememts may be coming. Mike has been working on
changing the backend from bdb to leveldb, which may (or may not) result in
a very different performance profile on your machine. Also, I've been
working on switching the bitcoin block verifier to use a different style
database layout ("ultraprune"), which is smaller, faster, and will support
pruning. A recent test on my own machine synced the blockchain up to the
latest checkpoint in 7 minutes (6 minutes when stored in RAM instead of
disk).
--
Pieter
[-- Attachment #2: Type: text/html, Size: 2034 bytes --]
next prev parent reply other threads:[~2012-07-27 9:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 22:37 grarpamp
2012-07-23 7:23 ` Raphael NICOLLE
2012-07-23 7:35 ` Gregory Maxwell
2012-07-23 9:00 ` Michael Grønager
2012-07-23 15:11 ` grarpamp
[not found] ` <CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
2012-07-23 22:33 ` grarpamp
2012-07-27 4:20 ` grarpamp
2012-07-27 4:59 ` Gregory Maxwell
2012-07-27 5:59 ` grarpamp
2012-07-27 6:03 ` Luke-Jr
2012-07-27 6:28 ` grarpamp
2012-07-27 6:56 ` Gregory Maxwell
2012-07-27 19:37 ` grarpamp
2012-07-27 8:53 ` Andreas Petersson
[not found] ` <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
2012-07-27 9:59 ` Pieter Wuille [this message]
2012-07-27 19:26 ` grarpamp
2012-07-23 15:54 ` steve
2012-07-24 8:25 ` Michael Grønager
2012-07-24 9:18 ` Mike Hearn
2012-07-24 19:56 ` steve
2012-07-25 9:45 ` Michael Grønager
2012-07-25 14:24 ` steve
2012-07-23 22:50 ` Aidan Thornton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBiT15KfRyBSeH15RKTcAPbq3Q12+8=w2dK8QncrWbD=sQ@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox