Bitcoin Forum
April 27, 2024, 02:18:32 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Extremely long engine initialization, v 0.95.1  (Read 2306 times)
dlasher
Sr. Member
****
Offline Offline

Activity: 467
Merit: 250



View Profile WWW
December 02, 2016, 08:40:27 AM
 #41


Been having a hell of a time the last week trying to get Armory to start.. Same symptoms, taken the same steps as others, still haven't been able to get it ever "complete" so I could move coins around.

FWIW, even with the suggested command line switches, ArmoryDB still uses 100% of the system RAM within 60 seconds.

Running on a 8 core 32G machine, all SSD.. shouldn't be this bad.

Running Bitcoin-QT/BitcoinD on their own, just fine, current and up to date on the block count.
ArmoryDB.exe --db-type=DB_BARE --ram-usage=1 == ram flatlined, sits on Organizing Chain a *LONG* time.. have waited a couple times then it's building TX -- FOREVER.

Once I get my coins out, I'm not -ever- running Armory again. To have to dedicate 2x the blockchain size just to run the client is unreasonable. 200G of SSD, 8 cores 32G to run a wallet?






1714184312
Hero Member
*
Offline Offline

Posts: 1714184312

View Profile Personal Message (Offline)

Ignore
1714184312
Reply with quote  #2

1714184312
Report to moderator
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- Greg Maxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714184312
Hero Member
*
Offline Offline

Posts: 1714184312

View Profile Personal Message (Offline)

Ignore
1714184312
Reply with quote  #2

1714184312
Report to moderator
Holliday
Legendary
*
Offline Offline

Activity: 1120
Merit: 1009



View Profile
December 02, 2016, 08:59:24 AM
 #42


Been having a hell of a time the last week trying to get Armory to start.. Same symptoms, taken the same steps as others, still haven't been able to get it ever "complete" so I could move coins around.

FWIW, even with the suggested command line switches, ArmoryDB still uses 100% of the system RAM within 60 seconds.

Running on a 8 core 32G machine, all SSD.. shouldn't be this bad.

Running Bitcoin-QT/BitcoinD on their own, just fine, current and up to date on the block count.
ArmoryDB.exe --db-type=DB_BARE --ram-usage=1 == ram flatlined, sits on Organizing Chain a *LONG* time.. have waited a couple times then it's building TX -- FOREVER.

Once I get my coins out, I'm not -ever- running Armory again. To have to dedicate 2x the blockchain size just to run the client is unreasonable. 200G of SSD, 8 cores 32G to run a wallet?

Armory doesn't reproduce the entire block chain anymore, so the first clue that something is wrong with your set up is that you are using 200GB of storage (the block chain is currently about 90GB).

I recently did a clean install (no wallet) of Armory on a 12 year old PC with a Q6600, 4GB of RAM, and an 120GB value tier SSD. It was synced and running in 15 minutes (I already had the block chain since I run a full node).

Have you posted your log files? That's the first step in getting informed help on this sub-forum.

What I find unreasonable is people who have certain expectations when dealing with the block chain and the software surrounding it. 90GB is a sizeable amount of data to work with on home PCs with countless combinations of hardware. If you want the security that comes with having a local copy of the block chain, you have to expect some trade-offs. These devs (Core and Armory) are providing users with free software that is capable of protecting large sums of money. While the software may not run perfectly every time for every user, after some basic troubleshooting, usually the problem can be found.

If you aren't the sole controller of your private keys, you don't have any bitcoins.
goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 02, 2016, 09:14:28 AM
 #43

FWIW, even with the suggested command line switches, ArmoryDB still uses 100% of the system RAM within 60 seconds.

1) Please don't hijack somebody else's thread, create your own and post your log files.

2) There is a difference between allocated memory (malloc) and mapped files (mmap). The usage figures show you total RAM load, but the distinction is significant: allocated memory belongs to the process while mapped files boils down to hinting the OS that you want these files cached in RAM for faster access. Mapped memory does not prevent new allocations, it simply uses otherwise free resources to speed up I/O.

You are better off documenting yourself on these topics than just jumping to conclusion. Armory has been using this model for nearly 3 years now.

3) This is an open source project, feel free to submit code if you have a better solution, or at least participate to the testing phases and provide constructive feedback and bug tracking.

dlasher
Sr. Member
****
Offline Offline

Activity: 467
Merit: 250



View Profile WWW
December 02, 2016, 04:03:28 PM
 #44

1) Please don't hijack somebody else's thread, create your own and post your log files.

People providing data about about the same problem isn't a hijack, it's an attempt to help find a solution to a problem.

2) There is a difference between allocated memory (malloc) and mapped files (mmap). The usage figures show you total RAM load, but the distinction is significant: allocated memory belongs to the process while mapped files boils down to hinting the OS that you want these files cached in RAM for faster access. Mapped memory does not prevent new allocations, it simply uses otherwise free resources to speed up I/O.

You are correct, I misread it.. it hammers the machine so hard it -acts- like it's completely out of ram and into swap.



3) This is an open source project, feel free to submit code if you have a better solution, or at least participate to the testing phases and provide constructive feedback and bug tracking.

True.

I hope you understand peoples frustration here...a product, free or not, they've been using, has become, for whatever reason, impossible to use, monopolizing their machines, and most importantly, holding their BTC hostage.

Speaking of which, after another over-night run, the client finally appears happy and caught up, except all the wallets have zero balance. Rescan gave zero change.

help?
goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 02, 2016, 09:16:43 PM
 #45

1) Please don't hijack somebody else's thread, create your own and post your log files.

Your problem is different from the OP's. You also didn't post your log files as requested.

Consider that for each vocal user seeking help here, there is a silent majority that parses these threads and fix their setup on their own. Isolating each issue in its own thread enhances search results and readability.

Quote
You are correct, I misread it.. it hammers the machine so hard it -acts- like it's completely out of ram and into swap.

In this case Armory is allocing <1GB memory but caching its reads in whatever left over RAM (mmap memory does NOT spill over the swap). This in turn reduces the load on your SSD, as this data is read over several times. As for the SSD load, there's some 90GB of data to process at this time. It will have to be read one way or another.

I don't particularly care to change your appreciation of the code. This is more of an informative point for the silent majority. You obviously made your opinion of me before you started posting.

Quote
I hope you understand peoples frustration here...

Do you understand mine? This project went from being funded, with 6 full time developers and 2 interns, to getting bombed and leaving me working on it alone, out of my pocket. There was not even a plan to further development of the FOSS version past 0.93. Armory would be nowhere if I didn't volunteer over a year of my time and money to keep it going. And with that I have to catch up on the technological debt cumulated over 2 years FOSS development stagnation.

Imagine my joy when people who did not participate to the testing phases, provide no feedback or code reviews, let alone contribute some code or help with maintaining the webpage, inaugurate their first post in this forum will all spite and venom.

But at any rate, this path doesn't really achieve anything. Reread yourself. Then put yourself in the position of the people that could help you. Do you really think your post did anything but deter them from helping?

Quote
a product

This is not a product but a project. It's always in development, always trying to get better, always in need of feedback, testing and code reviews. This is also beta software that you run at your own discretion. You are approaching this from an entitled perspective. The Bitcoin world will be full of bad experiences if you stick to that view.

Quote
free or not

Wrong again. A "free product" still has a monetization scheme. You may not be aware of it, but it is still there. Facebook and Google data mine you. Youtube feeds you advertisement. Free to play games come with micro transactions and pay to win schemes.

With Armory, there is none of that. There was quite a push under ATI to go down that path, but under my rule it has strayed as far as possible from this path, to deliver the leanest solution possible. The first I did was to get rid of the phone home code, which was intended to track user statistics for revenue projections and attracting new investors.

Quote
has become, for whatever reason, impossible to use, monopolizing their machines

Jesus... try syncing 0.93 with the current chain, let's talk again after.

Quote
and most importantly, holding their BTC hostage.

Your coins are not being held hostage. Your private keys are in your wallet, free for you to use. You can access them anytime with offline Armory, with versions as old as 0.90. Your private keys are your coins. Armory is a framework among others that deploys services to interface with the bitcoin network. Why do I even bother trying to explain this...

Quote
Speaking of which, after another over-night run, the client finally appears happy and caught up, except all the wallets have zero balance. Rescan gave zero change.

What is the address chain length on your wallets? Did you restore them from a paper backup before syncing 0.95? Try extending the address chain in offline mode before rescanning. Also, what is the top block displayed in the bottom right? Log files would go a long way.

dlasher
Sr. Member
****
Offline Offline

Activity: 467
Merit: 250



View Profile WWW
December 02, 2016, 10:23:46 PM
Last edit: December 02, 2016, 10:41:52 PM by dlasher
 #46

Sigh. Thank you for continuing to maintain Armory, hadn't realized the tribulations.

Sorry to hear your tale of woe, Mine is far simpler.

Life happens, been busy, haven't touched BTC in about 12 months. Consolidating coin. Forgot about Armory wallet with big pile of coin in it. Start Armory 0.91, too old, needs bitcoin/etc updates, Update, hangs/crashes repeatedly. Backup wallet (digital, unencrypted), remove all traces of Armory, install fresh, import wallet, have repeated troubles with 0.95.1 taking forever to start, like others in this thread. Failing to start at all, like others in the thread, but I've been trying for a week..

.. and here we are.

What is the address chain length on your wallets? Did you restore them from a paper backup before syncing 0.95? Try extending the address chain in offline mode before rescanning. Also, what is the top block displayed in the bottom right?

Been all over the client, in expert mode, can't find the "address chain length", either where to change it, or extend it.

I do see a decent amount of "-ERROR - 1480706621: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in processDataStackThread: invalid header size" in the ArmoryDB console however. I'll work on getting you logs. Pastebin ok?

Block count in lower right corner is: {will update once we're not OFFLINE again from restarting the client to get to expert mode}


goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 03, 2016, 12:21:33 AM
 #47

Quote
Been all over the client, in expert mode, can't find the "address chain length", either where to change it, or extend it.

There's a clickable figure in the wallet's properties dialog next to "Addresses Used", in export mode.

Quote
I do see a decent amount of "-ERROR - 1480706621: (..\BitcoinP2P.cpp:865) caught BitcoinP2P_Exception in processDataStackThread: invalid header size" in the ArmoryDB console however. I'll work on getting you logs. Pastebin ok?

That's benign. Still, pastebin your log file.

ToF (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
December 03, 2016, 10:33:17 AM
 #48

It *almost* worked for me in the end, but it crashed at the armoryDB.exe part still. I reinstalled Armory and without wallet it worked, then when I imported the old wallet it happened again after trying to sync.

So i thought maybe the blockchain got corrupt (Bitcoin Core was synced but there were no wallets in it). Anyway, I am now running Bitcoin Core getting fresh blockchain. Problem is, it seems it will take at least 10 days to fully sync. Is it normal these days?

I am running it on the NAS and while the CPU and RAM usage is relatively low, the NAS is hammered badly. I can hear its 6 RAID-6 connected HDDs working all the time now. The NAS has write speed of around 100MB/s.

When I was syncing the blockchain on the internal SSD, the laptop was unusable almost completely.
goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 03, 2016, 02:33:12 PM
 #49

It *almost* worked for me in the end, but it crashed at the armoryDB.exe part still. I reinstalled Armory and without wallet it worked, then when I imported the old wallet it happened again after trying to sync.

So i thought maybe the blockchain got corrupt (Bitcoin Core was synced but there were no wallets in it). Anyway, I am now running Bitcoin Core getting fresh blockchain. Problem is, it seems it will take at least 10 days to fully sync. Is it normal these days?

This is basically your last resort, albeit I can't think of any other issue causing your grief. Your only other solution is to let me SSH/TeamViewer into your machine so I can debug the code directly.

10 days is a bit excessive, but if you have bad connectivity to the network and/or a slow CPU, it will take days. It would prolly take my machine over 12h to sync the full chain now (for info, it builds & scans Armory's DB in 4min total, and I'm on fiber internet).

Quote
I am running it on the NAS and while the CPU and RAM usage is relatively low, the NAS is hammered badly. I can hear its 6 RAID-6 connected HDDs working all the time now. The NAS has write speed of around 100MB/s.

When I was syncing the blockchain on the internal SSD, the laptop was unusable almost completely.

Since the headers first change in Core, the chain data commit is random, which will grind a HDD to a crawl. The process is very CPU intensive too, courtesy of ECDSA. It will routinely max your cores.


ToF (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
December 03, 2016, 02:56:14 PM
 #50

Quote
10 days is a bit excessive, but if you have bad connectivity to the network and/or a slow CPU, it will take days.

That's the part I do not fully understand - the CPU is not weak as we discussed before, it's a Core i7, albeit a laptop version in a relatively old Lenovo Thinkpad T520 with 8GB RAM and my Internet connection is 240/25Mbps cable - although I can get only around 180Mbps due to old router but that's more than good still I suppose.

I mean, it does not feel like it's broken, it's definitely syncync as the NAS is basically unusable now and working on the laptop is a pain. It's just slow. Extremely slow. Couldn't perhaps Windows Defender or firewall be interfering with the process?

I can also test it on a game rig I have access to (ex-BTC mining machine, though upgraded to a very fast core i7 4790K with 16GB RAM).
TomPlatz
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
December 04, 2016, 02:53:23 AM
Last edit: December 04, 2016, 03:24:08 AM by TomPlatz
 #51

Hello everyone,

I used Armory for the last time several months ago, a few days ago I launched it again, version 0.93.x which is now upgraded to the latest 0.95.1.

The problem is, it has been initializing the engine for days now! I do realize there is a lot of new data to download, but it's crawling and I have very fast connection. I do see new block files are being downloaded so it's not stuck. Just very very slow.

Any idea what could be causing this? The OS is Windows 7 64bit with 8GB RAM and Core i7 (albeit an older laptop version).

Thanks!

Tomas


I start Armory every day and I had my version .93 stuck on "Initializing Bitcoin Engine" 4th December 8 hours after I had shut it down the night before, never been initializing for so long so I thought maybe it is because it has something to do with the new version and I should get it.
So I did and still the same.
I wish the initializing stage would tell us that something is in fact happening as we don't know if the rotating icon means it is only looping forever in some hopeless routine.
Fibre internet with plenty of PC grunt.
Not sure what to do with it, have never had to fiddle with it, always shuts down correctly.

Decided to start Bitcoin Core up, it wanted to re-index the whole lot, why would that be ? Not very convenient having to wait "4 years 18 weeks" so I can use it again.
Hoping this is the solution to the Armory problem however.
Has to be a good reason why this can fall over in this way.
goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 04, 2016, 08:51:05 AM
 #52

I mean, it does not feel like it's broken, it's definitely syncync as the NAS is basically unusable now and working on the laptop is a pain. It's just slow. Extremely slow. Couldn't perhaps Windows Defender or firewall be interfering with the process?

I dont recall anyone complaining about that in recent memory. At this point you should ask Core directly.

Quote
Has to be a good reason why this can fall over in this way.

LevelDB is flaky on Windows. It has gotten a lot better with the years but a bad shutdown or basically anything else can completely destroy Core's DB.

ToF (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
December 04, 2016, 03:57:40 PM
 #53

Update: So I installed Bitcoin Core on the other PC I mentioned (Core i7 4790K etc) Yesterday and it's almost finished syncync now, downloaded over 75GB since Yesterday and most of the time the PC actually was sleeping as Windows 10 in their eternal wisdom did not believe Bitcoin Core was doing anything and let the PC enter hibernation.

In other words, on the more powerful PC, connected to the same network as the core i7 laptop, it's exponentially faster. Probably around 15x+ faster...
goatpig
Moderator
Legendary
*
Offline Offline

Activity: 3668
Merit: 1345

Armory Developer


View Profile
December 04, 2016, 07:18:55 PM
 #54

Both pc running against the NAS? Can you post both specs next to each other for comparison?

ToF (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
December 05, 2016, 12:03:20 AM
 #55

Both pc running against the NAS? Can you post both specs next to each other for comparison?

The "Tower PC" was using its main SSD for the Bitcoin database but initially, the laptop PC was also using its SSD (and its faster than the one in the Tower PC) and it was just as slow on the laptop as when using the NAS.

The NAS has write speeds similar to what many people have in their PCs unless they have SSDs, so that's probably not the issue.

One thing I noticed - the Tower PC CPU usage was around 30% and it did not feel overloaded at all. I could browse the net, for example, without noticing any performance degradation. On the less powerful laptop PC, the CPU usage was only around 5-7% according to task manager, but it felt much slower than that. Badly managed hyperthreading maybe?

Really odd.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!