-
Notifications
You must be signed in to change notification settings - Fork 55
Memory Performance Improvements #78
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
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Mary Paskhaver <mary.paskhaver@gmail.com> Co-authored-by: mattkahrs <mattkahrs@gmail.com>
…metheus-haskell into mattp/memory-performance
|
|
||
| We're running into problems with unexpectedly high memory use in `prometheus-client`, so I've been investigating improving the behavior. | ||
|
|
||
| Specifically, we're notificing a significant increase in the amount of time and memory allocated while calling `exportMetricsToText`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Specifically, we're notificing a significant increase in the amount of time and memory allocated while calling `exportMetricsToText`. | |
| Specifically, we're noticing a significant increase in the amount of time and memory allocated while calling `exportMetricsToText`. |
| ## `MetricImpl` | ||
|
|
||
| A `Metric` had a field `construct :: IO (s, IO [SampleGroup])`. | ||
| To avoid tuple, we introduce `MetricImpl s` which uses bang patterns on the fields. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| To avoid tuple, we introduce `MetricImpl s` which uses bang patterns on the fields. | |
| To avoid the tuple, we introduce `MetricImpl s` which uses bang patterns on the fields. |
| This means that, should anything write to the `TVar`, all of the computation will be retried. | ||
| This is *probably* bad - we want to capture the state of the metrics *now*, and then return the `SampleGroup`, rather than allowing the computation to be aborted and retried multiple times. | ||
|
|
||
| The first two problems are based on the sizeof the histogram, so the number of buckets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| The first two problems are based on the sizeof the histogram, so the number of buckets. | |
| The first two problems are based on the size of the histogram, so the number of buckets. |
|
|
||
| The first two problems are based on the sizeof the histogram, so the number of buckets. | ||
| Every additional bucket causes another float to be rendered into a string, and another list cons cell to be held on to. | ||
| Since number of buckets is likely small, this is probably not a big deal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Since number of buckets is likely small, this is probably not a big deal. | |
| Since the number of buckets is likely small, this is probably not a big deal. |
| @@ -0,0 +1,91 @@ | |||
| # Investigating Memory Use in `prometheus-client` | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like an odd file to check into main. I think this would be more appropriate as the PR description.
|
Do these changes resolve the memory issues are seeing? There are several changes described in |
No description provided.