Cardano-node 1.33.0 released

Hey girls & guys, there will probably be an official release soon. But cardano-node 1.33.0 has just been released on GitHub.

Go and get it, it’s a really good upgrade. Beware: the ledger has changed and old ledgers are no longer compatible. On first start your node will need to rebuild the entire ledger, this can take a few hours. It would be wise to start on one relay first, then copy the ledger over to your other nodes.

I’ve been running 1.33.0 and the rcs for nearly a month now and have seen huge memory improvements!

1 Like

In the case of the memory improvements, can you provide an idea of what that’s looking like? I’m curious what minimum reqs are looking like, based on the new version.


On a 4core/16gb ram machine that I run with following RTS params:

+RTS -qb0 -T -S -N4 -G2 -A32m -AL512m -n1m -F1.1 -C0 -I0 -O3000m -RTS

after ~22hrs max residency is 5.3 GB. About 2.6 GB live data


You might see spikes a bit larger at epoch switch.

1 Like

Something is very wrong with this release… I would hold off upgrading until they take a look at it. cardano-cli commands seem to be effected - simple ones such as querying a wallet address are taking close to 30 seconds to return results whereas they were taking less than a second on 1.31…

Trying out 1.33.0 on a backup node. Did anyone else get this error on startup? I’m wondering if it has to do with the entire ledger being rebuilt

[backup-b:cardano.node.ChainDB:Error:11] [2022-01-08 20:12:38.18 UTC] Invalid snapshot DiskSnapshot {dsNumber = 50059327, dsSuffix = Nothing}InitFailureRead (ReadFailed (DeserialiseFailure 63473 “expected list len or indef”))
[backup-b:cardano.node.ChainDB:Error:11] [2022-01-08 20:12:38.18 UTC] Invalid snapshot DiskSnapshot {dsNumber = 50054434, dsSuffix = Nothing}InitFailureRead (ReadFailed (DeserialiseFailure 63307 “expected list len or indef”))

I’ve updated one relay node so far. When I restarted the node after the upgrade it just sits at starting. Been doing this for about 40 minutes so far. Did anyone else see this behavior? My relays used to restart in just a few minutes.

Same with mine. After upgrading and restarting the node and getting those error messages, nothing happened. No logging, no changes to the db directory, other than the fact the db directory had been cleared with the restart. Checking top, it’s processing 200 - 300% CPU and using a low amount of memory, but nothing. After about 30 minutes, I did a stop, then did a regular start (systemctl), versus the systemctl restart I had done earlier. Still no changes to the db directory. I’ll let it run for a few hours and see what happens.

It’s probably by design. Less memory is used after all.

It’s going to have to rebuild the complete ledger. It will take a while.

After the update to 1.33 my nodes were starting for over 4 hours, it’s expected to be like that.
According to latest release:

With this version, the ledger state will need to be replayed from the genesis block, meaning that the initial synchronisation may be slow. Users should account for this when deploying the node.

The ledger rebuild took my first node around 3 hours to complete. During this time, my gLiveView was stuck in “starting.” I imagine this rebuild will take most folks 2 to 4 hours.

After this initial resync, I copied the /opt/cardano/cnode/db/ledger files to subsequent nodes after updating and their sync times were around 10 mins each.

Yep. Mine are up now. Just took awhile.

And mine finished, Took 3 hours and 6 minutes. I was expecting to see the db directory update during the synchronization, but apparently the resync is all in memory.

Make sure you to have at least ghc 8.10.7 instead of ghc 8.10.4 and cabal 3.4.0 before proceeding.

1 Like

you can use IOHK documentation

Yes,it took about 4 hours to fully sync

I’m curious about your comment about ghc 8.10.7. I used this command while upgrading my nodes.

cabal configure -O0 -w ghc-8.10.4

I haven’t seen any issues yet but I’m curious if you think I will?


Probably no issues but I’d suggest to compile with 8.10.7, especially if you use the non copying gc collector.

Does anyone know if you still need to use the IOHK version of libsodium. I have been compiling against the debian stable version 1.0.18 for a while and haven’t seen any problem.