Jrockit JVM Memory Parametreleri, Performans Tuning ve Garbage Collection

Bir çoğumuz Java uygulamalarımıza memory ataması yaparken minimum ve maksimum heap size değerlerini verir ve öyle çalıştırırız. Çoğu kez sorun yaşamasak da uygulamada oluşabilecek memory problemlerinin tespiti ve yoğun uygulamalarımızın daha efektif çalışması için garbage collection loglamasını enable etme ve ek garbage collection parametrelerini set etme ihtiyacı duyarız. Bu noktada sizlere Jrockit'in bazı memory parametreleri ve garbage collection işlemleri hakkında bilgi vermeye çalışacağız.

Bir JVM i start ederken en temel şekilde aşağıdaki parametreleri veririz:

 Xms: JVM in başlarken alacağı minimum memory değerini belirtir.

ör: -Xms8G

-Xmx: JVM devam ettiği sırada alacağı maksimum memory değerini belirtir.

ör: -Xmx16G

Şimdi biraz yaşayabileceğimiz memory problemlerimiz sonrasında elimizde incelemek üzere nasıl data oluşturacağımza bakalım. Aşağıdaki parametreler Weblogic managed serverların start up parametrelerine eklenerek istenen çıktılar elde edilebilir:

-XX:+|-CrashOnOutOfMemoryError: Out of memory durumunda port ayakta kalır, ancak uygulama cevap vermez. Bu seçenek etkinleştirildiğinde ’out of memory’  hatası olması durumunda  JVM down durumuna geçer.

             ör: -XX:+CrashOnOutOfMemoryError

-XX:+|-HeapDiagnosticsOnOutOfMemoryError: Bu seçenek etkinleştirildiğinde, ‘out of memory’ hatası olması durumunda heap in o anki durumunu belirtir bir rapor üretilir. Bu rapor dosyası - XX:HeapDiagnosticsPath seçeneği ile belirlenen dizine yazılır.

                ör: -XX:+HeapDiagnosticsOnOutOfMemoryError -XX:HeapDiagnosticsPath=D:\myapp\diag_dumps 

-XX:+|-HeapDumpOnOutOfMemoryError: Bu seçenek ile out of memory  hatası  durumunda heap dump oluşturulur. Sonrasında bu oluşturulan heap dump dosyası Eclipse Memory Analyzer ya da benzeri bir tool ile incelenerek olası memory problemleri tespit edilmeye çalışılır.

              ör: -XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath: -XX:+|-HeapDumpOnOutOfMemoryError seçeneği etkinleştirildiğinde oluşturulacak heap dump ın dizinini ve dosya ismini belirlenir.

       ör: -XX:+HeapDumpOnOutOfMemory -XX:HeapDumpPath=D:\myApp\hprof-dumps

-XXtlaSize: Muti-thread çalışan uygulamalarda thread başında memory ayarlaması amacıyla kullanılır. TLA, Java uygulamasının kullandığı objelerin boyutuna veya fazlalığına göre ayarlanmalıdır. Parametrelere eklenecek değerler şu şekildedir.

min= TLA minimum değeri

preferred=TLA tercih edilen değeri

wasteLimit=Bir TLA’nın izin verilen en büyük memory değeri

                ör: -XXtlasize:min=2k,preferred=16k

Garbage Collection:

JVM e min ve max heap size değelerini set edip start ettiğimizde sistemden belirtilen memory değerini sistemin fiziksel memory sinden allocate eder ve uygulamaya verir. Bu noktadan sonra uygulama JVM'e ayrılmış bu miktardan sürekli olarak memory alır ve işini yürütmeye devam eder. Uygulama çalışmaya devam ettikçe yeni aldığı memory çöp haline gelir ve artık kullanılamaz durumdadır. Bu nedenle sürekli yeni memory ihtiyacı hisseder. Oysa biz memory i max heap size değeri ile sınırlamıştık. Dolayısıyla uygulama tarafından kullanılan ve çöp haline gelen bu memory nin bir şekilde bir geri dönüşüm işlemine sokulması gerekmektedir. İşte bu geri dönüşüm işlemine Garbage Collection denmektedir.

Heap üzerinde bir GC işlemi başladığında aşağıdaki şekilde görünen heap in tamamı taranarak o an kullanılmayan (referans gösterilmemiş) objeler belirlenir ve ikinci şekildeki gibi (After Marking) heap haritası çıkarılmış olur. Bu noktadan sonra temizleme işlemi başlar ve free memory oluşturularak uygulamanın yeniden kullanımına hazır hale getirilmiş olur.

Yukarıda bir GC işlemini kabaca anlatmaya çalıştık.Şimdi biraz daha detaya inelim. GC'nin iki farklı tipi vardır.

Young Garbage Collection :

Young generation üç hafıza alanından oluşmaktadır. Bunlar Eden, Survivor 1 ve Survivor 2 hafıza alanlarıdır. Bir JVM start olup uygulamayı available hale getirdiğinde objelerin hepsi Eden space'de oluşur. Survivor 1 ve Survivor 2 alanları ise geçici ara bellek alanlarıdır. Eden hafıza alanı dolduğunda, Garbage Collector live objeleri önce boş olan Survivor alanlarından birisine kopyalar. Bu işlemin ardından Garbage Collector Eden ve kullanımda olan Survivor alanını boşaltır. Eden hafıza alanı tekrar dolduğunda, live objeler ve dolu olan Survivor alanındaki nesnelerin hepsi tekrar boş olan Survivor alanına kopyalanır. Her zaman bir Survivor alanı boştur ve bir sonraki Young Garbage Collection işlemi sonunda live objeleri bünyesine alacak şekilde pasif olarak bekler.. 

Old Garbage Collection :

Young GC işlemlerinin yeterli olmadığı durumlarda Old GC devreye girer. Bu işlem sırasında o sırada JVM üzerinde aktif olarak çalışan tüm thread ler durdurularak temizleme işlemi başlatılır ve işlem bitince tüm thread ler kaldıkları yerden devam ederler. Temizlenecek heap ne kadar büyükse (max heap size) Old GC (Full GC) de bir o kadar uzun sürecektir. Dolayısıyla uygulamamız için optimum max heap size değerini bulmamızda fayda var. GC süresi ne kadar uzunsa kullanıcılar bu işlem sırasında o kadar fazla bekleyeceklerdir. (donma)

 Aşağıdaki grafik Young ve Full GC işlemlerini göstermektedir. Görüldüğü üzere testereye benzeyen şekilde ayrıca küçük merdivenler de bulunmaktadur. İşte her bir testere dişindeki ufak merdiven basamaklarını andıran bu işlemler Young GC işlemlerini göstermektedir. Her bir testere dişi de Full GC işlemlerini temsil eder. Biraz daha açıklamak gerekirse JVM start edildikten sonra belli aralıklarla Full GC işlemlerine tabi tutulmuş, her Full Gc sonrası memory kullanımı 500 MB seviyelerinden 250 MB seviyelerine inmiştir. Testere dişlerinin en dip noktalarını biz çizgi ile birleşirdiğimizde doğruya yakın bir şekil oluşmasını bekleriz. Eğer yukarıya doğru eğilmi bir doğru oluşuyorsa bu, uygulamamızda bir memory leak  olduğunu gösterir. Bu tip bir durumd belli bir süre sonra Full GC işlemleri sonrası free memory miktarı daha yüksek seviyelerde kalacak ve bir müddet sonra Full Gc işlemi anlamsız olacak, sonuç olarak da JVM Out Of Memory hatası alarak duracaktır.

Garbage Collection işleminden bahsettikten sonra Jrockit'in GC parametreleri hakkında bilgi verebiliriz. Bu açıklamalar ışığında sizler de uygulamanıza en uygun GC algoritmasını seçip performans tuning işlemlerinizi yapabilirsiniz. Ancak daha önce belirttiğimiz gibi uygulamanız inanılmaz derecede memory kullanmıyorsa Jrockit'e sadece min ve max heap size değerlerini vermeniz bile yeterli olabilir. Deneyip kontrol etmenizde fayda var.

Jrockit GC Parametreleri

-Xgcprio:pausetime : GC sırasında uzun duraksamalar istemiyorsak bu parametreyi kullanabiliriz. Paralel GC işleminden biraz daha fazla kaynak (cpu ve memory) tüketimine neden olur.

ör: -Xgcprio:pausetime -XpauseTarget:250 (-XpauseTarget parametresi verilmezse default 200 ms kabul edilir) 

-XgcPrio:throughput: Uygulamanın  optimum throughput sağlaması için bu seçenek kullanılır. Bu seçenek kullanıldığında Full GC sırasında belirlenemeyen uzun süreli stop time lar oluşabilir. Ancak yine de GC işlemi olabildiğince optimum çalışır ve JVM thread lere verebildiği kadar cpu kaynağı verir. Default değer budur.

ör: -XgcPrio:throughput 

-XgcPrio:deterministic:Çok kısa ve öngörülen stop time lar için bu parametre kullanılır. Verilen pause time’dan daha kısa sürede GC işlemleri bitirilmeye çalışılır.

-Xgc:genpar  Genel GC tipidir. Objeler önce Young Generation space de toplanır. Nursey size (Young Generation Space) full olduğunda Jrockit, JVM in tüm thread lerini durdurur ve paralel Nursery GC işlemini başlatır. Bu sırada uygun durumda olan tüm CPU kaynakları kullanılarak live durumda olan tüm objeler YG space den Old Generation space e taşınır. Bütün heap dolduğunda ise Old GC collector tüm thread leri durdurarak Full GC işlemini başlatır.

-Xgc:gencon  Bu algoritmada genel ve eş zamanlı bir GC işlemi yapılır. Objeler Nursery size’da toplanır. Nursery size dolduğunda tüm JVM thread ler durdurulur ve tüm live objeler Old Generation Space e taşınır ve Full GC işlemi yapılr.

-Xns: Uygulamamız çok fazla geçici obje oluşturuyorsa, bu parametreyi yüksek vermemizde fayda vardır.




       ör: -Xns:1G

Default Nursery Size
Options	Default value
-server (default)	free heap in %50 si
-Xgc:gencon	sanal işlemci başına 10 MB
-Xgc:genpar	free heap in %50 si
-Xgcprio:throughput	sanal işlemci başına 10 MB
-Xgcprio:pausetime	free heap in %50 si

-XXgcThreads:  Full GC yapılırken aynı anda kaç thread ile JVM in temizleneceğini belirtir. Bu parametre kullanıldığında CPU tüketimi artar ancak GC süresi azalır. Cpu bakımından güçlü serverlarda bu parametre kullanılabilir.

       ör: -XXgcThreads:4







GC Loglamasının Enable Edilmesi:

-Xverbose: JVM output u hakkında bilgi verir.

         ör:-Xverbose:memory 

-Xverboselog: GC loglarının (JVM out put) dizininin ve log isminin tanımlanmasını sağlar.



         ör: -Xgc:genpar -Xverboselog:/log/dizini/logname_gc.log -Xverbose:memory



Yukarıdaki parametrelerin eklenmesinin ardından JVM restart edilirse; GC loglaması enable duruma getirilmiş olur. Aşağıda örnek GC logları görülebilir.