Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lnd+config: add ability to obtain blocking and mutex profiles #7983

Merged

Conversation

Roasbeef
Copy link
Member

In this commit, we add the ability to obtain blocking and mutex profiles. The blocking profile will show which goroutines are consistently blocked on synchronization primitives like channels, or I/O. The mutex profile will show which mutexes are very contested.

The blocking profile can be enabled with a new arg: --blockingprofile. The mutex profile can be enabled with a new arg: --mutexprofile. These are both ignored if the profile port isn't set.

Activating these profiles requires the caller to pass in a sampling rate. For now I've set it just to 1 to test things out. Unfortunately documentation is rather scarce, so there aren't any good guides re what these values should be set to. AFAICT, these add more overhead than the other prowling options, so they shouldn't necessarily be enabled persistently in production.

@Roasbeef
Copy link
Member Author

Pushed an update to allow the user to set the rate value themselves (0 to 1).

@Roasbeef Roasbeef added this to the v0.17.0 milestone Sep 13, 2023
@yyforyongyu yyforyongyu requested review from yyforyongyu and removed request for guggero September 14, 2023 02:08
config.go Outdated Show resolved Hide resolved
sample-lnd.conf Outdated Show resolved Hide resolved
Copy link
Collaborator

@ellemouton ellemouton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tACK 🔥 This will be super useful 🔥

LGTM after the sample conf check is passing as YY mentioned

@@ -337,6 +337,9 @@ type Config struct {

Profile string `long:"profile" description:"Enable HTTP profiling on either a port or host:port"`

BlockingProfile int `long:"blockingprofile" description:"Used to enable a blocking profile to be served on the profiling port. This takes a value from 0 to 1, with 1 including every blocking event, and 0 including no events."`
MutexProfile int `long:"mutexprofile" description:"Used to Enable a mutex profile to be served on the profiling port. This takes a value from 0 to 1, with 1 including every blocking event, and 0 including no events."`

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps worth updating the descriptions a bit so that it is clear which "blocking event" the individual profiles will look at? The description in the commit message is great 👍

Copy link
Collaborator

@guggero guggero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super useful addition. One issue with the example file, otherwise looks good.

sample-lnd.conf Outdated Show resolved Hide resolved
In this commit, we add the ability to obtain blocking and mutex
profiles. The blocking profile will show which goroutines are
consistently blocked on synchronization primitives like channels, or
I/O. The mutex profile will show which mutexes are very contested.

The blocking profile can be enabled with a new arg: `--blockingprofile`.
The mutex profile can be enabled with a new arg: `--mutexprofile`. These
are both ignored if the profile port isn't set.

Activating these profiles requires the caller to pass in a sampling
rate. For now I've set it just to `1` to test things out. Unfortunately
documentation is rather scarce, so there aren't any good guides re what
these values should be set to. AFAICT, these add more overhead than the
other prowling options, so they shouldn't necessarily be enabled
persistently in production.
@Roasbeef Roasbeef merged commit 2359481 into lightningnetwork:master Sep 18, 2023
21 of 25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants