-
Notifications
You must be signed in to change notification settings - Fork 648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constant replaying of blockchain #390
Comments
You may have two object_database directories. Remove them both. (One in data-dir and one in data-dir/blockchain I think.) Will be fixed with #339 . |
This is being run by system service that ensure that working directory for that is |
I have 64 GB RAM on the dedicated server that runs this node exclusively. Its also a new and clean OS installation. Is it not enough? |
64 GB seems OK, but I'm not sure. Anyway you can monitor your server while replaying to find out if it's a RAM issue. |
It never hit the RAM limit and was far from that during the process according to supervisors. Despite that, many things CAN happen during working with high load servers. Does it mean, anything happen wrong, then I will need to resync from zero? |
Check your system logs. "Killed" should be done by another process or the OS, but not the witness_node itself. It's true that a lot of resource is required for replaying, some VPS providers may have daemons kill other high-resouce-consuming processes randomly, but you said you're using a dedicated server, so I'm not sure if it's the case, say, it's still possible you have such daemon running in your server. Ask your hosting providers. |
I have nothing like that. I do manual OS installation for each server. This also does not answer the question why after hitting CTRL+C exactly once and then waiting I need to replay everything from zero? I am administrating around 40 nodes at this moment, still growing in numbers, but BTS is the only one giving me so much issues. Its insane. I also see there were similar issues almost one year ago, not fixed but closed due to its age, ignored. What should I do now? Can the BTS even be stopped for maintenance without need to replay? How? EDIT: |
Sending SIGTERM during normal operation/sync will make the witness_node write its internal database to the blockchain/object_database directory, from which it will be read again on restart. This should work fine except under certain circumstances, like a crash of the OS or a SIGKILL. If that happens (indicated by the "unclean shutdown" message), stop the node, remove the object_database directories I mentioned above, and restart the node with the option --replay-blockchain. The "Killed" message is a separate problem that triggers the first. Like abit said, this indicates that something kills the node from the outside. Typically the reason is running out of memory. To rule that out, use the option --max-ops-per-account=1000 for example, see https://github.com/bitshares/bitshares-core/wiki/Memory-reduction-for-nodes . |
we need to get back into #339 and merge, even if there are cases where the replay is needed the pull have some improves in this subject. |
Currently a full node requires 40GB of RAM, and the number is increasing, I remember a few months back it's 30GB. If need to run |
Is there any documentation for |
Whenever I start my witness node it ALWAYS detects the unclean shutdown and replays the blockchain from zero. What's wrong with the implementation?
I use this command to run it:
Which then always starts with following:
If I close the witness node by hitting CTRL+C (exactly once, then wait), the next time I boot it up, it detects the unclean shutdown. If I let it synchronize to the full extend first , this is what happens:
It goes to 98% every time, and is being killed randomly on that stage, every time. Then, if I start it - "unclead shutdown detected". Why it does not backup the blockchain at all? Is there option to remove this "unclean detection"? What can I do? Witness node is unusuable for me right now.
I use Ubuntu 16.04 for that.
The text was updated successfully, but these errors were encountered: