will running multiple instance of STEEM,MUSE,BTS on a same VPS cause that bug ?
only if you are using the same port and have too little RAM
What do you base that on xeroc? Sounds like you've spent some time troubleshooting this problem, is that correct?
Well, statement number one: "same ports" is actually quite obvious
because you can only connect to either of the seed nodes and not all of
them. The second statement is more like an estimate. If you run a
BitShares seed/full node you need some RAM. Some more RAM for MUSE and
yet more RAM for STEEM.
If your machine has 32gigs of RAM that should do the trick, otherwise
you will end up with an unresponsive machine.
To clearify, I do not run a public seed node but multiple full nodes on
several machines
Actually from recent experience and observation the one factor that triggers this bug the most is request volume. Before I changed the port I was averaging around 50 connections pretty consistently on all of my nodes. Now it's up to 80 - 90. All but one of my servers are running low RAM, but even with the increased connections RAM use has remained flat without an increase.
RAM depends in fact on the use of BitShares. For instance open orders
are kept in RAM. Once the load in the DEX picks up, so will the
requirments for RAM.
Also, while switching all the nodes to use p2p port 1776 this weekend I had several seeds get stuck for some unknown reason. They've been solidly online for 2 days now, but nothing has changed so I suspect future failures will occur again.
My guess is that there is somethign weird happending after a few weeks
of runtime. And we haven't seen this kind of behavior in STEEM because
their have been plenty of hardforks and restarts.
I added abit's simple bash script to my list of monit tasks so I'll be notified if any of the nodes get stuck. Wackou's seed monitor is also useful for anyone that wants to see the status of all seed nodes. I haven't upgraded my nodes to his latest release of bts_tools yet, but I will soon.
!