Jump to content

r0bertz

Member
  • Content count

    95
  • Joined

  • Last visited

1 Follower

About r0bertz

  • Rank
    Member

Contact Methods

  • Website URL
    http://xrp.ninja

Profile Information

  • Gender
  1. r0bertz

    Robinhood adding crypto

    https://crypto.robinhood.com/ Add yourself to waitlist after opening an account.
  2. r0bertz

    My validator died last night

    xrp.ninja validator is fully operational now. I guess the initial problem was cause by some insane (testnet) peers. It didn't recover after I blocked those peers with iptables. I believe that was because I changed database from rocksdb to nudb and kept using online_delete. NuDB is supposed to be used in full history server since it doesn't support delete. I have attached a picture. That line represents the percentage of uptime that the validator stays in full mode (fully synced). When it stops growing, it will start syncing. My guess is that is when online_delete kicked in. I have no proof though, as of now. Now I have switched back to rocksdb again. Everything is working fine. That line is now asymptotically approaching 100. BTW, I have also changed ledger_history to none. I will changed it back to some positive value. I believe the validator will work fine after that.
  3. I know that. But there are so much more to monitor. I think validators (and validator operators) can compete, on all sorts of metrics. Blindly trusting institutions is naive.
  4. r0bertz

    Block insane peer?

    I created another custom metric for how much time (as percentage of uptime) validator stays in each state and created a chart for it. The chart shows 'syncing' time started to increase 9:27 pm. At the same time, Network inbound traffic and disk write increased, which I guess makes sense. I will try to create a chart that shows traffic from each host, hopefully that can help me to figure out what the problem really is.
  5. I hope we can build some metrics into rippled so that we can have some monitoring system scrape time series data from those metrics, show them on some dashboard so that people can see the performance of all validators and then choose their own validators to trust.
  6. r0bertz

    Block insane peer?

    I recently increased ram from 6g to 8g and disk from 10g to 40g. I didn't set peer max before (and I have unset it now). I have also recently set node size to small and then tiny. Previously, with 6G ram 10G disk, Rocks db, medium size, it worked pretty well. Now it looks like this: https://xrpcharts.ripple.com/#/validators/nHBTqw7vwjqrSMruoQNYmSXcrBmQHDquG7jgvrsQpurGaVELqdNx I just set node size to medium again.
  7. r0bertz

    Network usage

    Ignore what I said. It doesn't seem like a good idea.
  8. r0bertz

    My validator died last night

    I figured out why disk usage was high. It's because online_delete was disabled due to the validator not in sync with the network. https://github.com/ripple/rippled/blob/fc0d64f5eec4386db7146251ab1a7fe880bec17c/src/ripple/app/misc/SHAMapStoreImp.cpp#L751 I saw some "Not deleting" messages in the log.
  9. r0bertz

    Block insane peer?

    It went back down a little bit. I blocked the insane peer with iptables. Maybe rippled should block insane peer automatically.
  10. r0bertz

    Block insane peer?

    Bam! Back to 1.0 I haven't had a chance to block it using iptables though. https://xrpcharts.ripple.com/#/validators/nHBTqw7vwjqrSMruoQNYmSXcrBmQHDquG7jgvrsQpurGaVELqdNx Saturday, January 13 2018 1.00000 0.00000 855
  11. r0bertz

    Block insane peer?

    Damn, should've thought of that. Thanks!
  12. Is there such a way to do that? I have this peer in the output of 'rippled peers' I suspect this peer has to do with my validator's low agreement rate recently. I have recently set peer max to 10. Not sure if this also contributed to that. I just unset peer max. I will see if it helps.
  13. r0bertz

    Network usage

    Try setting [peers_max]. Like 15 or even 10.
  14. I use 6g ram previously. Later changed to 6.5g because of OOM. At first, ram usage dropped. Now it starts OOM again. Just changed to 8g.
  15. Here are the details: https://r0bertz.blogspot.com/2018/01/xrpninja-ripple-validator-crashed-last.html Basically, the disk was too small. The server kept getting new ledgers for several hours till the disk was full and killed itself. A question to all rippled operators: Did your rippled receive so many ledgers during the same time period (8:30 pm to 1:40 am PST)?
×