JVM Konteynerde — Bellek Sınırı Heap'ten Büyüktür

Asansörde “en fazla 600 kg” yazar. Yolcuları sayarsın, sığıyor; sonra herkes valizini de içeri çeker.

JVM’i bir konteynere koyduğunda bellek sınırı tam bu tartı gibi çalışır. Heap yolculardır; ama tartı valizleri de sayar.

Heap, sürecin yalnızca bir parçası

Konteynerin sınırını Linux’ta cgroup?Terimin tanımını açcgroupLinux çekirdeğinin bir süreç grubuna bellek ve CPU sınırı koyduğu mekanizma. Docker ve Kubernetes konteyner sınırlarını bununla uygular.JDK 10'dan beri JVM sınırları cgroup'tan okur (UseContainerSupport). Bellek sınırı sürecin bütün belleğini sayar.Sözlükte gör → koyar ve bu kalemlerin hepsini birlikte sayar. Spring Boot’lu tipik bir serviste heap dışı kalemler yüzlerce MiB tutabilir.

JVM heap’i nasıl seçer?

JDK 10’dan beri JVM konteynerde çalıştığını anlar ve sınırı cgroup’tan okur. Heap’in tavanını bu sınıra göre seçer.

Heap’i sabit bir -Xmx ile değil, sınırın bir yüzdesiyle vermek daha güvenlidir. Sınır büyüyüp küçüldüğünde ayar da onunla gelir.

java -XX:MaxRAMPercentage=50 -jar payment.jar

İki farklı ölüm

Heap yetmezse JVM OutOfMemoryError fırlatır. Logda yığın izi olur, ayarlıysan bir heap dump da alınır.

Bütün süreç sınırı geçerse karar Java’nın değil, çekirdeğin OOM killer?Terimin tanımını açOOM killerBellek sınırı aşılınca Linux çekirdeğinin bir süreci SIGKILL ile anında sonlandırması. Süreç hiçbir şey yazamaz; çıkış kodu 137 olur.Kubernetes bunu konteyner durumunda OOMKilled olarak gösterir. Java'nın OutOfMemoryError'ından farklıdır: o JVM'in içinde fırlatılır ve iz bırakır.Sözlükte gör →’ının olur. Süreç SIGKILL ile anında biter: çıkış kodu 137, Kubernetes’te durum OOMKilled. Java tek satır bile yazamaz.

Heap dışı kalemleri görmek için Native Memory Tracking açılır: -XX:NativeMemoryTracking=summary ve sonra jcmd PID VM.native_memory summary.

Kendin gör

2 GiB’lık konteynerde bir ödeme servisi var ve trafik tepe noktasına çıkıyor. Heap ayarını ve thread sayısını seç, belleğin nereye gittiğini izle.

1. Varsayılanı oynat. -Xmx2g: heap büyüdükçe toplam sınırı geçiyor ve süreç sessizce ölüyor.
2. “Hiç ayar yok”u seç. Bu kez heap dar: konteynerde boş yer varken OutOfMemoryError.
3. Yüzde 75’i dene, sonra 400 thread’i aç. Thread yığınları da sınırdan yiyor.
4. 400 thread’le tepe noktasını sağ atlatan ayarı bul.

Tuzaklar

-Xmx’i sınıra eşitlemek. Heap dışı kalemlere yer kalmaz; süreç yükte öldürülür.

Çok küçük CPU sınırı. JVM işlemci sayısını da konteynerden okur. İkiden az işlemci görürse G1 yerine Serial GC seçer ve havuzlarını küçük kurar.

Sınırı ölçmeden seçmek. Heap dışı pay her serviste farklıdır; NMT ile bir kez ölçülür ve yüzde ona göre ayarlanır.

1
FROM eclipse-temurin:21-jre
2
COPY build/libs/payment.jar /app/payment.jar
3
# Heap as a share of the container limit, measured with NMT; the rest is native headroom.
4
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=60 \
5
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps \
6
  -XX:NativeMemoryTracking=summary"
7
ENTRYPOINT ["java", "-jar", "/app/payment.jar"]

1
spec:
2
  template:
3
    spec:
4
      containers:
5
        - name: payment
6
          image: registry.bank.local/payment:1.8.0
7
          resources:
8
            requests:
9
              memory: "2Gi"
10
              cpu: "2"
11
            limits:
12
              memory: "2Gi"
13
          volumeMounts:
14
            - name: dumps
15
              mountPath: /dumps
16
      volumes:
17
        - name: dumps
18
          persistentVolumeClaim:
19
            claimName: payment-dumps

1
server:
2
  tomcat:
3
    threads:
4
      # Each platform thread has its own stack outside the heap.
5
      max: 150

#!/usr/bin/env bash
# Usage: memory-breakdown.sh <pid>. Prints where the process memory goes.
set -euo pipefail
jcmd "$1" VM.native_memory summary | head -60
jcmd "$1" GC.heap_info

Kendini sına

Önce hızlı bir ısınma: puan yok, kayıt yok. Sonra asıl sorular.