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. That’s not really how clustering works, unfortunately. Clustering can help for some things, especially if you operate many servers as a group, but the performance gains as such are pretty small. In the future, clustering may help with history sharding.
  2. I’m not sure how clustering would apply. Can you explain?
  3. So, hash functions, like SHA-256, are basically compression functions: their key property is that they take an arbitrary amount of data and compress it down to a fixed size. In the case of SHA-256, the fixed size of the output is 256 bits, regardless of the size of the input. Digital signatures aren't really compression functions. Their key property is that there exists a mathematical relationship between the private and the public keys, which allows us to sign something using the private key (which remains secret) and then verify the signature using the public key (which everyone knows). Simply hashing a private key using a general purpose hash function (like SHA256) doesn't necessarily preserve the important mathematical relationship between the private and public keys that digital signature algorithms rely on.
  4. Eek! That's unfortunate, thanks for pointing that out.
  5. I have no idea. As far as I know, PayID is justa way to “resolve” a human-friendly moniker, like joe$example.com) to less human-friendly identifiers (wallet addresses, account numbers, etc) used in various payment networks. I don’t think that PayID itself offers any kind of “pathfinding” mechanism.
  6. You’ll need to provide more information. Do you have the transaction hash?
  7. Thanks @tulo. These seem reasonable, but I only gave them a quick look. I'll take a closer look later tonight and follow up here.
  8. Given the constraints you describe (specifically the "force ledger at any pace I desire") then standalone mode, for all its limitations and problems, may be the best option. I'd urge you to reconsider the "independent of the outside world" requirement. If you can get away without that, why not consider using the testnet?
  9. 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.
  10. 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.
  11. 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.
  12. I'd definitely have you doing online delete a lot less; say once every 10k ledgers?
  13. 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!
  14. 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?
  • Create New...