Reduce RAM usage when nobody is connected

[unruha]

I have a quick question regarding server RAM usage. I'm running multiple paper servers in a kubernetes cluster. Each server runs in a pod. Each server is limited to 4GB of RAM.

I've noticed that even when no players are connected to a server, the server is still using most of the ram that is allowed. This is causing the cluster autoscaler to create more nodes than I'd think would be necessary, given that no players are connected to a server. This is causing excess charges from the cloud provider.

Is there some way to reduce RAM usage on a server when no users are connected? The way that the CPU usage reduces when no users are connected.

[itzg]

If you're using the MEMORY variable, perhaps instead set INIT_MEMORY and MAX_MEMORY separately with init/starting being much lower.

In general, read through https://www.baeldung.com/gc-release-memory

I'm confused why you say the autoscaler kicks in after the pod is running and users have left. What value are you using for memory requests? That's primarily what k8s uses to schedule pods by memory.

[unruha]

Thanks for the response. Regarding the autoscaler, it looks like I may have worded that poorly. The issue is that a server will be added to the cluster, then players will connect and play on it. This causes the RAM usage to go up to the limit of 4GB which sometimes causes the autoscaler to add a new node to schedule the pod. But after the players disconnect from the server, the RAM usage of the pod remains at 4GB, so the autoscaler is never able to scale down the cluster and remove the node. This is causing extra computing costs.

Ideally, I'd like the server to free up the memory when no players are connected so that the autoscaler can scale down the cluster. After reading the document you linked, it looks like -XX:MaxHeapFreeRatio may be an option. Is there an interface to access this from outside the pod? Also, could you explain why setting INIT_MEMORY lower than MAX_MEMORY could be a solution?

Thank you.

Here is my current configuration:

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mc-vanilla1
spec:
  replicas: 1
  serviceName: mc-vanilla1-svc
  selector:
    matchLabels:
      app: mc-vanilla1
  template:
    metadata:
      labels:
        app: mc-vanilla1
    spec:
      containers:
        - image: itzg/minecraft-server
          name: mc-vanilla
          env:
            - name: "EULA"
              value: "true"
            - name: "TYPE"
              value: "PAPER"
            - name: "MEMORY"
              value: "3200m"
            - name: "VIEW_DISTANCE"
              value: "10"
            - name: "SIMULATION_DISTANCE"
              value: "5"
          ports:
            - containerPort: 25565
              name: main
          resources:
            requests:
              cpu: "1200m"
              memory: "4Gi"
            limits:
              cpu: "1200m"
              memory: "4Gi"
          readinessProbe:
            exec:
              command: ["/usr/local/bin/mc-monitor", "status", "--host", "localhost"]
            initialDelaySeconds: 90
            periodSeconds: 10
            failureThreshold: 12
          livenessProbe:
            exec:
              command:
              - mcstatus
              - localhost
              - ping
            initialDelaySeconds: 90
            periodSeconds: 5
          volumeMounts:
            - mountPath: /data
              name: data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 50Gi
---

[itzg]

Thanks for clarifying

Ideally, I'd like the server to free up the memory when no players are connected so that the autoscaler can scale down the cluster. After reading the document you linked, it looks like -XX:MaxHeapFreeRatio may be an option. Is there an interface to access this from outside the pod?

Yes, you can pass those types of JVM options via JVM_XX_OPTS. Let me know if that flag does indeed resolve the scenario for you. Maybe there's a reasonable default I can include with the image.

Also, could you explain why setting INIT_MEMORY lower than MAX_MEMORY could be a solution?

The flag you found is probably more useful, but theory with separate values is the following:

Let's say you set INIT_MEMORY to 1G, which is the starting heap size. If it turns out that while players are joined the heap only gets up to 2G, then that's all it'll allocate. Where when using MEMORY to sets the start/init to same as max, so you're always telling it to allocate 4G.