Yes, 1.27.0 use more memory
With the current version of cncli (2.1.x) you can use another way to calculate leaderlog:
cardano-cli query stake-snapshot --stake-pool-id <poolid> --mainnet >snapshot.json
and
cncli leaderlog --pool-id <pool-id> \
–pool-vrf-skey vrf.skey \
–byron-genesis mainnet-byron-genesis.json \
–shelley-genesis mainnet-shelley-genesis.json \
–pool-stake $(cat snapshot.json | jq .poolStakeMark) \
–active-stake $(cat snapshot.json | jq .activeStakeMark) \
–db db/cncli.db \
–ledger-set next
that way you don’t need that much memory with the cardano-cli command.
3 Likes
I’ve been experimenting with the stake-snapshot method as an alternate way of seeing if my pool RADAR is up for a block. As the ledger-dump / leaderlog method takes up a lot of ram.
Can anyone post what the output looks like when they are scheduled for a block? I’ve been unlucky these last couple epochs. And didn’t know if the stake-snapshot method would just show me how many blocks I’m scheduled for or if it would also show the time.
And when my cncli ledger-dump/leaderlog method is giving me parsing errors (presumably because I’m checking too early before the epoch change) would that also mean that it also too early to run the cncli stake-snapshot method as well?
Both methods have the same output format and again 1,5 days before epoch change is the same for both methods.
I have no idea what this parameter db/cncli.db does or how can it be found
It’s the path to your cncli database. It might be different from mine - however since you have to keep your database in sync with the blockchain you’ll have it somewhere.
1 Like