add blog post for gomemlimit #158
Conversation
markdown/docs/gomemlimit.mdx
Outdated
|
|
||
| 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
markdown/docs/gomemlimit.mdx
Outdated
|
|
||
| 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)
markdown/docs/gomemlimit.mdx
Outdated
| - 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
markdown/docs/gomemlimit.mdx
Outdated
| 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
markdown/docs/gomemlimit.mdx
Outdated
| - **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
No description provided.