Closed gmosx closed 11 years ago
The server was probably either unable to fetch a ledger from the network or unable to get validations, likely because it had no validators configured. What's the output of 'server_info'?
{"result":{"info":{"closed_ledger":{"base_fee_xrp":0.000010,"hash":"AB...B6918936C7","reserve_base_xrp":200.0,"reserve_inc_xrp":50.0,"seq":1,"validated":true},"complete_ledgers":"empty","last_close":{"converge_time_s":15.0,"proposers":0},"load":{"job_types":[{"job_type":"untrustedProposal","peak_time":1},{"avg_time":2299,"job_type":"ledgerData","peak_time":9165,"per_second":1},{"in_progress":1,"job_type":"clientCommand"},{"job_type":"writeObjects","peak_time":3,"per_second":1},{"job_type":"peerCommand","peak_time":2,"per_second":10},{"job_type":"diskAccess","peak_time":23,"per_second":1052}],"threads":6},"load_factor":1.0,"network_ledger":"waiting","peers":8,"pubkey_node":"n9Mgumq..TBszdBKzsMrEVej6ekd7z","pubkey_validator":"none","server_state":"connected","validation_quorum":2}},"status":"success","type":"response"}
It looks like your server is having a hard time synchronizing the whole network ledger because it is performing an enormous amount of I/O. If this is a VPS, a lot of those are very I/O constrained and limit the server to 100 disk I/Os per second or so. If you have lots of RAM (1GB or more) you can increase the 'node_size' setting to get more memory caching. If you don't have the RAM, you may just have to suffer through it. It will clear once the server catches up.
Btw, I copied validators-example.txt to validators.txt (I have forgotten about that) but I still get the same error. Here is my updated server_info:
{"result":{"info":{"closed_ledger":{"base_fee_xrp":0.000010,"hash":"AB868A6...36C7","reserve_base_xrp":200.0,"reserve_inc_xrp":50.0,"seq":1,"validated":true},"complete_ledgers":"empty","last_close":{"converge_time_s":15.0,"proposers":0},"load":{"job_types":[{"avg_time":1,"job_type":"untrustedProposal","peak_time":3},{"in_progress":1,"job_type":"clientCommand"},{"job_type":"trustedProposal","peak_time":2},{"job_type":"peerCommand","peak_time":7,"per_second":14},{"job_type":"diskAccess","peak_time":640,"per_second":94}],"threads":6},"load_factor":1.0,"network_ledger":"waiting","peers":8,"pubkey_node":"n9Mgu..ej6ekd7z","pubkey_validator":"none","server_state":"connected","validation_quorum":2}},"status":"success","type":"response"}
OK, will leave the server running...
You were right, I left rippled running for a bit longer, and it works now ;-)
That looks a little better. It is still working to synchronize the initial ledger. Is this starting from empty databases? Or is this a VPS with very constrained I/O? Or very low RAM?
I think we are seeing cases where the server gets very bogged down with I/O. It's almost always shortly after startup, and it almost always clears in ten minutes or less. I'm trying to narrow down the circumstances under which it happens.
commit 9fbbee318df82346608eb9f5ed3dcbe9e2a528e2 was supposed to help with this, but it may be based on an incomplete understanding of the issue.
It was running on my Laptop (8Gb of RAM, but many many Chrome tabs open ;-)). I think it started from empty databases. Sorry, I don't know how to provide more information :(
On the positive side, everything is working fine now.
./rippled --net
RPC call (through WebSocket):
{"command": "account_offers", "account": "r...h"}
Error:
{"error":"noNetwork","error_code":12,"error_message":"Network not available.","request":{"account":"r...h","command":"account_offers"},"status":"error","type":"response"}
The same happens with account_info, etc. Subscribe commands do work.