lnd: Very slow start of LND even with Postgresql backend
Background
Starting, or restarting, my node will imply a wait time of about 20 minutes, of which 20s are spent opening the postgresql database, then a long series of
[ERR] RPCS: [/lnrpc.Lightning/GetInfo]: the RPC server is in the process of starting up, but not yet ready to accept calls
are produced (either GetInfo, or listpeers, or any other call that my running scripts send to lnd to fetch data) for about the next 10 minutes, and then another long series of
[ERR] RPCS: [/lnrpc.Lightning/ConnectPeer]: server is still in the process of starting
is spat out for roughly another 10 minutes, until channels start to be actually reconnected.
As mentioned before, I do have lndg jobs running every few seconds and my scripts checking whether lnd is alive with getinfo, but disabling them doesn’t really appear to speed up anything.
Your environment
- version of
lnd0.14.3 - which operating system (
uname -aon *Nix) raspberry bullseye - version of
btcd,bitcoind, or other backend 0.22 - any other relevant environment details raspberry pi 4 8gb
Steps to reproduce
Restart lnd on raspberry pi 4 8gb
Expected behaviour
Startup in a sane time (up to a coupld of minutes after database is opened maybe?)
Actual behaviour
lnd takes 20 minutes after database open to actually be operational
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 1
- Comments: 18 (8 by maintainers)
I think using multiple connections (e.g. 20 or more, make sure that Postgres also has at least that many configured) and setting a timeout (to something like
1mor5m) is probably a good idea. Other than that, I don’t think there are any other recommended settings. BTW, https://github.com/lightningnetwork/lnd/pull/7992 which is planned to land inv0.17.1-betashould definitely improve things for Postgres quite a bit.It’s a VPS with 16 cores and 32 GB RAM, so that cannot be the issue.
@MichaelAntonFischer what hardware is this on? We recently observed a case where a Raspberry Pi simply didn’t have a good enough power supply and dips in the voltage caused the SSD to just lock up Postgres operations for minutes. Looking at the description of the original poster, this could very well be the case for them here as well.
The log only prints on start up, but if you don’t have the
CHDBlog sub-system set todebug, then it won’t show up. So you might need to restart w/ that logging level to be able to see this log.