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…
1 Like
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)
1 Like
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
Thanks
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)
Hi, BR,
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…
Depends on the test. NIS tests will fail while servant tests (if servant is already started) will most likely pass.
Yes, no problem.
Yes that is very possible and does happen. But since everyone needs to restart once in a while, it levels out.
change ip 78.47.48.110 to 116.203.42.162
Yes, working on it to get it up again.
1 Like
Something wrong with measurement again? Round #4778 failed in my case (just) under “Balance” section - but balance is ok, of course…
1 Like
Will look into it on weekend.
Great, thanks, BR, I can confirm that (this additional) payout has been already delivered. Anyway, could you look also for round #4795, please? My node failed here under (and just under) “Height” item, which is weird as well…
That has nothing to do with Master or local NIS failing. Probably your node was doing a garbage collection and was unavailable for a short time. This happens to every node once in a while and therefore the payouts will level out in the long run.
Ok, thanks for explanation. Is it possible to make the garbage collection process more efficient / faster - e.g. with tuning -Xms / -Xmx parameters in java (during the start of NIS) ?
Well, I think G1GC is the garbage collector that has less “stop the world” events. But even with that one some times full garbage collections are necessary and those events bring the server to a halt for 15 seconds (depending on how much ram your server has).
So the bigger memory the faster that garbage process could be ? So it’s good idea to try to increase -Xms (initial heap) and especially -Xmx (memory allocation pool), if I have some other part of whole RAM still available ?
No, the more memory the server has, the longer it will take until the first full GC occurs, but the full GC will also take longer since more memory means more work doing a full GC.
I don’t know what influence the Xms param has on the full GC timing. I personally always set Xms equal to Xmx.