OpenJ9 ile JVM Bellek Tüketimini Azaltma ve Microservice Optimizasyonu

Yazar:komut.io ekibi Java ve JVM Ortamı Kurulumu
0 Yorum

Microservice dünyasında en büyük şikayetlerden biri Java’nın bellek iştahıdır. “Servis sayısını artır” dediğinde JVM öyle bir bellek tüketmeye başlar ki, altyapı maliyetleri tavan yapar. Tam da bu noktada IBM’in OpenJ9 projesi sahneye çıkıyor. HotSpot’a alternatif bu JVM implementasyonu, özellikle konteyner ortamlarında ciddi bellek tasarrufu sağlıyor. Ben de bu yazıda gerçek prodüksiyon deneyimlerimden yola çıkarak OpenJ9’u nasıl kurar, yapılandırır ve microservice yükü için optimize edersiniz, onu anlatacağım.

OpenJ9 Nedir ve Neden Önemlidir?

OpenJ9, IBM’in J9 JVM’ini Eclipse Foundation altında açık kaynak olarak sunduğu bir proje. HotSpot’tan temel farkı, tasarım felsefesinde yatıyor: HotSpot “mümkün olduğunca hızlı çalış” derken OpenJ9 “mümkün olduğunca az kaynak kullan” diyor. Microservice ortamlarında bu fark hayat kurtarıcı.

Gerçek sayılara bakacak olursak; aynı Spring Boot uygulamasını HotSpot ile çalıştırdığımda ~350MB heap kullanırken OpenJ9 ile aynı yük altında ~180MB’a düşürmeyi başardım. Bu %48’lik bir düşüş demek. Kubernetes üzerinde 20 replika çalıştırıyorsanız bu rakam çok ciddi bir maliyet farkına dönüşüyor.

OpenJ9’un öne çıkan özellikleri:

  • Shared Class Cache (SCC): JIT derlenmiş kodları disktte saklayarak yeniden başlatma sürelerini kısaltır
  • AOT (Ahead of Time) Compilation: Uygulama başlangıcında derleme yaparak warm-up süresini azaltır
  • Agresif GC politikaları: Farklı workload’lar için optimize edilmiş çöp toplama stratejileri
  • Container-aware bellek yönetimi: cgroup limitlerini doğal olarak anlayan akıllı heap boyutlandırması

Kurulum: AdoptOpenJDK / Eclipse Temurin ile OpenJ9

OpenJ9’u edinmenin en kolay yolu Eclipse Temurin (eski adıyla AdoptOpenJDK) dağıtımları üzerinden gitmek. Bu dağıtımlar hem HotSpot hem de OpenJ9 varyantlarını sunuyor.

Ubuntu/Debian Sistemlerde Kurulum

# Adoptium repository ekle
wget -O - https://packages.adoptium.net/artifactory/api/gpg/key/public | sudo gpg --dearmour -o /usr/share/keyrings/adoptium.gpg

echo "deb [signed-by=/usr/share/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | sudo tee /etc/apt/sources.list.d/adoptium.list

sudo apt update

# OpenJ9 tabanlı JDK 17 kurulumu
sudo apt install temurin-17-jdk-openj9 -y

# Kurulumu doğrula
java -version
# eclipse openj9 ifadesini görmelisiniz

RHEL/CentOS/Rocky Linux Sistemlerde Kurulum

# Adoptium repo dosyasını oluştur
cat <<EOF | sudo tee /etc/yum.repos.d/adoptium.repo
[Adoptium]
name=Adoptium
baseurl=https://packages.adoptium.net/artifactory/rpm/rhel/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.adoptium.net/artifactory/api/gpg/key/public
EOF

sudo dnf install temurin-17-jdk-openj9 -y

# Alternatif olarak sdkman ile kurulum
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk install java 17.0.9_9-openj9
sdk use java 17.0.9_9-openj9

Docker Container’ı İçin Temel Kurulum

Çoğu zaman geliştirme ortamında değil, direkt container içinde kullanacaksınız. Base image seçimi kritik:

# Küçük ayak izi için icr.io/appcafe/ibm-semeru-runtimes kullanabilirsiniz
# Ama Temurin de mükemmel çalışıyor
FROM eclipse-temurin:17-jre-openj9

WORKDIR /app

# Shared Class Cache için dizin oluştur
RUN mkdir -p /opt/shareclasscache

COPY target/myapp.jar app.jar

# OpenJ9 optimize JVM parametreleri
ENV JAVA_OPTS="-Xms64m 
  -Xmx256m 
  -XX:+UseContainerSupport 
  -Xshareclasses:cacheDir=/opt/shareclasscache 
  -Xscmx128m 
  -XX:+IdleTuningGcOnIdle 
  -XX:IdleTuningMinIdleWaitTime=180"

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

Bellek Optimizasyonu: Temel Parametreler

OpenJ9’da bellek yönetimi HotSpot’tan farklı çalışıyor. Parametreleri doğru ayarlamak, performans ile tasarruf arasındaki dengeyi bulmak için kritik.

Heap Boyutlandırması

# OpenJ9'da -Xms ve -Xmx'e ek olarak -Xmn (nursery/young gen) kontrolü
# Microservice için tipik başlangıç noktası:
java -Xms32m 
     -Xmx256m 
     -Xmns16m 
     -Xmnx128m 
     -jar myservice.jar

# Mevcut heap kullanımını görmek için
java -Xms32m -Xmx256m -verbose:gc -jar myservice.jar 2>&1 | grep "GC cycle"

OpenJ9’da dikkat etmeniz gereken önemli parametreler:

  • -Xms: Başlangıç heap boyutu, microservice için düşük tutun (32-64MB)
  • -Xmx: Maksimum heap, container limitinin %75’i iyi bir başlangıç noktası
  • -Xmns: Nursery (young generation) minimum boyutu
  • -Xmnx: Nursery maksimum boyutu
  • -Xsoftmx: Soft maksimum heap, JVM daha fazla belleğe ihtiyaç duyduğunda aşabilir ama önce GC çalıştırır
  • -Xcompressedrefs: 32GB altı heap için otomatik devreye girer, pointer boyutunu küçültür

GC Politikaları

OpenJ9’un en güçlü özelliklerinden biri çoklu GC politikası desteği:

# Varsayılan - dengeli performans ve verim
java -Xgcpolicy:gencon -jar myservice.jar

# Minimum bellek kullanımı için (latency'den ödün verilir)
java -Xgcpolicy:metronome -jar myservice.jar

# Throughput odaklı, batch işlemler için
java -Xgcpolicy:optthruput -jar myservice.jar

# Düşük duraklama süresi için (çoğu microservice için ideal)
java -Xgcpolicy:balanced -jar myservice.jar

Prodüksiyonda çoğu REST API microservice’i için gencon veya balanced politikasını tercih ediyorum. gencon, kısa ömürlü nesnelerin yoğun olduğu tipik web servislerinde harika çalışıyor.

Shared Class Cache (SCC) Yapılandırması

SCC, OpenJ9’un belki de en az bilinen ama en değerli özelliği. JIT derlenmiş kodu ve sınıf meta verisini diske kaydedip sonraki başlatmalarda yeniden kullanıyor. Kubernetes pod’larını düşünün: her yeni pod soğuk başlarsa JIT warm-up ciddi gecikme yaratır. SCC bunu çözüyor.

# SCC oluştur ve doldur (uygulama bir kez çalışsın)
java -Xshareclasses:name=myapp-cache,cacheDir=/tmp/scc 
     -Xscmx256m 
     -jar myservice.jar &

# Servisi biraz çalıştırın, sonra durdurun
sleep 30 && kill %1

# Cache boyutunu ve doluluk oranını kontrol et
java -Xshareclasses:name=myapp-cache,cacheDir=/tmp/scc,printStats 
     -version 2>&1 | grep -E "cache size|bytes stored"

# Sonraki başlatmalarda cache'i kullan
java -Xshareclasses:name=myapp-cache,cacheDir=/tmp/scc 
     -Xscmx256m 
     -jar myservice.jar

Kubernetes’te SCC ile Init Container Pattern

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myservice
spec:
  template:
    spec:
      initContainers:
      - name: scc-warmup
        image: myservice:latest
        command: ["/bin/sh", "-c"]
        args:
        - |
          java -Xshareclasses:cacheDir=/scc,name=myapp 
               -Xscmx128m 
               -cp /app/app.jar 
               com.example.WarmupRunner && echo "SCC populated"
        volumeMounts:
        - name: scc-volume
          mountPath: /scc
      containers:
      - name: myservice
        image: myservice:latest
        env:
        - name: JAVA_OPTS
          value: "-Xshareclasses:cacheDir=/scc,name=myapp -Xscmx128m -Xms32m -Xmx256m"
        volumeMounts:
        - name: scc-volume
          mountPath: /scc
      volumes:
      - name: scc-volume
        emptyDir: {}

Idle Tuning: Boşta Kalan Servislerin Optimizasyonu

Bu özellik OpenJ9’a özgü ve microservice dünyasında altın değerinde. Servis boşta kaldığında JVM heap’i küçülterek belleği OS’a geri veriyor. Bunu HotSpot’ta yapamazsınız.

# Idle tuning açık GC on idle aktif
java -Xms32m 
     -Xmx512m 
     -XX:+IdleTuningGcOnIdle 
     -XX:IdleTuningMinIdleWaitTime=180 
     -XX:IdleTuningMinFreeHeapOnIdle=20 
     -jar myservice.jar
  • IdleTuningGcOnIdle: Boşta kalındığında agresif GC çalıştırır
  • IdleTuningMinIdleWaitTime: Kaç saniye boşta kaldıktan sonra devreye girsin (saniye)
  • IdleTuningMinFreeHeapOnIdle: Boşta iken heap’in en az yüzde kaçı serbest olsun

Bir senaryoyu aktarayım: Gece yarısı trafiğin sıfıra düştüğü bir e-ticaret microservice’im vardı. HotSpot ile pod her zaman 400MB tutuyordu. OpenJ9 ve idle tuning ile gece bu 80MB’a düşüyordu. 10 replica üzerinde gecede yaklaşık 3.2GB bellek tasarrufu. Bunu maliyet olarak düşünün.

Spring Boot ile Pratik Entegrasyon

Gerçek dünya örneği olarak Spring Boot microservice’ini OpenJ9 ile nasıl optimize edeceğimize bakalım.

# Spring Boot native image yerine OpenJ9 AOT ile çalıştırma
# pom.xml'e gerek yok, JVM argümanları yeterli

# Uygulama başlatma scripti (production)
#!/bin/bash
JVM_ARGS="-server"
JVM_ARGS="$JVM_ARGS -Xms64m"
JVM_ARGS="$JVM_ARGS -Xmx512m"
JVM_ARGS="$JVM_ARGS -Xgcpolicy:gencon"
JVM_ARGS="$JVM_ARGS -Xshareclasses:cacheDir=/opt/scc,name=springapp"
JVM_ARGS="$JVM_ARGS -Xscmx256m"
JVM_ARGS="$JVM_ARGS -XX:+IdleTuningGcOnIdle"
JVM_ARGS="$JVM_ARGS -XX:IdleTuningMinIdleWaitTime=300"
JVM_ARGS="$JVM_ARGS -Xtune:virtualized"
JVM_ARGS="$JVM_ARGS -Djava.security.egd=file:/dev/./urandom"

exec java $JVM_ARGS -jar /app/application.jar "$@"

Buradaki -Xtune:virtualized parametresi önemli. Sanal makine veya container içinde çalıştığında CPU sayısı tespiti bazen yanlış yapılıyor. Bu parametre OpenJ9’un ortamı daha gerçekçi algılamasını sağlıyor.

Bellek Kullanımını İzleme

# OpenJ9 JVM'in gerçek bellek kullanımını görmek için
# Native bellek istatistikleri
java -Xms64m -Xmx256m 
     -Xmx256m 
     -XX:NativeMemoryTracking=summary 
     -jar myapp.jar &

APP_PID=$!

# Biraz bekle
sleep 15

# Native memory raporu al
jcmd $APP_PID VM.native_memory summary

# OpenJ9'a özgü verbose GC çıktısı
java -Xms64m -Xmx256m 
     -verbose:gc 
     -Xverbosegclog:/var/log/gc.log,5,10000 
     -jar myapp.jar

# GC log'unu analiz et (IBM GC and Memory Visualizer ile veya grep ile)
grep "gc end" /var/log/gc.log | tail -20

Konteyner Ortamı İçin İleri Seviye Optimizasyonlar

cgroup Limitlerini Tanıma

# Container'da maksimum bellek 512MB ise
# OpenJ9 bunu otomatik algılar ama explicit ayar daha güvenli

docker run --memory=512m 
  -e JAVA_OPTS="-XX:+UseContainerSupport 
                -XX:MaxRAMPercentage=75.0 
                -XX:InitialRAMPercentage=25.0 
                -Xtune:virtualized 
                -Xgcpolicy:gencon" 
  myservice:openj9-latest

# Yüzde bazlı heap ayarı (sabit değer yerine)
# Container 512MB ise: MaxRAMPercentage=75 -> Xmx ~384MB
# Container 256MB ise: MaxRAMPercentage=75 -> Xmx ~192MB

Çok Katmanlı Docker Image ile SCC

FROM eclipse-temurin:17-jdk-openj9 AS builder
WORKDIR /build
COPY . .
RUN ./mvnw package -DskipTests

FROM eclipse-temurin:17-jre-openj9 AS runtime
WORKDIR /app

RUN mkdir -p /opt/scc && chmod 777 /opt/scc

COPY --from=builder /build/target/app.jar app.jar

# SCC'yi image build sırasında populate et
RUN java -Xshareclasses:cacheDir=/opt/scc,name=myapp 
         -Xscmx128m 
         -Xms32m -Xmx256m 
         -jar app.jar 
         --spring.main.web-environment=false 
         --spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration 
         & sleep 20 && kill $!; exit 0

ENV JAVA_TOOL_OPTIONS="-Xshareclasses:cacheDir=/opt/scc,name=myapp 
  -Xscmx128m 
  -Xms32m 
  -Xmx256m 
  -Xgcpolicy:gencon 
  -XX:+IdleTuningGcOnIdle 
  -XX:IdleTuningMinIdleWaitTime=180 
  -Xtune:virtualized"

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Performans Karşılaştırması ve Benchmark

Bir microservice’i HotSpot ve OpenJ9 ile karşılaştırdığımda şu senaryoyu kullandım:

# Kısa bir yük testi ile bellek davranışını gözlemle
# wrk ya da ab kullanabilirsiniz

# Test 1: HotSpot
docker run --memory=512m --name hotspot-test 
  eclipse-temurin:17-jre myapp.jar &

# 30 saniye sonra bellek ölç
docker stats hotspot-test --no-stream --format "{{.MemUsage}}"

# Test 2: OpenJ9
docker run --memory=512m --name openj9-test 
  -e JAVA_TOOL_OPTIONS="-Xms32m -Xmx384m -Xgcpolicy:gencon -Xtune:virtualized" 
  eclipse-temurin:17-jre-openj9 myapp.jar &

docker stats openj9-test --no-stream --format "{{.MemUsage}}"

# Başlangıç süresini ölç
time docker run --rm eclipse-temurin:17-jre myapp.jar --spring.profiles.active=test &
time docker run --rm 
  -e JAVA_TOOL_OPTIONS="-Xshareclasses:cacheDir=/opt/scc -Xscmx128m -Xms32m -Xmx256m" 
  eclipse-temurin:17-jre-openj9 myapp.jar --spring.profiles.active=test &

Tipik sonuçlar prodüksiyonda şunlardır:

  • Boşta bellek kullanımı: HotSpot 280-350MB vs OpenJ9 120-180MB
  • İlk başlatma süresi: Benzer, OpenJ9 biraz yavaş olabilir
  • SCC sonrası başlatma: OpenJ9 %30-40 daha hızlı
  • Yük altında throughput: HotSpot biraz önde (%5-10), ama bellek tasarrufu bunu fazlasıyla telafi eder

Yaygın Sorunlar ve Çözümleri

Prodüksiyonda karşılaşacağınız en sık sorunlar:

  • OutOfMemoryError native memory alanında: -Xmx düşük tutulup GC overhead artabilir. -verbose:gc ile takip edin, gerçek kullanıma bakıp -Xmx değerini gerçekçi tutun
  • SCC cache corruption: Pod yeniden başladığında cache bozuk gelebilir. Cache dizinini emptyDir yerine kalıcı volume kullanıp reset parametresiyle temizleyin: -Xshareclasses:cacheDir=/scc,reset
  • Container CPU limiti ile JIT düşüşü: CPU throttling varsa JIT thread sayısını sınırlayın: -XcompilationThreads2
  • Yavaş ilk istek: SCC açık olsa bile warm-up gerekebilir. Kubernetes readinessProbe’u initialDelaySeconds ile geciktirin
  • verbose:gc log dolması: -Xverbosegclog:/path/gc.log,5,10000 formatı kullanın, 5 dosya 10000 satır döngüsel yazar

Sonuç

OpenJ9, microservice dünyasında HotSpot’a ciddi bir alternatif sunuyor. Özellikle çok sayıda replika çalıştırdığınız Kubernetes ortamlarında bellek tasarrufu doğrudan para tasarrufuna dönüşüyor. Shared Class Cache ile başlatma sürelerini kısaltmak, idle tuning ile boşta kalan servislerin belleği geri vermesini sağlamak, container-aware parametrelerle doğru boyutlandırma yapmak; bunların hepsi bir arada ciddi bir operasyonel avantaj yaratıyor.

Başlangıç için şu yolu izlemenizi öneririm: Önce mevcut uygulamanızı -Xms64m -Xmx256m -Xgcpolicy:gencon -Xtune:virtualized parametreleriyle OpenJ9’da çalıştırın, GC loglarına bakın, ardından SCC’yi devreye alın ve son olarak idle tuning’i ekleyin. Her adımda bellek kullanımını ölçün. Rakamlar sizi şaşırtacak.

Throughput açısından HotSpot ile baş başa olduğunuz ya da biraz geride kaldığınız senaryolarda bile, bellek tasarrufu sayesinde daha fazla replica çalıştırabilir ve toplam sistem throughput’unu artırabilirsiniz. Bu trade-off’u yapmaya değip değmeyeceğini her zaman kendi workload’ınızla ölçün, ama çoğu microservice senaryosunda OpenJ9 kazanıyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir