I’m using self-hosted version of GroupDocs.Conversion Cloud deployed on my server
image groupdocs/conversion-cloud:24.5b-alpine
I have se the CPU resourse as 1000m and limit as 1500m but I have observed that When I try to convert the file it consume the resources but does not clear the resources once its has completed its work
can you please look into this
we are using paid version of groupdocs
@sopan09
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CONVERSIONCLOUD-592
Hi, please share some details - what file format do you convert? Can you share sample file which cause memory leak?
Its not about a particular file
groupdocs service is not clearing the memory/resource used
lets say
I have set up CPU resource as 1000m and limit as 1500m
but I have observed that When I try to convert the file it consume the resources but does not clear the resources once its has completed its work
and if we keep converting different file services reaches the defined limit and eventually its gets crashed
Ideally groupdocs should clear the resources once the conversion is completed
What do you mean under “CPU”? May be you set RAM (Memoty) limit 1.5 GB? If so, it’s quit low, please try at least 2Gb, or 4Gb better
CPU and memory resource are 2 different
and memory i have set as 5 GB
the service is not clearing memory also
Please look into this why groupdocs service is not clearing up resources once it has done conversion
we are a paid customer
Hi, I think, we able to reproduce the issue. When a conversion request made, memory consumption increase and stay same even after request complete, but if a new request made, then memory consumption decrease. We will continue the investigation and will notify about results.
We are a paid customer when can we expect a fix we are facing issues in our production env because of this
Hi, we still working on this. Cannot say an exact ETA at the moment. As soon as we have more information, a notification will be posted in this topic.
Hi,
We are still facing same issue even we are using groupdocs/conversion-cloud:latest tag. Could you please help here ?
@sopan09
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CONVERSIONCLOUD-634
Hi, @piyush.rajput ,
For better issue analysis, could you please share some details:
What conversion formats are you performing ?
Mainly office files - xl, work, ppt…etc
And converting to pdf and png
That is typical file size you converting?
Max file size is 400MB
How many conversions performed before issue appear?
Not sure
Which CPU and Memory settings are you using?
We have deployed in k8s infra. Here is the resource config:
resources:
requests:
memory: “1Gi”
cpu: “1000m”
limits:
memory: “5Gi”
cpu: “8000m”
Thanks for information. We will perform testing and analysis and will be back with a responce
Hi @sergei.terentev
Just checking in to see if there are any updates regarding the testing and analysis. Looking forward to hearing back. Thanks!
Hi, @piyush.rajput , after analysis and testing, here is a brief report of the issue:
if you are running GroupDocs Conversion Cloud in a self-hosted container and notice that memory usage climbs after each conversion and never fully drops back, this is expected behavior — not a memory leak.
Why it happens
The .NET runtime manages its own memory heap. After a conversion completes, the runtime frees all managed objects internally but intentionally holds onto the OS memory pages for reuse on the next request. This avoids the overhead of repeatedly requesting memory from the OS. From Docker or Kubernetes’ perspective, the container’s RSS (resident memory) stays high even when the service is idle.
What to do
Set the DOTNET_GCConserveMemory environment variable. It tells the .NET garbage collector to actively return unused memory pages back to the operating system rather than holding onto them. The value is a scale from 0 (default, performance-optimized) to 9 (most aggressive memory trimming).
For document conversion workloads, a value of 9 is recommended:
env:
- name: DOTNET_GCConserveMemory
value: "9"
You can also set a hard ceiling on the GC heap to prevent the process from ever claiming more than a fixed amount. For example, to cap at 800 MB:
env:
- name: DOTNET_GCConserveMemory
value: "9"
- name: DOTNET_GCHeapHardLimit
value: "838860800"
Pair with a restart policy
Document conversion involves native libraries for font rendering and image processing. These allocate memory outside the .NET heap, which the GC cannot control. Over extended uptime under heavy load, this native memory can accumulate. The practical safeguard is a Kubernetes liveness probe combined with memory-based resource limits:
resources:
limits:
memory: "1Gi"
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 30
failureThreshold: 3
When the container exceeds its memory limit, Kubernetes will restart it automatically. Combined with DOTNET_GCConserveMemory, this keeps your pods lean during normal operation and recovers cleanly in edge cases.
Summary
| Setting | Purpose |
|---|---|
DOTNET_GCConserveMemory=9 |
Return managed heap pages to OS aggressively |
DOTNET_GCHeapHardLimit |
Hard cap on .NET heap size |
resources.limits.memory |
Kubernetes-level safety net |
| Liveness probe | Auto-restart on health failure |
For most self-hosted deployments, DOTNET_GCConserveMemory=9 alone produces a noticeable reduction in idle memory footprint with negligible impact on conversion throughput.
Thank you @sergei.terentev for the detailed analysis and update on this.
We will implement the recommendations and monitor. We will update you on the result.
You welcome!