Parity-ethereum: Default settings for cache size insufficient for parity to work

[gsalzer]

• Parity Ethereum version: 2.4.5 or 2.4.6
• Operating system: Linux
• Installation: binary from Github | releases
• Fully synchronized: both, no and yes
• Network: ethereum
• Restarted: yes

Actual behaviour

When starting parity 2.4.5/2.4.6 in archive mode (tracing on, db_compaction ssd, pruning archive, fat_db on) with the default settings for the cache_size parameters, parity seems to get stuck after writing the first few lines of the logfile, before printing the updated exchange rate and before importing/synching any blocks. The CPU load may go up to 200%, but memory usage stays low (e.g. 1% of 32GB), and the system utilities report lots of io waits.
The same when setting cache_size=2048. The situation stays the same for 30 minutes and more (after which I restarted parity with different settings).

With cache_size=4096, however, parity uses notable amounts of memory and starts to sync/import blocks almost immediately.

Expected behaviour

The default settings should be chosen in a way that enables parity to do its work to some reasonable extent (differently from getting stuck).

Steps to reproduce

Run parity 2.4.5 and 2.4.6 with a configuration like

[parity]
mode = "active"
auto_update = "none"

[network]
warp = false
min_peers = 1
bootnodes = [ ... ]
discovery = true
reserved_peers = ".../ethereum/parity/peers.txt"
reserved_only = false

[rpc]
server_threads = 8
processing_threads = 8 

[footprint]
tracing = "on"
db_compaction = "ssd"
pruning = "archive"
fat_db = "on"

[snapshots]
disable_periodic = true

[gsalzer]

Addendum: at least in archive mode, the memory consumption of Parity can be hardly controlled. For example, with cache_size=4096 parity may consume easily 16GB of physical memory after running a day (without mining, only for archiving blocks and answering queries via json-rpc).

[adria0]

Closing issue due to its stale state.