# Ad Service Manual Garbage Collection

### Failure scenario

This performance issue is triggered by enabling the `adManualGc` flag in the Flagd config (ConfigMap on Kubernetes) or Flagd UI.

When activated, this flag forces manual garbage collection in the `ad` service.

## Root Cause Analysis by Coroot

### How it works

#### 1. Anomaly detection

Coroot identified an anomaly in the `frontend-proxy` service, detecting increased latency and failed requests.

#### 2. eBPF-based metrics correlation

Using eBPF metrics, Coroot connected the `frontend-proxy`’s performance issues to the `frontend` service, and finally to the `ad` service.

#### 3. Understanding the cause

The increase in the `ad` service latency correlates with JVM safepoints caused by garbage collection activity

### Results

2/3

Detection of the problematic service:

Coroot identified the `ad` service as the source of the issue.

Immediate fixes provided:

Partial. Increasing the memory limit might help in real scenarios, but the best solution is to profile the application's memory usage and address the root cause.

Additional details:

Coroot did not detect feature flag involvement because it was missing from the trace attributes, but it did identify JVM GC pressure as a contributing factor.

### LLM Usage Details

Model: Anthropic Claude Sonnet 4 (claude-sonnet-4-20250514)

Token usage: 18,265 input tokens • 630 output tokens

Estimated cost: ~$0.06 USD

Based on $3 per 1M input tokens, $15 per 1M output tokens

## Try Coroot's AI RCA in your environment

See how Coroot finds root causes for your real production issues with a full enterprise trial.

[Try it free](https://coroot.com/account/signup) [Back to benchmark](https://coroot.com/ai-benchmark)