Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Omitting PULSAR_GC VM settings may lead to very high Proxy memory usage #161

Open
slawrencemd opened this issue Jan 16, 2024 · 0 comments
Open

Comments

@slawrencemd
Copy link

Hi guys,

Issue: Extremely high memory usage by the pulsar-proxy pods (4GB for proxy+websocket containers at idle)

Steps to reproduce:

Fixes attempted

  • changing pulsar image (tried variants of 3.0.0, 3.0.2, default)
  • setting resource limits for proxy (caused OOM kills, as expected)
  • setting higher requests for proxy
  • disabling just the websocket - this led to halving the memory usage (now only 2GB)!

I then did a vanilla deployment of Pulsar via the official Pulsar Helm Chart. This used ~200mb of memory. I compared the configmaps between this and the KAAP proxy, and noticed that the KAAP doesn't specify many JVM settings, especially w/r to the GC.

I set these explicitly in the config for the proxy with the values I saw in the official Pulsar instance. The resulting proxy instances exhibit normal memory consumption (~345Mb).

What I added was the config section was:

  proxy:
    replicas: 1
    resources:
      requests:
        cpu: "0.2"
        memory: "128Mi"
    config:
      PULSAR_GC: |
        -XX:+UseG1GC -XX:MaxGCPauseMillis=10 -Dio.netty.leakDetectionLevel=disabled -Dio.netty.recycler.linkCapacity=1024 -XX:+ParallelRefProcEnabled -XX:+UnlockExperimentalVMOptions -XX:+DoEscapeAnalysis -XX:ParallelGCThreads=4 -XX:ConcGCThreads=4 -XX:G1NewSizePercent=50 -XX:+DisableExplicitGC -XX:-ResizePLAB -XX:+ExitOnOutOfMemoryError -XX:+PerfDisableSharedMem

I saw that these were set in the past, but were removed in this commit, for reasonable reasons. My experience, and the fact that they are still explicitly set by the Pulsar devs may be a good reason to persist them...

If I can help triage this further, please let me know.

Environment

  • Azure Kubernetes Cluster (AKS)
  • kubectl v 1.28
  • k8s v: v1.25 (<< slightly behind, but don't expect this to matter here?)

-s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant