Parity-ethereum: Correct settings for a public node

[moeadham]

Hello,

Can you give us some advice on running a public parity node? We are looking to run a node that does not prune, and has a virtually unlimited tx-queue. There are a lot of config options, so we want to make sure we didn't miss anything. It is running in a pretty huge server(64GB ram), sitting behind Nginx inside this docker container:
https://github.com/go-faast/parity-docker/blob/master/Dockerfile#L29

Here are the current configs:

            "--port", "30303", \
            "--jsonrpc-port", "8541", \
            "--ws-port", "8542", \
            "-d", "/paritydata", \
            "--pruning", "archive", \
            "--scale-verifiers", \
            "--no-ui", \
            "--ws-apis", "web3,eth,pubsub,net,parity,parity_pubsub,traces,rpc", \
            "--ws-origins", "all", \
            "--ws-interface", "all", \
            "--ws-hosts", "all", \
            "--jsonrpc-hosts", "all", \
            "--jsonrpc-interface", "all", \
            "--jsonrpc-cors", "'*'", \
            "--jsonrpc-apis", "eth,net,web3", \
            "--no-dapps", \
            "--no-secretstore", \
            "--tx-queue-mem-limit", "0", \
            "--tx-queue-size", "1000000000", \
            "--jsonrpc-server-threads", "10", \
            "--jsonrpc-threads", "10", \
            "--public-node"

[5chdn]

Can you give us some advice on running a public parity node?

--public-node # remove this

Public Node might _not_ be what you want it to be, since you also have a --no-ui flag, this does not make any sense and I would recommend using this flag unless you understand what it means (see wiki link).

Can you give us some advice on running a public parity node?

--jsonrpc-apis safe # consider "safe"

This will enable all APIs that are considered _safe_. For WS APIs this is: web3,eth,pubsub,net,parity,parity_pubsub,traces,rpc,secretstore,shh,shh_pubsub

and has a virtually unlimited tx-queue.

--tx-queue-size 4294967295 # assuming a 32-bit system

This is the virtual limit of the size parameter on a 32-bit system. You would probably never need more than this. 18446744073709551615 should work on a 64-bit system.

There are a lot of config options, so we want to make sure we didn't miss anything.

--no-ui
--no-dapps
--no-hardware-wallets
--no-secretstore
--no-secretstore-http

Consider disabling stuff you do not need.

It is running in a pretty huge server (64GB ram),

--cache-size 16384

Give this client a huge cache to work with (if desired).

Here are the current configs

This is looking good so far. It seems parity --help is your friend already. Let me know if you need anything else. :)

[awgneo]

@5chdn if parity is considered a safe public module, are the account vault commands also safe for public exposure (https://github.com/paritytech/parity/wiki/JSONRPC-parity-module#account-vaults)?

[5chdn]

No, that's a very unfortunate placement of the vault-RPCs. We will probably move them to parity_accounts.

[moeadham]

Hey @5chdn

So I'm trying to sync a non-archived node with tracing. The issue we have not is that the sync is now slower than new block generation, so it likely will never finish.

2017-12-06 04:45:34 UTC Syncing #2692412 b185…791f 0 blk/s 0 tx/s 0 Mgas/s 0+ 9937 Qed #2702353 44/50 peers 14 MiB chain 1 MiB db 75 MiB queue 4 MiB sync RPC: 0 conn, 0 req/s, 0 µs

Currently, it looks like the parity process is only using 33% of one CPU, the Server has 12 CPU's available.

Any suggestions what we should change in the following settings to speed things up?

["parity", \
            "--port", "30303", \
            "--jsonrpc-port", "8541", \
            "--ws-port", "8542", \
            "-d", "/paritydata", \
            "--pruning", "archive", \
            "--tracing", "on", \
            "--scale-verifiers", \
            "--no-ui", \
            "--no-dapps", \
            "--no-hardware-wallets", \
            "--no-secretstore", \
            "--no-secretstore-http", \
            "--ws-apis", "web3,eth,pubsub,net,parity,parity_pubsub,traces,rpc,secretstore,shh,shh_pubsub", \
            "--ws-origins", "all", \
            "--ws-interface", "all", \
            "--ws-hosts", "all", \
            "--jsonrpc-hosts", "all", \
            "--jsonrpc-interface", "all", \
            "--jsonrpc-cors", "'*'", \
            "--jsonrpc-apis", "safe", \
            "--tx-queue-mem-limit", "0", \
            "--tx-queue-size", "4294967295", \
            "--cache-size", "16384", \
            "--jsonrpc-server-threads", "10", \
            "--jsonrpc-threads", "10"]

[mingfang]

The limiting factor is disk io.
When syncing my node, I've seem over 1.5GB/s write and over 10,000 op/s.
I'm using two nvme ssd raid 0.

Use nmon to check your io.

[moeadham]

Thanks for the suggestion, nmon indeed showed some troublesome disk stats.

I switched our server settings to an SSD, hopefully that improves things.

Thanks for the suggestion.

[5chdn]

Yeah, the only thing you can do is switching to SSDs.

[tzapu]

just wanted to mention here that the latest builds crash if you specify --tx-queue-size 18446744073709551615 with Thread 'main' panicked at 'capacity overflow', libcore/option.rs:917

[5chdn]

Try 4294967295.

[tzapu]

yeah, works with that, thought it was useful here as people use this thread as recommendation (i suppose, i do anyway)