Weblogic'te Memory Yönetimi

Merhaba,

Bu akşam da weblogic'teki memory management kısmına değinelim.
Genel manada 3'e ayırabiliriz hafıza yönetimini(oracle dha farklı sınıflandırabilir, benimki daja pratiğe yönelik):

Heap Yönetimi: Server'ların start scriptlerinde veyahut man. server'ları grep'lediğinizde görebileceğiniz -Xms -Xmx değerlerinin karşılığıdır burası aslında.
Örneğin, -Xms:2048 ve -Xmx:3096 olsun. Burdan çıkan sonuç şudur: heap size en az 2GB olabilir ve ihtiyaç durumunda 3GB'a çıkabilir. İşletim Sistemi bu kadar alanı sadece sizin kullanımınız için ayıracaktır.

PermSize Yönetimi: JVM'lerin(Java Virtual Machine) garbage collectorleri malumunuz. Bunlar da dönem dönem memory temizliği yaparlar. Örneğin uygulamayı deploy ettiniz. Uygulamalar içinde statik nesneler de vardır. Onlar direkt PermSize'ın içine yerleşir. Bunlar garbage collector ile temizlenemez. Bunların değerlerini vermek önemlidir bu yüzden.
XX:PermSize=128m -XX:MaxPermSize=256m gibi.

Native Yönetimi: JVM, işletim sistemleri ile de konuşur bildiğiniz üzere(jvm üstündeki weblogic kodlarını makina diline çeviriyor). İşletim sistemleri ile de konuşmak için memory ihtiyacı ortaya çıkar. Buna da native denir. Uygulamanın karakteristiğine göre değişir. %50lere kadar çıkabilir. Değeri dinamiktir.(JRockit ile görüntülenebilir değeri).

Görüşmek üzere..

Weblogic JMS (Java Messaging Services)

Merhaba,
Bugün weblogic'te temel bir konuya değinmek istiyorum: Weblogic JMS.
 

 JMS, en temel tabirle, mesajlaşma üstünden haberleşmeye yarayan bir altyapıdır.
Örneğin abone bilgilerini BTK'ya ileten bir yapınız olsun. BTK gün içinde sistemini kapatırsa, abone bilgileri kayıp mı olacak, gönderemediğinizden ötürü? Tabi ki hayır. Bunu kuyruğunuzda tutmanız ve karşı taraf uygun olduğunda tekrar göndermeniz gerekir. JMS tam da bunun gibi asenkron mesajlaşmalar için uygundur. Düşünün, senkron bir mesajlaşma olsa, her client istekte bulunur ve cevap bekler.

Temelde 2 tip JMS var. Biri point-to-point diğeri topic JMS.

Point-toPoint JMS: 1 Client'ın isteği 1 kez gerçekleşir.




Gelen istekler, JMS Queue'dan geçer ve sadece bir application'a ya da server'a iletilir. Bu mesaj locklanır artık. Diğerleri göremez bu mesajı. Mesaj işlendikten sonra da bu mesaj queue'dan silinir.

Topic JMS: 1 Client'ın isteği, tıpkı broadcast yayını gibi, tüm uygulama ya da server'lara iletilir. Mesajın topic'ten silinip silinmemesi ayrı bir sorun teşkil eder. TimetoLive süresi belirlenmezse, sistemi patlatabilirsiniz.





Örneğin kampanya bilgisini tutan 50 server'ınız olsun. Bu durumda bu güncellemeyi tüm serverlarda yapmak durumunasınız. Bunun için de topic JMS kullanmanız kaçınılmaz.

JMS ile ilgili değinebilecek çok konu var ama son olarak Persistent Store'a da değinmek istiyorum. JMS Server'ına gelen mesajlar geçici olarak, karşı taraftan mesajın okunduğu/alındığı bilgisi gelene kadar, burada tutulur. Karşı taraf, namı diğer consumer, mesajı çekince ack bilgisi gönderilir ve store'dan silinir. Her bir jms server'a bir adet tahsis edilir. Bu persistent store, file ya da database olabilir. Her ikisinin de avantajı ve dezavantajları var. (Kişisel tercihim file kullanımı)
File persistent store'lar corrupt olabilir. Ancak çok çok hızlıdır. Database persistent store'ları ise, db'de uygun tablolarda yaratılmalı ve db mutlaka high available olmalı.

Kısaca JMS böyle. Daha sonra guaranteed messaging, conn factory, subdeployment gibi konulara da gireriz umarım.

İyi Akşamlar.