On a system with mining disabled and doing nothing but AddAddress calls according to the debug log, there are 80-120 IOPs per second (likely very small ops, because the total throughput is only ~1MB/s), which can bog a system down considerably.
Some avenues of improvement might be:
Overall transaction handling in db.cpp is terrible. BDB has good transaction support, but it is only used in one or two places.
This appears to be at least an order of magnitude worse in the OSX build than in the Linux build. Might OSX be handling the fsync'ing differently?
Yeah, it's absolutely abysmal on osx.
I didn't really notice since the macs I run it on all have SSDs. But yes, it is demonstrably worse on OS X.
With a high-end Mac Pro (gobs of RAM, 2 quad-core CPUs) this issue makes Bitcoin essentially unusable in conjunction with other day-to-day use of the machine. It causes the HD to click noisily all day (with brief pauses) and degrades performance of other applications - web browsing etc. I keep Bitcoin terminated during the day when working and just run it at night.
How large is the address DB typically and is it expected to grow with network size? (mine is ~15MB). If it remains of that order, perhaps an option to keep it in memory would be appropriate?
I'm assuming the 'fsync' suggestion above involves modification of the code, but if there is any 'quick fix' available, that would be a useful temporary workaround for Mac users.
Cheers (- everyones work is appreciated).
You might try -noflushwallet, but that probably wouldnt work and could lead to the loss of data in the wallet or the corruption of the wallet if the bitcoin client crashes while it is writing to the wallet.
Does every address need an fsync? It seems that just fsyncing after key/wallet operations would be more than acceptable. Can the address cache fsyncs be batched into blocks of 1000 or something?
With OS X adding addresses is much slower than with Linux: it takes a very long time until it starts fetching new blocks after startup. Note: I'm using an encrypted *.dmg for all Bitcoin data (inclusive debug.log), which could make things more worse.
Just to confirm this as a serious problem (0.3.24-beta, OS X Lion): the difference between Linux and OS X is so big (with OS X it has taken >15min until fetching first block!), that something seems to be buggy.
Try with some revision that is more recent than 24271c542b9a0d6016badf5438fb7e5ff7961ace. This patch reduces db commits when addresses are added.
Addrman (#787) fixes this completely, as it only writes addr.dat asynchonously.
Addrman pulled.