This has been mentioned in many discussions. I don't know if it's been posted here by someone.
I think you know what I'm talking about, so no basic tutorial here. I'm running the node in Linux.
Background:
The steemd v0.16.0 release is built on ChainBase library, which primarily brought disk IO issues if running with default settings, even with the kernel parameter tweaks recommended by the dev team in the release blog.
To get around those issues, the best practice (IMHO) is to keep the "shared file" data in memory. The second best is to use the swapping system provided by the OS which has better performance than storing that data on disk directly (by default).
Requirements:
- For low memory nodes, best to have more than 12GB of free RAM, if not, use some swap space, for example 6G RAM and 6G swap
- For full nodes, I have no experience, so try it yourself, or perhaps others will tell you.
How-to:
# change the size of /dev/shm
sudo mount -o remount,size=10G /dev/shm
# run steemd
./steemd --shared-file-dir /dev/shm/
From my experience, with a good block_log file (pre-downloaded or synced), it takes about 10 minutes to finish replaying on a low_mem node. If sync from scratch, it's expected to take less than a hour.
//Edit 1:
When I was saying "low memory node", actually additionally I mean only the "witness" plugin is enabled, aka in config.ini you have:
enable-plugin = witness
but not (by default):
enable-plugin = witness account_history account_by_key
//Edit 2:
A low memory node now need around 8GB space for the shared file, so it's safe to set the file size to 9GB so far (in config.ini, listed below). By default the limit is set to 32G, but it's not fully pre-allocated, so shouldn't matter if not change it. Usually I set it to 12G.
shared-file-size = 12G
//Edit 3:
If you forgot to change the enable-plugin setting at the first place, you may run into Bus error which will crash the node. In this case, you need to restart steemd with --replay parameter:
./steemd --shared-file-dir /dev/shm/ --replay
Not to bother with a basic question but what are the advantages of running a node? From my basic understanding for a node to profit it must be voted as a witness? I have some serious hardware at my disposal and static public IP's that could be used. Just need some literature on what the situation is if you have any links it is appreciated. I messed around in the github to get an understanding of how to run things locally in case the actual site went down. That is as far as I have gotten. Thanks!
It's true that not everyone need to run a node. Witnesses and standard miners need to run nodes. And yes you get the point, you can run things locally (although I haven't tried to run a GUI locally, others do). Profitable or not is another topic. In regards to links, I'm not sure what you are looking for exactly, perhaps you can join https://steemit.chat/ and ask in #witness or #dev channel.
Thanks, will check it out!
Good info!
Thanks for sharing.
Shared on twitter
Disclaimer: I am just a bot trying to be helpful.
Thanks.
Thanks for posting this.
There are no posts about this at all.
It doesn't work for me, though.
Steemd still tells me 30G memory free (That's on the main partition)
The messages about "30G memory free" doesn't matter. Check whether the files are created in /dev/shm by commands:
ls -al /dev/shm/ du -hs /dev/shm/Yeah, I think they were being created.
It also went a lot faster.
After 85% it crashes now.
That usually means you ran out of available space on whatever file system is holding the shared data file. If you are following @abit's directions that would be /dev/shm. You need to make sure you have enough RAM and/or swap space and have used the remount command to enlarge it.
BTW, on Ubuntu Linux (and probably others) /dev/shm is not a mounted file system, it is a symlink to /run/shm.
I don't think remount on /dev/shm will work, but I'm not 100% sure.I do the remount on /run/shm instead. EDIT: remount on /dev/shm appears to be okay; mount follows the link.I guess it's OK to remount /dev/shm, from my test:
$ df -h /dev/shm Filesystem Size Used Avail Use% Mounted on none 10G 144K 10G 1% /run/shm $ sudo mount -o remount,size=11G /dev/shm $ df -h /dev/shm Filesystem Size Used Avail Use% Mounted on none 11G 144K 11G 1% /run/shmI guess mount follows the link. I will edit.
Thank you.
I tried a few different sizes for RAM and swap.
I will try to remount /run/shm/ instead.
Could this also be related to this ?:
source: https://steemit.com/steem/@steemitblog/steem-0-16-0-official-release
It is related in that the settings given there are trying to address some of the same issues. The approach outlined by abit here works better.
I have:
Still crashes with Bus error.
I appreciate the help.
Didn't work so far.
I also tried the kernel settings @steemitblog suggested ...
Didn't change the error.
After you changed the
enable-pluginsettings in config.ini, you need to run with--replaylike follows:Also you can check if the disk is full:
df -h /dev/shm///Update: after further investigation, we found that @felixxx's issue is caused by a typo when running the
mountcommand, so the size of/dev/shmremained unchanged (too small), so unable to allocate new space. Here is the tip: no space after the comma, and, just copy & paste.But how to use the cli_wallet after disabling account_history and account_by_key?
You can probably still use most of the functions but you won't be able to use list_my_accounts or get_account_history
account_by_key doesn't use a huge amount of memory, so you can leave it enabled if you want. account_history does use a lot of memory, but you can eliminate almost all of that usage by only tracking your own account with
--track-account-rangeHowever, if you are running a witness node (signing blocks) you should not use any extra plugins, even these. Better to run another node for wallet purposes if you need it.
Ah. Ok. Thanks for the info.
smooth...
Not a change. I created a withdraw route that sends 87.5% of it back to vesting, so the net power down rate is the same as before (actually slightly lower) and I'm not, at this time, taking advantage of the higher rate, nor do I have any specific plan to do so.
But I have reevaluated the situation and I'm keeping my options open at this point, especially given that many of the important concerns I and others expressed elsewhere in the comments to that same post and others on the topic (e.g. implementing the economic changes unnecessarily abruptly and not phasing them in, too many changes at once, bundling the economic changes with immature chainbase code, etc.) not having being addressed. Overall I am supportive of the path that was taken, so far, but we will have to see how things turn out.
Good info. I have a question: Are there any way for send founds programatically without run your own node? Thanks!
You can use
cli_walletto connect to a public websocket server, for example (https://steemit.com/steemws/@jesta/steem-ws-the-public-steem-api-cluster):Then connect to the
cli_walletwith your own program.You can also use piston (https://piston.readthedocs.io/en/stable/).
Oh, thanks you very much! What noob that I am...
This post has been linked to from another place on Steem.
Steemit Bergbau #2 by @deutschbot
Fighting Steem Daemon #5 by @felixxx
Learn more about and upvote to support linkback bot v0.5. Flag this comment if you don't want the bot to continue posting linkbacks for your posts.
Built by @ontofractal
I was getting this error as well, figured it out two days ago but wish i seen your post earlier.
Thanks for the great info this should help many people out.
Is it posible for adapting SSD ?
Performance of v0.16.1 and later is much better already, so I guess SSD would be OK, although I'd still prefer RAM.
With v0.16.0, SSD of dedicated server would be OK, but not as good as RAM. Most VPS's aren't with full-powered SSD due to resource shrinking/limiting, so it was not an option.