Memory is not released after traffic stops in APISIX pods deployed with HPA on Kubernetes

**Current Behavior**
When deploying APISIX via the Helm chart in a Kubernetes cluster, I am using a Horizontal Pod Autoscaler (HPA) that allows scaling up to 5 pods. During periods of sustained traffic, memory usage in each APISIX pod increases as expected. However, after the traffic stops, the memory used by the pods is not released. The only way to recover memory is to manually restart the pods; otherwise, the memory remains high even if no new requests are received.

**Expected Behavior**
Memory should be released automatically when the traffic decreases or stops, without the need to restart the pods.

**Steps to Reproduce**
1. Deploy APISIX using the official Helm chart with an HPA configured (up to 5 pods).
2. Send traffic to APISIX for a sustained period.
3. Stop all traffic to APISIX.
4. Observe that memory usage in the pods does not decrease.
5. Restarting the pods is the only way to free up the memory.

**Environment**

- APISIX version: 3.12
- Helm chart version: 2.10
- Kubernetes version: 1.29
- Cloud provider or local cluster: Azure (AKS)
- Any custom plugins: Prometheus exporter

**Additional Information**
Requests and limits for memory are properly set in the deployment.

The issue persists regardless of the number of pods.

No OOMKill events, but memory remains high until pod restart.

This behavior affects cluster resource efficiency and can lead to unnecessary restarts.

**Question**
Is this a known issue or limitation? Are there recommended configurations or best practices to ensure APISIX releases memory automatically after traffic spikes? Any guidance or workaround would be appreciated.

Start by reviewing the Helm chart's HPA and deployment configuration, then reproduce the reported memory behavior in Kubernetes using APISIX 3.12 and chart 2.10 with the Prometheus exporter enabled. Compare memory before, during, and after sustained traffic; done means identifying a chart configuration issue, a reproducible defect, or a documented workaround.

Written by the indexing model from the issue text.