You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
59 lines
3.3 KiB
59 lines
3.3 KiB
The following environment variables are required:
|
|
|
|
DB_DIRECTORY - path to the database directory (if relative, to `run` script)
|
|
USERNAME - the username the server will run as if using `run` script
|
|
ELECTRUMX - path to the electrumx_server.py script (if relative,
|
|
to `run` script)
|
|
DAEMON_URL - the URL used to connect to the daemon. Should be of the form
|
|
http://username:password@hostname:port/
|
|
Alternatively you can specify DAEMON_USERNAME, DAEMON_PASSWORD,
|
|
DAEMON_HOST and DAEMON_PORT. DAEMON_PORT is optional and
|
|
will default appropriately for COIN.
|
|
|
|
The other environment variables are all optional and will adopt
|
|
sensible defaults if not specified.
|
|
|
|
COIN - see lib/coins.py, must be a coin NAME. Defaults to Bitcoin.
|
|
NETWORK - see lib/coins.py, must be a coin NET. Defaults to mainnet.
|
|
DB_ENGINE - database engine for the transaction database. Default is
|
|
leveldb. Supported alternatives are rocksdb and lmdb.
|
|
You will need to install the appropriate python packages.
|
|
Not case sensitive.
|
|
REORG_LIMIT - maximum number of blocks to be able to handle in a chain
|
|
reorganisation. ElectrumX retains some fairly compact
|
|
undo information for this many blocks in levelDB.
|
|
Default is 200.
|
|
HOST - the host that the TCP and SSL servers will use. Defaults to
|
|
localhost.
|
|
TCP_PORT - if set will serve Electrum TCP clients on that HOST:TCP_PORT
|
|
SSL_PORT - if set will serve Electrum SSL clients on that HOST:SSL_PORT
|
|
If set, SSL_CERTFILE and SSL_KEYFILE must be filesystem paths.
|
|
RPC_PORT - Listen on this port for local RPC connections, defaults to
|
|
8000.
|
|
BANNER_FILE - a path to a banner file to serve to clients. The banner file
|
|
is re-read for each new client.
|
|
DONATION_ADDRESS - server donation address. Defaults to none.
|
|
|
|
Your performance might change by tweaking the following cache
|
|
variables. Cache size is only checked roughly every minute, so the
|
|
caches can grow beyond the specified size. Also the Python process is
|
|
often quite a bit fatter than the combined cache size, because of
|
|
Python overhead and also because leveldb consumes a lot of memory
|
|
during UTXO flushing. So I recommend you set the sum of these to
|
|
nothing over half your available physical RAM:
|
|
|
|
HIST_MB - amount of history cache, in MB, to retain before flushing to
|
|
disk. Default is 250; probably no benefit being much larger
|
|
as history is append-only and not searched.
|
|
|
|
UTXO_MB - amount of UTXO and history cache, in MB, to retain before
|
|
flushing to disk. Default is 1000. This may be too large
|
|
for small boxes or too small for machines with lots of RAM.
|
|
Larger caches generally perform better as there is
|
|
significant searching of the UTXO cache during indexing.
|
|
However, I don't see much benefit in my tests pushing this
|
|
too high, and in fact performance begins to fall. My
|
|
machine has 24GB RAM; the slow down is probably because of
|
|
leveldb caching and Python GC effects. However this may be
|
|
very dependent on hardware and you may have different
|
|
results.
|
|
|