JayT106

Results 92 comments of JayT106

Ah, the `blocksync` and `statesync` is the mechanism after the node started and catching to the network height. It will happen only the node starting after the node catches up...

RocksDB uses `snippy` as the default compression algorithm, We can use `LZ4` or other more aggressive(but may more resource consuming) algorithms as its compression option. ref: https://github.com/facebook/rocksdb/wiki/Compression https://github.com/tendermint/tm-db/blob/d24d5c7ee87a2e5da2678407dea3eee554277c83/rocksdb.go#L33

> ## Remove tx_index.db > Currently we rely on tx indexer to query tx by eth tx hash, an alternative solution is to store that index in a standalone kv...

I will start a testing build with the custom RocksDB setup to see how good it can be improved

> For reference: > > ``` > 939G application.db > 42G blockstore.db > 1.0G cs.wal > 46M evidence.db > 4.0K priv_validator_state.json > 47M snapshots > 81G state.db > 238G tx_index.db...

Looks like `lz4` might be working, the current`application.db` of the testing node at the block height of 1730K is around 511G. Projecting today's block height(2692K) will be around 755G. And...

> BTW, this is `prunning=default` node size (thanks @allthatjazzleo): > > ``` > 535G /chain/.cronosd/data/application.db > 20K /chain/.cronosd/data/snapshots > 44G /chain/.cronosd/data/blockstore.db > 120G /chain/.cronosd/data/state.db > 312G /chain/.cronosd/data/tx_index.db > 20K /chain/.cronosd/data/evidence.db...

Got the testing node synced up to the plan upgrade height, using default: ``` 1057776M ./application.db 45714M ./blockstore.db 88630M ./state.db ``` using `lz4` ``` 1058545M ./application.db 47363M ./blockstore.db 88633M ./state.db...

Went through the `application.db`, Got some basic statistic numbers (at height 2933002 and the size is raw data length): evm and ibc module use major store space in the database...

the major Key patterns in ibc store: `acks/ports/transfer/channels/channel-0/sequences/...` counts 1003777 `receipts/ports/transfer/channels/channel-0/sequences/...` counts 1003777 `clients/07-tendermint-1/consensusStates/...` counts 403893 `636C69656E74732F30372D74656E6465726D696E742D31...` (hex code of clients/07-tendermint-1) counts 134631