There was some text you asked me to add ending in GC.txt in the nisStart.sh file a while ago, I meant starting NIS without the garbage collector text.
That may be the use of the G1 garbage collector, i can’t tell without seeing the actual nisStart.sh.
Restarting NIS probably already has the GC.txt overwritten, else i could have taken a look at it to see how much your NIS was under pressure memorywise.
Removing the additional startup param for the garbage collector only results in the use of the default garbage collector which is not better.
Increasing memory is probably the best option.
Hi, the additional text at the end of the startup script was as below:
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGC -Xloggc:"./gc.txt"
I presume this is the G1 collector.
Yes. So unless your provider is the culprit of poor computing power results, the only option would be to increase memory.
the problem I think does not fixed yet
Yeah, I observed exactly the same problem - it failed for balance in round #4679 and #4680, even if balance is - of course - right (over 3mio XEM). If this happened (happens) only for a part of supernodes, I hope it will be recalculated for the right reward after solving this issue.
And anyway, about the rewards - I’m still waiting for the payout for rounds #4673-#4676. It should came yesterday (2019-03-14) around 14:00-15:00 GMT, but nothing arrived. Did anybody has the same experience ?
Reason for the failures were that i needed to restart the local NIS on the node rewards master. I will check on weekend which nodes suffered from that problem and issue the missing payouts.
why some nodes had paid at 4677-4680 for 838?
seems stuck at number 167
Are there any recommendations on providers for hosting a node? Preferably ones with pre-configured nodes if possible, I think I vaguely remember ctl.io have a pre-installed supernode server which just requires configuration with your settings. I’ve also seen recommendations of people recommending vultr.
Hi, I do not know if you know the page. Here you have an overview of all used ISP´s (NEM Blockchain).
Thanks, looks like vultr is most popular.
not sure about OS though, seems like there’s a lot of options in vultr, like debian, ubuntu, fedora, centos etc. Thinking of going for the 8GB to future proof it. VC2 $40 per month. Is there still a tutorial available, I used Pauls one last time, not sure if it’s still valid though.
That’s the good thing about Linux, but it also has a few disadvantages.
Everyone has a slightly different configuration.
I think most used ubuntu / debian. . … centos… . . Fedora…etc.
Actually only the main settings(Ports, etc.) are the same, the rest is a question of opinion and comfort…
Here is the list of additional payouts for the nodes that suffered from the NIS restart on the node rewards server in round 4679:
payouts.pdf (89.5 KB)
I can confirm that this payout has been received. Many thanks, BR, for all your work around SuperNodes and rewards program!
There were some balance tests failing in round 4702 due to the local node-rewards NIS doing a full garbage collection. Here are the additional payouts for those nodes:
payouts.pdf (52.3 KB)
The same happened in round 4703
If that happens too often then i guess it will level out in the long run.
This time I am doing the additional payout though:
payouts.pdf (53.8 KB)
short technical question ->
When Supernode is (e.g. after restart/update of server platform) in LOADING CHAIN status, and the measuring will come, will Supernode pass the tests in this while or not ?
When Supernode is in LOADING CHAIN status, is it possible to start servant (./startservant.sh), or is better idea to wait for finish of loading chain and start servant immediately after that ?
Why I’m asking for - now, with ~ 2100000 blocks height of blockchain, is loading chain very slow process - it takes 1.5-2hours, even on strong servers. But on the other hand - sometimes is of course necessary to update and restart server platform under Supernode (kernel vulnerabilities, newer java, etc.). As measuring is happened each ~ 6hours, it should be very easy to “interfere” with updating (and reloading chain) process thru some round of measuring process. And thus is possible to miss the reward due this issue, which is sad at all, of course ;).
Thanks for clarification…