add blog post for gomemlimit#158
Conversation
edeNFed
left a comment
edeNFed
left a comment
There was a problem hiding this comment.
Looks great, I would try to make it 30% shorter and little less ChatGPTy but its great as it anyway
|
|
||
| Efficient memory and CPU management in Go applications involves a delicate balance, particularly around garbage collection (GC). | ||
|
|
||
| - Running Garbage Collection in Go is a blocking operation, and is considered relatively expensive (resource wise). |
There was a problem hiding this comment.
| - Running Garbage Collection in Go is a blocking operation, and is considered relatively expensive (resource wise). | |
| - Running Garbage Collection in Go is a blocking operation, and is considered relatively expensive (CPU wise). |
| tags: [golang, resource-management] | ||
| authorImage: '/amir.jpg' | ||
| author: Amir Blum | ||
| metadata: GOMEMLIMIT, CPU consumption, resource management |
There was a problem hiding this comment.
I think SEO wise worth to add Otel, Opentelemetry, Opentelemetry collectors, collectors etc
|
|
||
| Key Trade-Offs: | ||
|
|
||
| - **Memory Reservation** - ensure your platform (e.g., Kubernetes) reserves a guaranteed amount of memory for your application. Without this, an OOM Kill event could occur unpredictably, undermining stability regardless of the GOMEMLIMIT value. |
There was a problem hiding this comment.
if you started with e.g Kubernetes
maybe after guaranteed amount of memory for your application. (e.g resource request)
| - Memory not tracked by GOMEMLIMIT (e.g., stack memory, code memory). | ||
| - A buffer to accommodate GC delays when memory usage crosses the limit. | ||
| - safety margin. | ||
| - **Low vs High GOMEMLIMIT**: |
There was a problem hiding this comment.
the low vs high is not so clear in my opinion,
maby stability versus prioritizing busniess logic?
even though is sounds a duplicate for key considerations above
| In our setup, we followed the [OpenTelemetry memory limiter processor best practices](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/memorylimiterprocessor#best-practices): | ||
|
|
||
| - We reduced 50MB from the memory request in Kubernetes and assumed this is roughly the memory allocated to the heap. | ||
| - We used 80% of the remaining memory as the GOMEMLIMIT value (leaving 20% of the assumed heap memory as a buffer). |
There was a problem hiding this comment.
20% is the 50MB that reduced right? in the first point u talk in MB and second in precentage maybe worth refactor this two sentences
| - **Lower Value** - Provides greater stability by allocating more memory headroom, reducing the risk of crashes. | ||
| - **Higher Value** - Improves memory efficiency by prioritizing business logic over safety margins, but increases the risk of hitting OOM under load. | ||
|
|
||
| In our setup, we followed the [OpenTelemetry memory limiter processor best practices](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/memorylimiterprocessor#best-practices): |
There was a problem hiding this comment.
It is the first time Opentelemetry is mention, in general seems like we hook our use case without context. maybe worth adding another section of our case after the general explanations about GOMEMLIMIT?
| @@ -0,0 +1,205 @@ | |||
| --- | |||
| pubDate: 'Dec 17 2024' | |||
| title: 'Understanding GOMEMLIMIT: How It Can Spike CPU Usage (and How to Fix It)' | |||
There was a problem hiding this comment.
What about:
Understanding GOMEMLIMIT: Lessons Learned from Optimizing OpenTelemetry Collectors
BenElferink
left a comment
BenElferink
left a comment
There was a problem hiding this comment.
We have a new flow for posting blogs, please follow the readme:
https://github.com/odigos-io/landing-page?tab=readme-ov-file#how-to-add-a-blog-post
5 participants
No description provided.