duno if this is the best way or if its safe, but i know it works… seems pretty legit
used it when i initially updated to 1.35, because it was the official latest version before they rolled back on that…
keeping the IOHK default relay in the BP node topology.json file stopped it from desyncing from the network.
not sure why it happened… i mean i’ve been running without that for like 2 months.
but i guess there could be some sort of network change with the new release coming up…
or other software on my node host which has changed and thus now gives me a different result.
i however digress…
my node is back online and has been for a good while…
thanks for the help.
How many relays do u have? Perhaps both are restarting (by topologyUpdater) same time and thats why it is loosing the sync till the relays came up again?
just two presently, but will most likely want 3 or so…
no that isn’t why, nothing so obviously sadly…
each time i would start the BP it would sync to the network and then within anywhere from a few minutes to an hour or more … usually sooner rather than later… it would lose sync and just never recover.
got a log entry that said it lost contact with the relay, but if i opened peer analysis in gLiveView the relay would still seem like it was connected…
if i restarted the BP it would happen again, spent a long time trying to figure out what was wrong…
had this fix not worked, i would have migrated the BP to a different node that was working…
ofc if it was the topology.json then maybe it would have had the same issue…
i duno… it works now… so that is great…
or it seems to work… been online for like 3 hours which was been rare over the last week or so.
thus i suspect the issue is resolved.
1 Like
now it can run without my relays… 
which is sort of interesting… then the none centralized relays are just for decentralization i guess.
i always thought of them as a security measure… i mean i guess if the IOHK relays aren’t there they would still serve as a security measure…
Install the testnet.
Which version? 1.34.1?
Hi Alex
After removing the extra servers in topology since the node would not start it was stuck for 3 days. It is now at least running but still it was syncing after another 3 days there is obviously something wrong here or is this normal?
Current topology.json
{
“Producers”: [
{
“addr”: “relays-new.cardano-testnet.iohkdev.io”,
“port”: 3001,
“valency”: 2
}
]
}
Current sync approx 5 epochs behind after 3 days ???
The Tip ref ^^^ is the only figure changing should that be this number as I checked on https://testnet.cardanoscan.io/ the number of the slot starts with 3 not 6, is something wrong with my node is it trying to sync to mainnet ?
How long does this usually take, as its been 10 days since I started this any idea how long a sync should be ?
According to stack exchange 1-2 days
Shall I just create a new VM any recommended spec this time ?
for me trying to sync new relays, its basically taking forever… like a couple of weeks or more.
i haven’t been able to figure out exactly why, but it seems to be either cpu or network related.
the best results i’ve seen is when running less cores (maybe because of more L3 cache for the process), most likely why the default number of cores is 2.
which is what i would most likely recommend pr cpu. (or per core complex… in the case of threadrippers or epyc’s)
depending on the cpu architecture used, it might be different for you.
you can track cpu utilization and see how much of the time its actually running 100% of the cores allowed in cnode.sh
when its downloading the new parts of the chain for processing the cpu utilization will drop.
atleast from what i have been able to tell.
also been testing if additional memory helps… it really doesn’t…
ofc one needs enough memory which is like 24GB atm else the system will eventually start to swap which can or will slow down everything.
but early on in the sync process it doesn’t use much memory, it gradually grows until it reaches the full active node state… but even adding 64GB of memory does nothing for sync.
like alexd1985 says, the by far easiest way is to copy the db from synced node.
1 Like
If u copy the db from a synced node… the new relay should be up and running in ~ 2 hours (build + sync)
1 Like
Hi thanks but I dont have a fully synced node as not used Testnet relay. So what is the recommended RAM and cpu settings and is there a way to run more efficiently that could help like I read somewhere.
cardano-node +RTS -N2 --disable-delayed-os-memory-return -I0.3 -Iw600 -A16m -F1.5 -H2500M -T -S -RTS --your-usual-parameters`
How do I add such a parameter to the systemctl ?
And can I expand the ram then contract it after the sync is done ?
Check inside cnode.sh with nano cnode.sh
And can I expand the ram then contract it after the sync is done ?
Yes, but I don’t see how it will help u
Hi Alex
Can you see what would help us as we are now about 10 days behind and still no sync ?
Also how would I amend the cardano command in systemctl ?
U have the script ./deploy-as-systemd.sh
Can you give an example of editing the current systemctl cardano node command ?
1 Like
Is there any other troubleshooting tips for a node not syncing on here ?
1 Like
I don’t understand what u mean…
Glive output
how would I change from the current cnode.sh systemctl to
cardano-node +RTS -N2 --disable-delayed-os-memory-return -I0.3 -Iw600 -A16m -F1.5 -H2500M -T -S -RTS --your-usual-parameters
Glive output ?
I have posted several times the node is not syncing its going backwards in last 3days.
I am just spinning up a new VM to have one more go at this.
Next move is probably Docker if this still doesn’t work again, its not syncing.
Just to repeat this is a TESTNET node.