![]() |
TweaksOn this page you can find ways to improve performance and lower resource consumptions of a running client.Like with every tuning, you should apply any changes in steps, checking each time for expected gains. In particular, you should monitor your system for RAM usage. If it uses all the memory, revert the change before you see the swap file burning. Garbage Collector and UTXO heapIf you have RAM to spare, try increasing the Garbage Collector treshold.This will increase memory usage, but should improve performance (e.g. initial blockchain download time). For that, edit the config file to set Memory.GCPercTrshold to 100 or more (higher value for more effect).Alternativelly, you can turn off the GC treshold (by setting it to -1) and control the maximum memory usage via Memory.MemoryLimitMB .Use this method if you want to allocate a fixed amount of RAM for your running node, but mind that the limiter does not account for UTXO records when Memory.UseGoHeap is disabled.Additionally, you can switch UTXO records to Go's heap manager by setting Memory.UseGoHeap
to true.This seems to significantly improve UTXO update performance (so also chain sync times), as long as your node does not run GC too often. At the other hand, your node will then need more memory and loading of UTXO database (when node starts) will take slightly longer. Initial chain sync cacheIf you have a fast internet connection (e.g. 1Gbit), examine the two options below.Don't bother with a slow connection, as the download speed is your bottleneck then. (you know it when syncing node uses your entire bandwidth) The first option will likely have a better effect on the performance, although requires more RAM.
To assure the UTXO worker doesn't have to wait for the network, the node tries to download blocks ahead and store them in the cache. The bigger the cache, the less likely it is that the UTXO worker will ever have to wait for the network. Mind that with CacheOnDisk disabled, a change of the cache size has a major effect on memory usage.At the other hand, having the cache on disk results in a minimal memory requiement even for a huge cache size. But it comes at the extra time required for the disk operations and re-creation of memory structures after loading. Note: 1. This only affects the chain sync performance. Once the chain is synchronized, it does not matter. 2. Monitor your node's TextUI for cachempty: X debugs. If X is not increasing after block 200000, don't bother with a bigger cache.3. The node does not need restarting to apply new values of these parameters. 4. Restarting the node during chain sync discards the entire cache, even when on disk. Disable wallet functionalityYou can disable node's wallet functionality, to save system memory used by a running client and improve block processing times.In order to do so, use TextUI command wallet off or click the disable wallet button on the bottom of the Wallet page in the WebUI.Note: This is only applicable to a synchronized node - after it launched and made sure to have all the recent blocks. If you don't want the wallet functionality to automatically enable after the node is started and synchronized, set the value of AllBalances.AutoLoad to false in the
config file.Note: You can manually enable wallet functionality at any time while the node is running, either from WebUI or by executing TextUI command wallet on .External secp256k1 speedupsIt is possible to use libsecp256k1 (maintained by Bitcoin Core project) that is written in C and assembler.Note: To check the performance difference, use test programs from gocoin/lib/others/cgo/ec_bench/
(e.g. go run gonative.go vs go run sipasec.go ).To make Gocoin client to use the external library, copy either the file sipadll.go (Windows only) or sipasec.go (any OS),
from gocoin/client/speedups/ to its parent folder (gocoin/client/ ).
Then rebuild and restart the client.Note: You can have either sipadll.go or sipasec.go in your
gocoin/client/ folder, but never both of them as the client will not build then.Depending which speedup file you chose, follow either of the instructions in the table below.
Disable BlockDB compressionEdit the config file and set the value ofMemory.CompressBlockDB to false.This may improve chain sync performance, as well as some tasks of a synchronized node. However, it will require more disk storage, as the compression saves about 15% of blocks data space. Compress UTXO recordsTo save some system memory as well as a disk space, although at the cost of a performance, you can compress UTXO database.In order to do this, execute the tool utxo -compress .The tool needs to be executed from inside the data folder - where the UTXO.db file is.The node must not be running while executing the tool. You can reverse the operation of compressing the database, be running utxo -decompress .Note: It saves only about 3% of space used by UTXO.db file. Disable countersEdit the config file and set the value ofStats.NoCounters to true.This will turn off node's internal statistics which should improve performance. Note: It is likely that such a performance gain will not be noticable. |