JConsole ile Performans Gözlem - Part 2

JConsole'un en önemli ve en kullanışlı tablarından birisi Memory tabı.. Memory'nin grafiği size durumun nasıl gittiğini anlatır. Neler olabileceğine dair fikirler verir. Figure 3'te gördüğünüz grafik sıradan bir Heap Memory'nin yaklaşık yarım saatlik süreçteki akışını göstermektedir. Grafiğin hemen altında yeşil renkle gördüğünüz sütunlar, değişik memory kısımlarını göstermektedir. Sırasıyla Survivor Space, Young Space, Old Space, Permanent Space, Code Cache Space'tir. Altlarındaki yatay çubuklar ise üzerlerindeki sütunların toplamlarını göstermektedir. Eğer JVM tune ediyorsanız, bu parçalar hakkında bilgili olmanızda fayda olacaktır. Bu parçalar hakkında yüzeysel birer açıklama yapayım.
Survivor Space : Swap Space gibidir, hafıza içerisinde yeri değiştirilecek nesneler için kullanılır.
Young Space : Hafızada süre olarak yeni olan objelerin tutulduğu yerdir. Minor GC bu kısımda yapılır.
Old Space : Göreceli olarak hafızada daha uzun süre yer alan nesneler burada tutulurlar. Major GC dediğimiz ve yapıldığı sürede JVM'in başka birşey yapamadığı Garbage Collection burada yapılır.
Permanent Space ve Code Cache Space : Bu kısımlar JVM için ayrılan yerin dışında yer kaplarlar ve mesela statik yüklenen class'lar burada tutulur.
Bu kısımların nasıl efektif kullanılacağı ile ilgili bilgileri
Tuning the Java Runtime System
tagtraum industries
A Collection of JVM options
linklerinde bulabilirsiniz.

Bu bilgilerin yanında kolonlara tıkladığınızda o kolonlarla ilgili bilgileri JConsole'u çalıştırdıktan sonra geçen zamana ait olarak görebilirsiniz. GC Time kısmında kaç kere Major GC (Yukarıdaki) yapıldığı ve ne kadar sürdüğü ve kaç kere Minor GC (Aşağıdaki) yapıldığı ve ne kadar sürdüğü görülebilir. GC'nin ne olduğu, nasıl izlendiği ile ilgili arkadaşım ve meslektaşım Mustafa Tan'ın Java Hafıza Problemleri ve GCViewer yazısı iyi bir kaynak olabilir.

Figure 3

Threads tabı bir diğer hayat kurtaran tabdır. Yani en azından bizim için öyle olmuştur. Figure 4'te gördüğünüz ekranlarda JVM içerisinde yer alan thread listesini ve bunun tomcat ile ilgili olan (yani web servlet aracılığı ile gelen) thread listesini görebilirsiniz. Aşağıdaki filter kısmına thread ile ilgili belirleyici bir kaç harf giriyorsunuz ve ta-tam, thread'leriniz listeleniyor. Bundan sonra yapmanız gereken sadece hangi threadin detayını görmek istiyorsanız ona tıklamak. Eh artık biraz da stack trace'den neler çıkarabileceğimize kalıyor iş.

Figure 4

MBean'ler ve invocation'ları ile ilgili bilgileri Figure 5'teki MBeans tabında bulabilirsiniz. Bu tab içerisinde soldaki navigasyonda erişebildiğiniz mbean'leri ve bu mbean'lerin metodlarını bulabilirsiniz. Eğer az çok JBoss'un JMX console'una aşina iseniz, bu ekran sizin için hayli güzel şeyler içerebilir. Ben örnek olarak Threading'i seçtim. e

Figure 5

Son tabımız ise Figure 6'da da gördüğünüz gibi VM tabı, biraz summary tabına benzesede burada bulacağınız bilgiler de gayet kullanışlı olacaktır. Bu bilgiler sırasıyla, JVM'in hangi Java versiyonu ile çalıştığı bilgisi, çalışan JVM'in process numarası (name kısmında @ işaretinden hemen önce), kullandığınız JVM argümanlarının tam bir listesi, çalışan JVM'in classpath'i boot classpath'i gibi faydalı bilgiler bazı diğer makine konfigürasyonu bilgileridir.

Figure 6

Bu yazıya ek olarak belirtmekte fayda göreceğim birkaç nokta var. JDK 6.0 ile birlikte gelen JConsole içerisinde JVM'in makine üzerinde yarattığı CPU yükünü takib edebiliyorsunuz. Yani yeni bir özellik olarak CPU izleyebilme eklenmiş. Summary tabı ile VM tabı birleştirilmiş. Bunun yerine ilk açtığınızda karşınıza Memory, Threads, CPU ve Classloading'den oluşan dörtlü basit bir monitor geliyor. Hmm bir de JDK 6.0 üzerindeki JConsole'a yazılmış birkaç tane eklenti gördüm. JDK 5.0'daki JConsole'da yoktu, ya da ben rastlamadım.

Bu kadar kolay ve rahat kullanılabilen bir aracın neler yapabildiğini anlatmaya çalıştım. Bu durumda şunu söyleyebilirim, ne şekilde olursa olsun, sistemleri gözlemlemek, hem sistemin doğasını anlamanıza yardımcı olur, hem de sistemi mevcut durumundan daha iyi bir düzeye getirmek için elinizde bulgular olmasını sağlar.

JConsole ile Performans Gözlem - Part 1

Performans Gözlemlemek sistemler için vazgeçilmez bir kavramdır. Bir sistemde oluşan sorunlar kadar, oluşabilecek sorunları önceden tahmin edebilmek de hayati bir aksiyondur. Sorun oluştuğu esnada sistemin parametrelerini gözlemleyebilmek ve sorunun sebebini bulmak hayat bile kurtarabilir.

İşte JConsole, eğer java tabanlı uygulamalar geliştiriyorsanız, işinize yarayacak güzel bir araç. En büyük özelliği JDK (5.0 ve sonrası) ile birlikte bedava geliyor olmasına rağmen boyundan büyük işler yapıyor olması. Geliştirdiğimiz projede yaklaşık 1 yıldır JConsole'dan faydalanıyoruz. Kullanımı çok basit, ama söylediğim gibi yaptıkları çok büyük.

Avantajları ve Dezavantajları

• En büyük avantajı, izlenilmek istenilen sistemler üzerine yük getirmiyor olması. Performans gözlem araçları, genellikle, izlenilmek istenen uygulamanın yanına bir agent kurarlar. Bu agent aracılığı ile merkezi bir server'a bilgi gönderirler. Ve izlenilen uygulamaya yük getirir.
• Bir diğer avantajı, kurulumunun ve hayata geçirilmesinin çok kolay olmasıdır.
• Bunun dışında belli bir süre gözlemledikten sonra (yaklaşık 7-8 saat) merkezi izlemenin yapıldığı sistemde (Genellikle PC olur bu) performans sıkıntısı yaratabilir.
• Verdiği bilgiler, çok detaylı bilgiler değildir. Yani memory ve cpu (JDK 6 ile birlikte) gözlemlenebilir, ama response time ve throughput değerleri gözlemlenemez (en azından eklentiler olmadan).
• JDK 6.0'dan sonra JConsole'a eklenti yazılabilme esnekliği getirilmiştir.

Bu avantaj ve dezavantajlar daha detaylandırılabilir.

JBoss üzerine nasıl JConsole'un yerleştirilebileceğini ve gözlemlediğimiz bilgilerin ne anlama geleceğini aşağıda anlatmaya çalışacağım.

Kurulumu ve Çalıştırılması

1. JVM argument'larının java satırına eklenmesi

Öncelikle, java ile çalıştırılan komuta bazı eklentiler yapmamız gerekiyor. Bunun için run.sh içerisinde JAVA_OPTS değişkenini bulup bunun sonuna

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

attribute'larını eklememiz gerekiyor. Bu attribute'lardan bizi ilgilendiren ve ileride kullanacağımız jmxremote.port, yani 9000.. Bu, merkezi açtığımız jconsole'un remote olarak bağlanacağı makinenin hangi porttan bilgileri vereceğini gösteriyor. Sonra tabi ki sunucuyu restart etmemiz gerekiyor. Açılırken herhangi birşey yüklemiyor. Bu konuda kafanız rahat olsun, sadece verdiğimiz porttan JConsole isteklerini dinleyip, bunlara response verecek.

2. Local'den JConsole'un çalıştırılıp remote sunucuya bağlanması

${JDK5_HOME}/bin altında jconsole.exe var. Bunu çalıştırıyoruz ve bitti, evet bu kadar. Ne kurulum yaptık, ne de konfigürasyon ayarladık. Dediğim kadar basitmiş değil mi? Karşımıza aşağıdaki Figure 1'deki ekran geliyor. Host or IP kısmına incelemek istediğimiz IP'yi, port kısmına jmxremote.port attribute'unda verdiğimiz port numarasını yazıyoruz...

Figure 1

Login işlemi sona erdiğinde önünüze gelen Figure 2'deki ekranda JVM ile ilgili genel bilgileri görebilirsiniz. Bu ekranda en çok kullandıklarımı ve zaman zaman sorun çıktığında başvurduğum bilgileri aşağıda kısaca açıklamaya çalışacağım.

Uptime = Server'ın ne kadar süredir çalıştığını gösterir. Bunu availability ile ilgili birilerine birşeyler kanıtlamam gerektiğinde kullanırım. Mesela bu ekranda server'ın yaklaşık 6 gündür ayakta olduğu görünüyor.
LiveThreads = JVM içerisindeki aktif thread sayısını görürsünüz. Bu sayı sistemin çalışması esnasında belli bir sayı aralığında dolaşır. mesela 60-90 arasında. Ama bunun üzerine çıkmaya başlarsa sistemde bir sorun başgösteriyor olabilir.
Memory ve classes için ayrı bir tab mevcut dolayısıyla bundan sonra bahsedeceğim, fakat JVM instance'ının üzerinde çalıştığı makinenin fiziksel memory'si ile ilgili birkaç bilgiyi Operating System kısmında bulabilirsiniz.

Figure 2

Bir sonraki yazımda JConsole ile memory grafiklerinin takibi, JVM thread'lerinin incelenmesi, Remote MBean Invocation ve JVM ile ilgili diğer bilgilere nasıl ulaşacağımızı, bunların yanında bunların nasıl kullanılırsa hayat kurtarabileceğini anlatmaya çalışacağım.

Performans Gözlemin Önemi

Çalışan uygulamaların ve uygulama sunucularının sürekli gözlemlenmesi gerekir. Sorunun ne zaman ve nereden geleceğini bilemeyiz, eğer biliyorsak sorun bizdedir, bu durumda "tembel ne duruyorsun? madem sorunu biliyorsun, çözsene!!!" derler, demezler mi?!?

J2EE uygulamalarının üzerinde çalıştıkları Uygulama Sunucuları, birçok özellikleri ile bu tür dikizlenmeye (monitor edilebilmenin argosu) müsaittirler. Birçok uygulama sunucusu kendi üzerinde MBean'lere sahiptir ve bu MBean'lerin remote çağrılması ile kendilerine ait bazı bilgileri çağırana iletir. Etrafımızda Uygulama Sunucusu izleme için birçok araç vardır. JConsole, JBoss ON, Tivoli ITCam, Hyperic, Applications Manager, JProfiler gibi. Bunların hepsini bilmenize veya kullanmanıza imkan yok. Ama hepsi ile ilgili kısa birer açıklama faydalı olacaktır.

JBoss ON - Uzunca hali JBoss Operation Network, adından belli JBoss için yapılmış olan bu uygulama JBoss'un CPU bazında lisans ücreti talep ettiği bir uygulama. Sadece performans monitoring değil, aynı zamanda uygulama sunucusu yönetimi de sağlıyor. Hepsi bir arada, fiyatı 30 CPU ve fazlası için yanlış hatırlamıyorsam 80,000 € civarındaydı.

JProfiler - İşte JVM'in process'ine yapışıp, hayatını sömüren uygulamalardan birisi. Sistemde acaip bir yük yaratıyor. Çok kullanışlı bulmadım. En son 5.0 versiyonunda birçok düzeltme olduğunu duydum.

Hyperic - Durum biraz daha kaliteli hale geliyor. Linux'te kendi kullanıcısını yaratıyor, Database'de şema istiyor. Ama hala yeterli değil.

Applications Manager - Kurulumu ve kullanımı çok kolay, 5 sistemi ücretsiz monitor edebiliyorsunuz, ama fazlası için para ödemeniz gerekiyor. Local'inize kuruyorsunuz, servisi başlatıyorsunuz, istediğiniz sistemi monitor edebiliyorsunuz (JBoss, Tomcat, Oracle ve hatta Linux)

JConsole - Yaklaşık 1 senedir kullanıyorum, neredeyse tüm sorunlarımı çözebiliyorum, memory leak'leri, bu leak'lere yol açan thread'leri bulabiliyorsunuz, JDK ile birlikte geliyor, sisteme yük getirmiyor. JConsole ile ilgili detaylı bir guideline ve gerçek hayat uygulamasını avantajlarını ve dezavantajlarını daha sonraki yazılarımda yazacağım.

Tivoli ITCam - Bu da IBM'in WAS'ları dikizlemek, ve üzerlerinde tam hakimiyet kurup sorunları tespit etmek için kullandığı bir ürün. 2004'te IBM ailesine katılmış. Tivoli başlı başına bir gözlem canavarı, ama bizi sadece ITCam ilgilendiriyor. Bunun kurulumunu yaptık, bununla ilgili de gözlemlerimi ilerleyen yazılarımda paylaşacağım.

Farkındaysanız, çalışan uygulamaların ve uygulama sunucularını gözlemlemek ne kadar önemli, ne kadar hassas yapılması gereken ve ne kadar sorun çözen bir işlem. Tabi memory, CPU gözlemlemek, hani derler ya "Ağaç yaşken eğilir", o hesapta taa Development'tan başlatılabiliyor. Bunun için de çeşitli IDE plugin'leri mevcut. Yukarıda listesini verdiğim gözlem araçlarının dışında tonla gözlem aracı mevcut, ben sadece deneyim yaşadıklarımı veya en azından duyduklarımı yazıyorum.

Websphere, Weblogic, JBoss - Part 1

Altyapı değişikliği yapmak, hem de uzun bir süreden sonra, hem de çok kapsamlı. Acaip riskli bir iş, riskli olduğu kadar zevkli de. Neden zevkli, çünkü her zaman göremeyeceğin şeyleri görme fırsatın oluyor. Ve yeni şeyler öğreniyorsun. Neyse bizim şirkette de bu tür bir çalışma yapılıyor..

Altyapı değişikliği yapmamızın sebeplerinin başında mevcut sistemin yetersizliklileri ve düşünülen ideal yapının getireceği avantajlar var. Bu seride sırasıyla mevcut sistemin dezavantajları, düşünülen sistemin avantajları, ve bu sistemlerle ilgili karşılaştırma yorumlarımı yazacağım.

Kısaca Mevcut yapı : JBoss ve Weblogic ortak kullanılıyor. Ürün ortamında yaklaşık 12 tane JBoss instance'ı ve 7 tane Weblogic instance'ı var. JBoss instance'larının her biri yaklaşık 3 GB, Weblogic'ler ise 2 GB JVM ile çalışıyorlar.

Support and Documentation

Yetersizliklerin en başında JBoss'un open source olmasından dolayı, sorunla karşılaştığımızda buna müdahele ederken kaynak ve destek konusunda çektiğimiz sıkıntılar geliyor. Bunu da şu şekilde anlatayım.

Şanslıysam, daha önce birisi daha JBoss'ta aynı problemle karşılaşmıştır.
Daha şanlıysam, bu problemini internette forumlarda paylaşmıştır.
Daha daha şanslıysam, bu problemi çözmüştür.
Hepten şanslıysam, çözümü internette biryerlere yazmıştır.

Yani nasıl bir şansa ihtiyacım olduğunu siz düşünün. Bu durum bana hatırı sayılır bir deneyim kazandırdı, bunu inkar edemem. Ama bunun yanında eğer bir sistem 7/24 çalışmak zorunda ise ve size kalan mini minnacık kısıtlı zamanda bu tür bir araştırma yapmanız gerekirse, sanırım yeterince terlersiniz. Projemiz henüz bu aşamada değil, ama çok yakın bir zamanda 7/24 çalışması gereken bir sistem haline gelecek. Bu da sorunlara müdahele şeklimizi değiştirmemizi gerektirecek.


Scalability

Ölçeklenebilirlik, aslında bizlere mühendislik eğitiminde neredeyse sürekli anlatılan bir kavramdır. Ama nedense iş pratiğe geldiğinde günü kurtarma adına verilen kararlar, hem ölçeklenemeyebilirlik yaratmakta, hem de ileride çözümü çok çok zor olan sorunlara yol açmaktadır. Ölçeklema kavramında işin büyük kısmı tasarım ve geliştirmeye düşse de, uygulama sunucusunun da ölçek büyüdükçe buna dayanabilmesi gerekmektedir. Ve hatta daha iyi performans gösterebilmesi gerekmektedir.

Her ne kadar sorunlarla karşılaştığımızda sistemlerimizi dikey veya yatay olarak büyütsek de, buna ihtiyacımızı en aza indirebilmek uygulama sunucusunun görevlerinden biridir. Yaa düşünsenize gerçek hayatta ayakkabı alırken dahi, "bir numara büyüğünü al, gelecek sene de giyersin" diyen bizler, her zaman proje geliştirirken proje büyüklüğünün bu şekilde kalacağını düşünürüz. Ne ironi ama.


Performance Monitoring

Yaşadığımız sıkıntılar içerisinde ilk sıraları zorlayan ve zaman zaman birinciliği alan sorunlardan bir tanesi de, sistem üzerinde performans gözlemleme işlemini layığıyla yapamamızdı. Aşağıda bu sistemde kullandığımız 3rd party tool'ları sıralayayım.

JProfiler - Ürün ortamında kullanmak neredeyse imkansız, sisteme getirdiği yük hayli fazla, dolayısıyla kullanmak istiyorsan, Alfa veya Beta ortamlarında kullanabilirsin ki onu da denedim, o bile işkence idi.

GC.log - JVM içerisine birkaç parametre yazdığınızda sistem Garbage Collection ile ilgili tüm dataları bir dosyaya yazıyor, ve server'ın yaşam süresi boyunca bu dosyayı güncelliyor. Aman dikkat dosyayı yanlışlıkla silerseniz yeniden yaratmıyor. Taa ki sunucu restart olana kadar. Bundan sonrası ile ilgili iyi bir Konfigürasyon Yöneticisi arkadaşımın yazılarında detaylı bilgi var java hafıza problemleri ve GCViewer

JConsole - Neredeyse aralarında favorim budur. Ne ortamlara yük getiriyor, ne de bir sürü ayar yapmanız gerekiyor. Sadece JVM'e birkaç parametre yazıyorsunuz, bitti. Ama bu bile sistemde sadece memory'yi takip etmemize, mevcut thread'leri izlememize yarıyor, ve bundan öteye gidemiyordu.

TomcatListener - Bunu da ben yazdım. Aurora ve JBoss kullanıyorsanız, gayet kullanışlı...

Bu listeden sonra bile, yine de sistemde bir sıkıntı olduğunda bu sıkıntıyı bulmak, bulamadığımız durumlarda geçici çözüm üretmek yeterince zor oluyor. Bu durumda son çare olarak uygulama sunucusunu restart ediyoruz. Yine aynı noktaya geliyoruz, sistem çok yoğun çalışmadığı durumlarda bunu yapabiliyoruz, ama yarın sistem 7/24 çalıştığı zaman bizden hesap sormazlar mı?