You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From this discussion and the various profile dumps
shared there, it is clear that if a node has many tower client sessions, then start-up of the tower client, and hence
LND, can be very slow.
The issue:
After some investigation, it is clear that the current way the tower client starts is super sub-optimal as it does
the following on each startup (and for each client):
the client keeps an in-mem map of map[channelID] max-commit-height. This map represents the maximum commitment height of a backup for a channel that the client has received. It uses this map in various places.
the issue is the population of this map (which is done at startup) : it will currently range over every session (which could be in the ten thousands) and for every session, it goes through each of its range indices to get the max height per channel backed up with the session.
The solution(s):
The first thing that needs to be done that will have the most impact is removing the need to iterate through all the sessions & range indices on each start-up. So we should: keep track of the max-height for each channel in the channel details bucket and update that accordingly & then read from that on startup. This will require a migration since we need to iterate once over all sessions to populate this new field for existing channels. - wtclient+migration: start storing chan max height in channel details bucket #8222
From this discussion and the various profile dumps
shared there, it is clear that if a node has many tower client sessions, then start-up of the tower client, and hence
LND, can be very slow.
The issue:
After some investigation, it is clear that the current way the tower client starts is super sub-optimal as it does
the following on each startup (and for each client):
map[channelID] max-commit-height
. This map represents the maximum commitment height of a backup for a channel that the client has received. It uses this map in various places.The solution(s):
The text was updated successfully, but these errors were encountered: