Java sanal makinelerinin ayarlanması

IBM eXtremeBellek

eXtremeBelleğini yapılandırarak, nesneleri Java öbeği yerine yerel bellekte saklayabilirsiniz. eXtremeBelleğin yapılandırılması, yeni bir iletim mekanizması olan eXtremeGÇ ' yi etkinleştirir. Nesneleri Java öbeğinden taşıyarak, atık toplama duraklamalarını önleyerek daha sabit başarım için ıten eder da eder! Daha fazla bilgi için IBM eXtremeBelleğin Yapılandırılmasıbaşlıklı konuya bakın.

eXtremeBellek with gencon atık toplama işlevini kullanıyorsanız, atık toplama çocuk odası boyutunu yığın boyutunun %75 'ine ayarlamayı düşünün. -Xmn JVM bağımsız değişkeniyle çocuk odası boyutunu ayarlayabilirsiniz.

Test edilmiş platformlar

Performans testi öncelikle AIX® (32 yönlü), Linux® (dört yönlü) ve Windows (sekiz yönlü) bilgisayarlarda gerçekleşti. Üst uç AIX bilgisayarlarıyla, çekişme noktalarını tanımlamak ve düzeltmek için çok iş parçacıklı senaryoları test edebilirsiniz.

Anlamsız veri toplama

WebSphere eXtreme Scale , istek ve yanıt ve günlük sırası gibi her işlemle ilişkili geçici nesneler oluşturur. Bu nesneler çöp toplama verimliliğini etkilediği için, atık toplama işleminin ayarlanması kritik önem taşır.

Tüm modern JVM ' ler paralel çöp toplama algoritmaları kullanır, yani olarak ---gibi ben mi mi-daha fazla çekirdek kullanıyorum, bu da çöp toplama duraklamalarını azaltabilir. Sekiz çekirdekli bir fiziksel sunucu, dört çekirdekli bir fiziksel sunucudan daha hızlı çöp toplamaya sahiptir.

Uygulamanın her bölüm için büyük miktarda veriyi yönetmesi gerekiyorsa, atık toplama bir faktör olabilir. Bir okuma çoğunlukla, bir kuşak toplayıcı kullanılırsa büyük yığınlarla (20 GB veya daha fazla) bile çalışır. Ancak, süre dolduktan sonra, canlı yığın boyutuyla orantılı bir duraklama ve bilgisayardaki işlemci sayısı oluşur. Bu duraklama, büyük yığınlı küçük bilgisayarlarda büyük olabilir.

Java atık toplama için IBM sanal makinesi

IBM Virtual Machine for Java için, yüksek güncelleme hızı senaryoları için optavgpause veri toplayıcısını kullanın (hareketlerin %100 'ü girişleri değiştirir). gencon toplayıcısı, verilerin nispeten seyrek olarak (zamanın %10 'u ya da daha azı) güncellendiği senaryolar için optavgpause toplayıcısından çok daha iyi çalışır. Senaryonda neyin en iyi işe yaradığını görmek için her iki toplayıcıyı da deneyin. Atık toplama için harcanan sürenin yüzdesini denetlemek üzere ayrıntılı çöp toplama açık olarak çalıştırın. Ayarlama sorunu düzeltilinceye kadar, zamanının %80 'inin çöp toplama içinde harcandığı senaryolar ortaya çıktı.

• WebSphere Application Server yapılandırmasında, yönetim konsolunda -Xgcpolicy parametresini ayarlayın. Servers > Application servers > server_name > Process definition > Java Virtual Machine(Sunucular > Uygulama sunucuları > sunucu_adı > Süreç tanımlaması > Java Virtual Machine) öğelerini tıklatın. Soysal JVM bağımsız değişkenleri alanına parametreyi ekleyin.
• Bağımsız bir yapılandırmada, atık toplayıcıyı belirtmek için -jvmArgs parametresini sunucuyu başlatma komut dosyasına geçirin. -jvmArgs parametresi, komut dosyasına geçirilen son parametre olmalıdır.

Diğer atık toplama seçenekleri

WebSphere eXtreme Scale , WebSphere Real Time Java 'yı destekler. WebSphere Real Time Java ile WebSphere eXtreme Scale için işlem işleme yanıtı daha tutarlı ve öngörülebilir olur. Sonuç olarak, çöp toplama ve iş parçacığı zamanlamanın etkisi büyük ölçüde en aza indirilir. Etki, yanıt süresinin standart sapmasının normal Java 'nın %10 'undan daha az olduğu derecesine indirgenir.

Yığın boyutu

Örneğin, 10 K baytlık dizileri depolayan bir uygulama, POJO'lardan oluşan karmaşık grafikleri kullanan bir uygulamadan çok daha büyük bir yığın çalıştırabilir.

İş Parçacığı Sayısı

İş parçacığı sayısı birkaç etkene bağlıdır. Tek bir parçaın yönetebileceği iş parçacığı sayısı için bir sınır vardır. Parça, bir bölümün örneğidir ve birincil ya da kopya olabilir. Her JVM için daha fazla parça ile, her ek parçgünümektedir için var ya), İtidi mi için ya) ya) var bir ya!, iyi? ??? ne? Her bir parça, koşutzamanlılık için bir sınır olmasına rağmen mümkün olduğu kadar eşzamanlıdır.

Nesne İsteği Aracısı (ORB) gereksinimleri,:

Kullanımdan Kaldırıldı: Nesne İsteği Aracısı (ORB) kullanımdan kaldırıldı. ORB ' yi önceki bir yayında kullanmıyorsanız, aktarım mekanizmanız için IBM eXtremeIO (XIO) kullanın. ORB kullanıyorsanız, yapılandırmanızı XIO kullanacak şekilde geçirmeyi düşünün.

IBM SDK, WebSphere Application Server ve WebSphere eXtreme Scaleile test edilmiş bir IBM ORB uygulaması içerir. Destek sürecini kolaylaştırmak için IBMtarafından sağlanan JVM ' yi kullanın. Diğer JVM uygulamaları farklı bir ORB kullanıyor. IBM ORB yalnızca IBMtarafından sağlanan Java sanal makineleriyle birlikte sağlanır. WebSphere eXtreme Scale ürününün çalışması için bir ORB gerekir. WebSphere eXtreme Scale ürününü diğer satıcıların ORB ' larıyla kullanabilirsiniz. Ancak, bir satıcı firma ORB ile ilgili bir sorununuz varsa, destek için ORB satıcı firmasına başvurmanız gerekir. IBM ORB uygulaması, üçüncü partyJava sanal makineleriyle uyumludur ve gerekirse yerine konabilir.

orb.properties ayarlama

# IBM JDK properties for ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# WS Interceptors
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# WS ORB & Plugins properties
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Needed when lots of JVMs connect to the catalog at the same time
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Clients and the catalog server can have sockets open to all JVMs
com.ibm.CORBA.MaxOpenConnections=1016

# Thread Pool for handling incoming requests, 200 threads here
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# No splitting up large requests/responses in to smaller chunks
com.ibm.CORBA.FragmentSize=0