|
|
|
|
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
|
|
|
|
|
SERVER_MAIN - path to the server_main.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.
|
|
|
|
|
TCP_PORT - if set will serve Electrum clients on that port
|
|
|
|
|
SSL_PORT - if set will serve Electrum clients over SSL on that 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 these cache settings. 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 bigger than the combine cache size, because of Python overhead and
|
|
|
|
|
also because leveldb can consume quite a lot of memory during UTXO
|
|
|
|
|
flushing. So these are rough numbers only:
|
|
|
|
|
|
|
|
|
|
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.
|
