Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


nikb last won the day on November 27 2017

nikb had the most liked content!

About nikb

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Las Vegas, NV
  • Occupation
    Software Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The problem you're encountering is that in standalone mode the server never closes a ledger for you; you must choose to do it explicitly. And unless the server closes a ledger, it won't save anything. You can follow the process you are using; simply setup some mechanism to execute this command:/opt/ripple/bin/rippled ledger_accept at whatever frequency you feel is appropriate for your case. Generally, I would discourage you from using this mode, not even for internal testing. It is, primarily, used for debugging/troubleshooting of rippled code because it allows the server operator to very precisely control what happens when.
  2. That's curious. I don't see such CPU spikes on my own machines and CPU and memory seems roughly in line with what I would expect. Spiking the CPU on occasion is not unreasonable; the question is what the server is doing during those spikes. Can you produce the output of the following two commands: rippled server_info counters rippled get_counts Out of an abundance of caution, please be sure to mask out or remove the pubkey_node, pubkey_validator and hostid fields from the server_info counters response.
  3. I normally avoid threads like this, but I feel compelled to chime in here, because the above is simply not true; it’s a gross generalization and, frankly, nonsensical. People leave for many reasons. Perhaps they want to leave to focus on their own startup; to attend school; because they have health issues; or maybe the amount of work they have is so much that they find themselves unable to devote time to things that matter—like family. The point is that people‘s reasons are their own; they don’t owe anyone an explanation and if they do, their reasons don’t need to make sense to anyone other than themselves.
  4. I'd definitely have you doing online delete a lot less; say once every 10k ledgers?
  5. It took 0ms for the job to run. It took the server 337.895 seconds, or over 5 minutes, to actually complete higher-priority jobs and/or earlier ledger data to get to it and execute it. Somethings is definitely weird here. The [node_size] being small probably doesn't help—I'd recommend medium by the way—but I doubt that's the issue. Sukrim may be right about the disk. Can you please execute the following command while rippled is running? iostat -t -d -x 10 > iostat.out 2>&1 It will collect disk I/O information every 10 seconds until stopped. Please allow this to run for about 5 minutes then press CTRL-C. You can then attach the file iostat.out here. Please review the information contained within before you do so (you can use any text editor to view the contents), to ensure that it contains no information that you feel uncomfortable with. It should not; just I/O metrics on the disks on your machine, but better safe than sorry!
  6. That seems pretty standard. Some spikes aren’t unexpected, but if you see that much usage constantly, something is off. Can you show us the output server_info please?
  7. Karlos is entitled to run his validator any ways he sees fit, however, I think that decisions on amendments require a modicum or technical understanding, since every amendment has implications and every amendment that activates imposes some cost to the network. Asking on a forum with open registration about which way to vote seems, to me anyways, to be a poor way to do this. I’d never run my validator in such a fashion, but as I said, to each their own.
  8. A laptop is just a computer you can easily move. You should be able to run a validator on a recently modern machine. Up until recently, I’d spin up a rippled instance on a first generation 2013 ThinkPad Carbon X1 with 8GB of RAM on a regular basis. You may find the following useful: https://xrpl.org/install-rippled.html
  9. I normally wouldn’t dignify this tripe with an answer, but I feel compelled to: You must lack in imagination.
  10. Hop on the devnet or the altnet and have a blast. There’s no need for coordinated action either: two accounts should be enough.
  11. Good for them. If they have concerns or they want time to evaluate the amendment on the devnet, or even the code itself they should absolutely veto it. Notice too that Alloy says “at this time” which suggests to me that he wants the time to investigate this code and understand it and its implications. I’d never more concerned if they blindly rubber-stamped code changes than I am by Wietse’s and Alloy’s choice to veto the amendment. They are stewards of the XRP Ledger and should be careful about and weary of changes. Any change we make is a change that we are stuck with, potentially forever. For some details about this amendment, check out my twitter thread:
  12. Great! We are working on improving the insights module with rippled which can be used to export various metrics using the statsd protocol; empowering administrators to collect and plot performance/usage data from their running instances should prove helpful in identifying bottlenecks, areas of improvements as well as in spotting trends.
  13. We do have some insights into the increased resource, but they are insights; we need data and metrics that we can monitor over time to allow us to spot trends. Ripple, like any other operator of servers with a large number of client and server connections, can observe the servers it operates, examining things like memory, CPU and bandwidth usage and trends, and use that information along to extrapolate on future requirements. And like any other operator, it isn't clairvoyant, so it's predictions about hardware requirements may be off. As for reserves, my gut says it's not a good idea to tie them to amount of RAM or CPU. But perhaps I'm wrong. Curious to see what others think.
  • Create New...