Topic: Extremely long engine initialization, v 0.95.1 (Read 2433 times)

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.

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

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...

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


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.

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.

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).

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).


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.

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.

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


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

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.


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}

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.


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.


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?


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.


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.


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


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...


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.

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


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




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?

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.

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.

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?

I have just left prime95 running the Blend test for over 2 hours, no problems at all.

These types of errors have 4 different causes:

1) You are running a same DB folder against different blockchain folders.
2) You are running different versions of the code against the same DB folder. You should get an error output in the console and GUI in this case.
3) You have a bad/corrupted copy of the blockchain.
4) Your machine is unstable.


There is no knowing that without passing an hour worth of memtest and prime95 without errors. If you can actually pass these tests, then consider 3).


The DB code does not use shared libraries, it's all in the one binary. The only possible "left over issue" is using a DB dataset built with a previous version (i.e. 0.94 data vs 0.95 binary).

Unfortunately, no luck. Armory still crashes at the ArmoryDB.exe part. These are the last records in dbLog.txt:

-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1435) Headers DB has no block at height: 0
-ERROR - 1480209973: (..\lmdb_wrapper.cpp:1415) No headers at height 0

Before the command prompt window crashed I also saw error about missing key pairs as before. The PC is really stable, I don't think that's the issue. Perhaps something is left from the old version installation somewhere still?

I am not sure if I am the only person with such problems, though I may be the only person who reported it at the forums but that's a different thing. I am not sure what caused these issues but the PC is actually an extremely stable machine running Windows 7 which I restart only about once a month. There is definitely no malware etc.

The last time I used Armory was the 0.93.x version several months ago and I did not experience any of the issues at all. Of course, there can always be another application or previous installation interfering.

Hopefully it will work in the end.

DB is done building. You have to start the client to scan it now.


People are having issues with upgrading to 0.95 because they do not wipe out the existing DB or use a different dbdir.

The issues you are experiencing are in a whole different class, and you are the only one with these. Surely if this was an in issue with the code, it would have manifested itself several times since April of this year, when 0.94 came out.