Anything to be done about armoryd's crazy memory usage? I'm seeing 41GB virt and about 6GB residual. It's causing other processes to start swapping. It is done scanning blocks, this is persistent memory usage. In comparison, bitcoind only uses about 55MB residual.
Restarting the process causes the memory to go down, but then armoryd starts eating up CPU and filling up again. It continually is using the lion's share of resources on the system.
Upcoming DB changes will reduce the memory footprint. For now you should manage BitcoinQt manually so that you can restart Armory after a full rescan without having to restart Core. |
|
|
|
"f9 be b4 d9" are the first bytes, I think that may have just been a weird bug in Armory
It's possible Armory looked at the file right when Core created it but before anything was written to it, so it read a bunch of 0s instead. |
|
|
|
|
Look at the file content yourself, is it leading 0s?
|
|
|
|
|
Don't mess with the permissions. This error means the auto path detection believes your blockchain data is in '/Users/me/Library/Application Support/Bitcoin/'. Apparently the user you are logged under does not have permissions to create that path.
The fix is to force your Bitcoin path with the --satoshi-datadir argument.
|
|
|
|
Do you mean I have to rebuild bitcoind, or armory, or both?
Both I have a backup of partially completed armory database, can I try to continue at that point?
Yes Or, would you mind to share a completed bitcoin and armory database with me?
It's 92GB. Maybe we'll bootstrap the entire DB on our torrent boxes one of these days. Again, considering the speed of your machine, I'll be done with the DB changes before you are done scanning supernode, and then you'll have to restart from scratch. |
|
|
|
I have the same "Header heigh&dup is not in BLKDATA DB" error at block 284920. I'm building a supernode and it took me more than a week to reach this height. Certainly I don't want to do it all over again. What should I do?
"Header heigh&dup is not in BLKDATA DB" -> Is this the error you are getting? This means your blk files are missing this one block. There is currently no mechanism to fix that kind of error in the code. You would have to rebuild and rescan. The new DB code is right around the corner anyways, and you will have to rebuild with that too. Among other things supernode will be a lot faster, but you should still stay away from that if it takes your machine a week to get through 50% of the blockchain. |
|
|
|
|
--satoshi-datadir="d:\data\bitcoincore\testnet3"
This is what you need if you want testnet to work. You should ignore the testnet part in the trouble shooting page. I guess it's confusing, we should change that.
|
|
|
|
So they tell me my database is corrupted and I need to rebuild but amory still wont get past the scanning 99% blocks deal so I cant do that
what other options do I have ?
Then factory reset |
|
|
|
|
why are you pointing Armory to d:\data\bitcoincore when you are using tesnet?
|
|
|
|
I'm running armoryd.py in supernode mode (on Linux) but it is scanning very slowly. I want to add some RAM but can't do that without interrupting the scan. How could I stop it gracefully?
There is indeed no command for that. We'll add one. For now you can just SIGTERM armoryd, the DB is resilient to that. |
|
|
|
So, how does this work? Who can program plugins? Only Armory-devs, or anyone?
Anyone can make plugins, but they will only run on stock mainnet Armory if we have signed them. You can modify the source to add your own public key to the list of trustees if you want to run plugins someone else signed. I don't think we added an option in the UI for that yet, I'm not sure if we are going down that path. I think the internal talk was to sign trusted 3rd parties' key with ours so they can do their own plugin dev, and revoke privileges through the announcement system in case someone goes rogue. You should really ask etotheipi or Circus_Peanut for details, I wasn't part of this development effort. All plugins run unsigned on testnet. Sorry for the doublepost.
Debian 64bit Wheezy here, I just upgraded both bitcoin-cli and Armory. Both via git and compiling. Armory master branch.
Armory takes hours to do "Blockchain Optimizations" or the like, then hangs at 175497 blocks height. Shutting down takes endlessly, until I re-close. Next startup same symptoms.
I read that happened to other(s) already, couldn't find a solution to this?
I already reset the blockchain on Armory.
Armory: 0.93.1
Bitcoin-cli: "version" : 100000, "protocolversion" : 70002,
Is there a known fix already? Or shall I provide logs and all?
Thanks,
Ente
I'd prefer log files one way or another. Do you have another copy of the blockchain you can sink Armory with? It sounds like missing block data in Core's raw files. |
|
|
|
|
Actually, the reworked ZC handler could accommodate for this kind of behavior. I'll look into it eventually, once the coin control is completed.
|
|
|
|
Whoa, that's a lot of cool stuff in the works!
I'm waiting for the new wallet format the most.
Except, well, is the addon/plugin-feature in the race too?
Ente
It's been up and working since 0.92.x afaik. We just don't have anything for main stream use yet, and plugins can't run unsigned on mainnet, only testnet. The first real production plugin may just be an arbitrary history lookup for supernode. |
|
|
|
|
Turn off bitcoind auto management in File -> Settings. Run BitcoinQt manually. If the problem persists (and I expect it will), it means something is off with your machine.
|
|
|
|
And not the new wallet format? You guys are doing a lot of releases soon by the looks of it. I thought python 3 and qt 5 (and gitian...) were also on the table?
Each one these features is developed in parallel and will have its own separate release version. They are all significant changes under the hood and we won't be releasing them together in order to minimize the bug search effort that follows a new version. As for the release order, it's a matter of which major change is ready first. I think I'm ahead of the race with the DB changes but that may not hold true in the upcoming weeks. Doug is on Gitian, and Alan is on the new wallets, our new guy (he doesn't have a forum handle yet I think) is on Py3/Qt5. He's got other priorities though, so he's kinda out of the race for now. Place your bets =P |
|
|
|
It's an extension of the previous work (apparently).
It is. It will also be faster and more stable thanks to some simplification in the architecture. Hope it makes it into 0.94, looks like there's alot to get into that release. It's the basis for that release actually. |
|
|
|
|
Make a ticket, add your log files.
|
|
|
|
It's an extension of the previous work (apparently).
It is. It will also be faster and more stable thanks to some simplification in the architecture. |
|
|
|
i'm getting this in the Armory Dashboard:
There was an error starting the underlying Bitcoin engine. This should not normally happen. Usually it occurs when you have been using Bitcoin-Qt prior to using Armory, especially if you have upgraded or downgraded Bitcoin-Qt recently. Output from bitcoind:
StdErr:
bitcoind: ./db/dbformat.h:99: leveldb::Slice leveldb::ExtractUserKey(const leveldb::Slice&): Assertion `internal_key.size() >= 8' failed.
Start BitcoinQt manually and see what it has to say for itself. Most likely it's DB is corrupt and it will ask to reindex the blockchain. |
|
|
|
|
Show Posts
