scrobble.life
#steem-pressure

Steem Pressure #5 - Run, Block, Run!

Run, boy, run! They’re trying to catch you.

In the previous episode of the Steem Pressure series, we checked how much time we needed to get a fully functional steem consensus node from scratch.

We also took a closer look at the steemd version v0.19.2 resync and replay performance for 20’000’000 blocks. It was back in the pre-appbase era with the HardFork 19 rules. Time flies, and so do blocks. Recently, our chain has grown beyond 30’000’000 blocks, and this offers a good opportunity to look at the performance once again, especially as we have also seen many important changes in the code.

https://www.youtube.com/watch?v=7IkI6yVvzHIVideo created for Steem Pressure series.

Time needed for replay

We won’t be measuring --resync performance this time, because we want to avoid the bias introduced by external factors such as network latency and the performance of 3rd party nodes. We will focus on the --replay part, using block_log file, which we can get either from a previous --resync operation or we can download it from a another instance or public source. If you want to find out more about the difference between --resync and --replay, feel free to read the previous episode.

Test setup

We have exactly the same machine as in the previous episodes: An entry-level dedicated machine with Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz on an Ivy Bridge with 32GB DDR3 1333MHz RAM and 3x 120GB SSD.

That’s not the configuration I use for my witness nodes, because as a consensus witness that takes part in every round, I’m not going to risk losing blocks sporadically due to high latency. However, that is a perfect test configuration to check the performance of steemd for the purposes of public seed nodes, backup witnesses, state providers, private RPC endpoints for wallets, or even exchanges, as account_history plugin with just one or two tracked accounts has a negligible footprint on the performance.

But why?

If we have all the blocks downloaded to our disk, we have all the data about all transactions that were performed on the Steem blockchain. But at this point we still can’t say how much Steem Power Alice has or how many upvotes Bob’s most recent post about cute kittens received.

We can’t until we check (replay) every block since The Genesis. That’s the only way to validate the current state of Steem.

Every three seconds, one of the witnesses signs a new block (head block) with new transactions making the whole process increasingly difficult.

Speed does matter

When you can’t replay fast enough to catch up with the current head block in a reasonable time, you are doomed.

Of course, you can rely on your state providers, snapshots, etc., but whenever you run out of reliable copies of the reasonably recent state (due to software or hardware failures), or whenever new features are introduced, you have no other choice but to replay.

When something unexpected happens

Back in September, after an unexpected event caused by a bug, we were forced to replay with the fixed code. That’s where the ability to replay the whole blockchain from scratch in less than 4 hours and multiple high-end servers at your service pays off. Especially when you need to do that multiple times. I started producing again at block 26038153 (one hell of a block!), soon after we got back to a fully operational status. There were no transactions going on between 12:47:00 and 19:56:51 UTC. And it could have been much worse.

Benchmarks

v0.19.2 - pre-appbase, 20M blocks, 2018-02-19

In the previous episode, we were able to replay 20M blocks in 145 minutes.

Replay v0.19.2

v0.19.12 - appbase, 25M blocks, 2018-08-12

There were a number of optimizations to improve reindex performance. With appbase based steemd v0.19.12, we were able to replay 20M blocks in 121 minutes and reach the 25M block mark in less than 5 hours.

Replay v0.19.12

v0.20.9 - Current version, 30M blocks, 2019-02-02

The current version of steemd is even faster. Despite “Reconstructing Block Log Index..” itself takes over 6 minutes longer, we were able to replay 20M blocks in 115 minutes, reach the 25M block mark 25 minutes earlier than v0.19.12, and replay 30M blocks in less than 8 hours (7h38m)

Replay v0.20.9

Replay speed

speed.png

Replay speed, measured at 100k block intervals never drops below 324 blocks per second, and the last 1M blocks replay at an average speed of 454 blocks per second.

Summary

Replay v0.19.2 v0.19.12 v0.20.9
20 M blocks 145 min 121 min 115 min
25 M blocks n/a 297 min 272 min
30 M blocks n/a n/a 458 min

Paying attention pays off

By paying attention to performance, we are able to identify and resolve issues that, if underestimated, may prove silent killers and endanger the reliability of our platform in the long run. One of such incidents I detected during appbase development was a witness plugin that caused significant resync performance degradation

Upcoming improvements

We are nearing 50GB of state file size for a consensus node. As you can see, with the current architecture, that is difficult for servers with “only” 32GB of RAM. I’m looking forward to the MIRA release. My preliminary benchmarks of MIRA branches are far from being optimistic, but Steemit Inc team updates say that MIRA jest under heavy development / optimization phase; a lot of effort is being put into making it replay in reasonable time, but the advantage would involve robust access to the state in low memory conditions.

Previous episodes of Steem Pressure series

Introducing: Steem Pressure #1 Steem Pressure #2 - Toys for Boys and Girls Steem Pressure #3 - Steem Node 101 Steem Pressure: The Movie ;-) Steem Pressure #4 - Need for Speed

Stay tuned for next episodes of Steem Pressure :-)

Bonus: Inspiration for the title

https://www.youtube.com/watch?v=lmc21V-zBq0“Run Boy Run” - Woodkid, The Golden Age


If you believe I can be of value to Steem, please vote for me ([**gtg**](/@gtg)) as a witness on [Steemit's Witnesses List](https://steemit.com/~witnesses) or set ([**gtg**](/@gtg)) as a proxy that will vote for witnesses for you. ***Your vote does matter!*** You can contact me directly on [steem.chat](https://steem.chat), as [Gandalf](https://steem.chat/direct/gandalf)
[Steem On](/)

Comments · 22

  • @danieldedosd2(71)· 2680d

    Excelente amigo, gracias por subir cosas como estas...

  • @jacuzzi(75)· 2681d

    Interesting post! A long term goal of mine is to set up a Witness server as well. lol, tho its a log ways off for me at this time... for not its just slow going. I do enjoy however reading about others who are Witness's and what they are doing. Keep up the good work and I hope one day we can Witness together! YEA~

  • @trincowski(72)· 2681d

    Hello there, @gtg!

    I've seen you around, helping some people who were unjustly attacked... I'd like to ask for your assistance recovering this this new user, who was flagged for no reason whatsoever.

    https://busy.org/@maxsieg/protecting-free-speech-on-steem

    https://busy.org/@maxsieg/nazi-volkswagen-und-seine-heutigen-konzentrationslager

    https://busy.org/@maxsieg/silencing-journalists

    https://busy.org/@maxsieg/us-politics-is-victim-to-bad-journalism

    He joined 3 months ago and he's already being attacked simply for reporting on sensitive topics. This way, Steem will be left behind.

  • @elsiekjay(77)· 2681d

    @gtg, have you considered using auto voter instead of sitting on all that VP?Or perhaps delegation? I could really use one of the 2. I am a fulltime steemian mostly focused on dtube, steemhunt & steempress. I know we are not acquainted (yet), but would you please put me into consideration?

    Sincerely, Elsie.

  • @dalz(81)· 2682d

    Enjoyed the song :)

  • @clixmoney(78)· 2687d

    Thanks a lot for this report, I also wrote a report about how I've reached the reputation 70. I included you as well because I'm voting for you as a witness all this time. Thanks for being so valuable to steem.

  • @nasiruddin694(47)· 2692d

    Sir give me 100% upvote in my post to helping homeless children

    Posted using Partiko Messaging

  • @steemitboard(66)· 2702d

    Congratulations @gtg! You received a personal award!

    Congratulations! You've been among the most infectious people during the April Fools' Steem Plague in 2019! organized by @suesa

    You can view your badges on your Steem Board and compare to others on the Steem Ranking

    Vote for @Steemitboard as a witness to get one more award and increased upvotes!
  • @king-of-disease(51)· 2704d

    You have been infected by the King of Disease!

    Will you quarantine yourself?

    Or will you spread the plague?

    King Of Disease

  • @arcange(79)· 2704d

    Damned, I got infected by a Steem virus. Sorry to !sneeze at you 😪

  • @blockchainstudio(72)· 2710d

    Thanks and I've just voted for you :)

  • @steem-bet(63)· 2712d

    Dear gtg:

    We are SteemBet, the next generation STEEM based gaming platform. We are honored to invite you to join our first fantastic dice game, which is just the beginning of SteemBet game series. Our dividend system has now launched. The prize pool has already accumulated 2,000 STEEM and more than 60 players have participated in staking mining token SBT. A huge reward of 40,000 STEEM is awaiting! Join us NOW with other 500 STEEM users to loot HUGE dividend reward!!

    SteemBet Team

    Official Website https://steem-bet.com

    Discord Server https://discord.gg/95cBN3W

    Telegram Group https://t.me/steembet

  • @glenalbrethsen(71)· 2723d

    I can see that replay speed, as important as it may be now, is going to be even more so as we get into 100 million blocks, not to mention 1 billion, etc. I know it's a ways off at our current rate (I guess things would change if we had a significant increase in user activity), but is that something these current modifications are going to help with, especially when our rate of block creation is running at twice or thrice the speed it is now? So, basically, we'll have storage issues unless we can continue to compact things, and/or speed replay issues, right?

    Also, I'm wondering, if I'm reading this correctly—in v. 0.20.9, there appears to be a difference of 157 minutes between replaying 20 million blocks and 25 million blocks, but it's up to 186 minutes between 25 to 30 million blocks. Did the blocks get heavier with more transactions between 25 and 30, or is there something else at play?

  • @hidemi(61)· 2723d

    @gtg, long time no see. 😊 Thank you for following and upvote!

    I look forward to seeing you again.

    Posted using Partiko iOS

  • @hidemi(61)· 2723d

    @gtg, long time no see. 😊 Thank you for following and upvote!

    I look forward to seeing you again.

    Posted using Partiko iOS

  • @tuhinahmef(11)· 2725d

    I like your post,steemit noline income is very good line.

  • @pennsif(77)· 2725d

    This post has been included in the latest edition of SoS Daily News - a digest of all the latest news on the Steem blockchain.

  • @nervi(64)· 2726d

    Thank you @gtg for improving this great blockchain

    Posted using Partiko Android

  • @rishi556(72)· 2726d

    Wondered what you meant when you said that the block was one hell of a block. Checked it out on steemd. WOAH, (https://steemd.com/b/26038153), 70K virtual ops.

  • @justinw(63)· 2726d

    Thanks for doing this @gtg - very cool to know that replays are faster than ever before.

  • @anmitsu(57)· 2726d

    Ahahaha are you watching Umbrella Academy too? Pretty sure that track was used there

  • @yakubenko(73)· 2726d

    Good job! I like the way you feel about work. Unfortunately, I didn’t understand so much, because I don’t understand much, and there are still problems with English))) Good job, buddy !!!!!!!!