64 bit işletim sisteminde 32 bit JVM'nin maksimum Java yığın boyutu

Soru, 32 bit işletim sistemlerinde maksimum 4 GB adreslenebilir bellek boyutuna sahip olduğu ve JVM'nin maksimum yığın boyutunun ne kadar bitişik boş belleğin ayrılabileceğine bağlı olduğu göz önüne alındığında, 32 bit işletim sistemindeki maksimum yığın boyutu ile ilgili değildir.

64-bit işletim sisteminde çalışan 32-bit JVM için maksimum (hem teorik hem de pratik olarak ulaşılabilir) yığın boyutunu bilmekle daha çok ilgileniyorum. Temel olarak, SO ile ilgili bir sorudaki rakamlara benzer cevaplara bakıyorum .

64 bit yerine 32 bit JVM'nin neden kullanıldığına gelince, bunun nedeni teknik değil idari / bürokratiktir - üretim ortamına 64 bit JVM kurmak için muhtemelen çok geçtir.

Tek bir büyük bellek yığınına sahip olmayı ve ham işaretçileri kullanmayı bekleyen 32-bit JVM'ler 4 Gb'den fazlasını kullanamazlar (çünkü bu, işaretçiler için de geçerli olan 32 bitlik sınırdır). Buna Sun ve - oldukça eminim - IBM uygulamaları da dahildir. Örneğin JRockit veya diğerlerinin 32-bit uygulamaları ile geniş bir bellek seçeneğine sahip olup olmadığını bilmiyorum.

Bu sınıra ulaşmayı bekliyorsanız, üretim ortamınız için 64 bitlik bir JVM'yi doğrulayan bir paralel iz başlatmayı kesinlikle düşünmelisiniz, böylece 32 bit ortam bozulduğunda bunu hazır hale getirebilirsiniz. Aksi takdirde, bu işi baskı altında yapmanız gerekecek ki bu asla hoş bir şey değil.

2014-05-15'i Düzenle: Oracle SSS:

32 bit JVM için maksimum teorik yığın sınırı 4G'dir. Mevcut takas, çekirdek adres alanı kullanımı, bellek parçalanması ve VM ek yükü gibi çeşitli ek kısıtlamalar nedeniyle, pratikte sınır çok daha düşük olabilir. Çoğu modern 32 bit Windows sisteminde maksimum yığın boyutu 1,4G ile 1,6 G arasında değişecektir. 32 bit Solaris çekirdeklerinde adres alanı 2G ile sınırlıdır. 32 bit VM çalıştıran 64 bit işletim sistemlerinde, maksimum yığın boyutu daha yüksek olabilir ve birçok Solaris sisteminde 4G'ye yaklaşır.

( http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit )

Java Runtime'a sorabilirsiniz:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

Bu, varsayılan yığın tahsisine göre "Maksimum Bellek" raporlayacaktır. Yani yine de -Xmx( HotSpot'ta ) oynamanız gerekecek . Windows 7 Enterprise 64 bit, 32 bit'im üzerinde çalıştığını buldum HotSpot JVM'min 1577MiB'ye kadar ayırabildiğini buldum:

[C: çizik]> java -Xmx1600M MaxMemory
VM'nin başlatılması sırasında hata oluştu
Nesne yığını için yeterli alan ayıramadı
Java sanal makinesi oluşturulamadı.
[C: çizik]> java -Xmx1590M MaxMemory
Toplam Bellek: 2031616 (1,9375 MiB)
Maksimum Bellek: 1654456320 (1577,8125 MiB)
Boş Bellek: 1840872 (1.75559234619 MiB)
[C: çizik]>

Bir ile Halbuki 64 bit aynı OS üzerinde JVM, elbette bu kadar çok daha yüksek (3TiB hakkında)

[C: çizik]> java -Xmx3560G MaxMemory
VM'nin başlatılması sırasında hata oluştu
Nesne yığını için yeterli alan ayıramadı
[C: çizik]> java -Xmx3550G MaxMemory
Toplam Bellek: 94240768 (89,875 MiB)
Maksimum Bellek: 3388252028928 (3184151.84297 MiB)
Boş Bellek: 93747752 (89.4048233032 MiB)
[C: çizik]>

Diğerlerinin daha önce de bahsettiği gibi, işletim sistemine bağlıdır.

• 32 bit Windows için: <2GB olacaktır ( Windows dahili kitabı , kullanıcı işlemleri için 2GB diyor)
• 32 bit BSD / Linux için: <3GB (Devil Book'tan)
• 32 bit MacOS X için: <4 GB ( Mac OS X dahili kitaptan)
• 32 bit Solaris'ten emin değilsiniz, yukarıdaki kodu deneyin ve bize bildirin.

64 bitlik bir ana bilgisayar işletim sistemi için, JVM 32 bit ise, büyük olasılıkla yukarıda gösterildiği gibi yine de bağlı olacaktır.

- GÜNCELLEME 20110905 : Diğer bazı gözlemlere / ayrıntılara dikkat çekmek istedim:

• Bunu çalıştırdığım donanım, 6GB gerçek RAM yüklü 64-bit'ti. İşletim sistemi Windows 7 Enterprise, 64-bit idi
• Runtime.MaxMemoryTahsis edilebilecek gerçek miktar , işletim sisteminin çalışma kümesine de bağlıdır . Bunu bir keresinde VirtualBox çalışırken çalıştırdım ve HotSpot JVM'yi başarılı bir şekilde başlatamadığımı-Xmx1590M ve küçülmek zorunda olduğumu fark ettim . Bu aynı zamanda o zamanki çalışma setinizin boyutuna bağlı olarak 1590 milyondan fazla alabileceğiniz anlamına da gelir (yine de Windows tasarımı nedeniyle 32 bit için 2GiB altında olacağını düşünüyorum)

Hangi işletim sistemini belirtmezsiniz .

Windows altında (benim uygulamam için - uzun süredir devam eden bir risk yönetimi uygulaması), Windows 32bit'te 1280MB'den daha ileri gidemeyeceğimizi gözlemledik. 64bit altında 32bit JVM çalıştırmanın herhangi bir fark yaratacağından şüpheliyim.

Uygulamayı Linux'a taşıdık ve 64bit donanımda 32bit JVM çalıştırıyoruz ve oldukça kolay çalışan bir 2.2GB VM'ye sahibiz.

Sahip olabileceğiniz en büyük sorun, belleği ne için kullandığınıza bağlı olarak GC'dir.

Gönderen 4.1.2 Öbek Boyutlandırma :

"32 bitlik bir işlem modeli için, işlemin maksimum sanal adres boyutu genellikle 4 GB'dir, ancak bazı işletim sistemleri bunu 2 GB veya 3 GB ile sınırlar. Maksimum yığın boyutu genellikle 2 GB sınırlar için -Xmx3800m'dir (1600m) ), ancak gerçek sınırlama uygulamaya bağlıdır. 64-bit işlem modelleri için, maksimum esas olarak sınırsızdır. "

Burada oldukça iyi bir cevap buldum: Windows XP'de Java maksimum belleği .

Yakın zamanda bununla ilgili bazı deneyimlerimiz oldu. Yakın zamanda Solaris'ten (x86-64 Sürüm 5.10) Linux'a (RedHat x86-64) geçiş yaptık ve Linux'ta 32 bit JVM işlemi için Solaris'e göre daha az belleğe sahip olduğumuzu fark ettik.

Solaris için bu neredeyse 4 GB'a denk geliyor (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Uygulamamızı son birkaç yıldır Solaris üzerinde -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m ile çalıştırdık. Linux'a taşımayı denedim ve başlangıçta rastgele yetersiz bellek hatalarıyla ilgili sorunlar yaşadık. Sadece -Xms2300 -Xmx2300'de tutarlı bir şekilde başlatılmasını sağlayabildik . Daha sonra destekle bize bu konuda bilgi verildi.

Linux'ta 32 bitlik bir işlemin maksimum adreslenebilir adres alanı 3gb (3072mb) iken Solaris'te tam 4gb'dir (4096mb).

64-bit işletim sistemindeki 32-bit JVM'nin sınırlamaları, 32-bit işletim sistemindeki 32-bit JVM'nin sınırlamaları ile tamamen aynı olacaktır. Sonuçta, 32 bit JVM, 32 bitlik bir sanal makinede (sanallaştırma anlamında) çalışacak ve böylece 64 bit işletim sistemi / makinede çalıştığını bilemeyecektir.

32 bitlik bir işletim sistemi yerine 32 bitlik bir işletim sistemi üzerinde 32 bitlik bir JVM çalıştırmanın bir avantajı, daha fazla fiziksel belleğe sahip olmanız ve bu nedenle değiştirme / sayfalama işlemiyle daha az karşılaşmanızdır. Ancak bu avantaj, ancak birden fazla işleminiz olduğunda gerçekten tam olarak fark edilir.

64 bit yerine neden 32 bit JVM kullanıldığına gelince, bunun nedeni teknik değil, idari / bürokratik ...

BEA için çalışırken, ortalama uygulamanın aslında daha yavaş çalıştığını gördük 64 bitlik bir JVM'de çalıştığını, ardından 32 bitlik bir JVM'de çalışırken çalıştığını . Bazı durumlarda, performans isabeti% 25 daha yavaştı. Dolayısıyla, uygulamanız gerçekten tüm bu ekstra belleğe ihtiyaç duymadıkça, daha fazla 32 bit sunucu kurmanız daha iyi olur.

Hatırladığım kadarıyla, BEA profesyonel servis personelinin karşılaştığı 64 bit kullanmak için en yaygın üç teknik gerekçe şunlardı:

1. Uygulama birden çok büyük resmi işliyordu,
2. Uygulama muazzam sayıda hesaplama yapıyordu,
3. Uygulamada bir bellek sızıntısı vardı, müşteri bir hükümet sözleşmesinin ana sözleşmesiydi ve bellek sızıntısını takip etmek için zaman ve masraf yapmak istemiyorlardı. (Büyük bir bellek yığını kullanmak MTBF'yi artıracak ve ana para yine de ödenecektir)

.

Şu anda Oracle'ın sahip olduğu JROCKIT JVM, bitişik olmayan yığın kullanımını destekleyerek, 32 bit JVM'nin, JVM 64 bit Windows işletim sisteminde çalışırken 3,8 GB'den fazla belleğe erişmesine izin verir. (32 bit işletim sisteminde çalışırken 2,8 GB).

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

JVM, şu adresten ücretsiz olarak indirilebilir (kayıt gereklidir)

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

Solaris ve Linux 64-bit altında bazı testler

Solaris 10 - SPARC - T5220 makine, 32 GB RAM (ve yaklaşık 9 GB boş)

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

BTW: Görünüşe göre Java başlangıçta çok fazla gerçek bellek ayırmıyor. Başlayan örnek başına yalnızca 100 MB alıyor gibiydi (10'a başladım)

Solaris 10 - x86 - 8 GB RAM'li VMWare VM (yaklaşık 3 GB boş *)

3 GB boş RAM gerçekten doğru değil. ZFS önbelleklerinin kullandığı büyük bir RAM yığını var, ancak tam olarak ne kadarını kontrol etmek için kök erişimim yok

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

RedHat 5.5 - x86 - 4 GB RAM'li VMWare VM (yaklaşık 3,8 GB kullanıldı - arabelleklerde 200 MB ve önbelleklerde 3,1 GB, yani yaklaşık 3 GB boş)

$ alias java='$HOME/jre/jre1.6.0_34/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)

$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

JRE 7 kullanan aynı makine

$ alias java='$HOME/jre/jre1.7.0_21/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB

Çok daha iyi olmalı

64 bitlik bir ana bilgisayarda çalışan 32 bitlik bir JVM için, JVM'den sonra mevcut olan parçalanmamış sanal alan, kendi DLL'leri ve OS 32 bit uyumluluk öğeleri yüklendikten sonra yığın için geriye kalanın kalacağını hayal ediyorum. Çılgın bir tahmin olarak 3GB'nin mümkün olması gerektiğini düşünüyorum, ancak bunun ne kadar iyi olduğu, 32 bitlik ana bilgisayar alanında ne kadar iyi yaptığınıza bağlı.

Ayrıca, dev bir 3GB yığın yapabilseniz bile, bunu yapmak istemeyebilirsiniz çünkü bu, GC duraklamalarının potansiyel olarak sorun yaratmasına neden olur. Bazı insanlar ekstra belleği kullanmak için dev bir bellek yerine daha fazla JVM çalıştırır. Şu anda JVM'leri dev yığınlarla daha iyi çalışacak şekilde ayarladıklarını hayal ediyorum.

Tam olarak ne kadar iyi yapabileceğinizi bilmek biraz zor. Sanırım 32 bitlik durumunuz deneylerle kolayca belirlenebilir. Özellikle 32 bitlik ana bilgisayarlarda bulunan sanal alan oldukça kısıtlı olduğu için, birçok şey etkeni olduğu için soyut olarak tahmin etmek kesinlikle zordur. Yığın bitişik sanal bellekte var olması gerekir, bu nedenle dll'ler ve işletim sistemi çekirdeği tarafından adres alanının dahili kullanımı, olası tahsislerin aralığını belirleyecektir.

İşletim sistemi, HW cihazlarını ve kendi dinamik ayırmalarını eşlemek için bazı adres alanını kullanacaktır. Bu bellek java işlem adres alanına eşlenmezken, işletim sistemi çekirdeği ona ve adres alanınıza aynı anda erişemez, bu nedenle herhangi bir programın sanal alanının boyutunu sınırlar.

DLL'lerin yüklenmesi, JVM'nin uygulanmasına ve yayımlanmasına bağlıdır. İşletim sistemi çekirdeğinin yüklenmesi, çok sayıda şeye, sürüme, HW'ye, son yeniden başlatmadan bu yana şu ana kadar kaç şeyi eşleştirdiğine, kim bilir ...

Özetle

Bahse girerim 32 bitlik alanda 1-2 GB ve 64 bitlik alanda yaklaşık 3 GB elde edersiniz, yani genel olarak yaklaşık 2x'lik bir gelişme .

Solaris'te limit, Solaris 2.5'ten bu yana yaklaşık 3,5 GB olmuştur. (yaklaşık 10 yıl önce)

App Inventor for Android Blocks Editor'ün kullandığı JVM ile aynı sorunları yaşıyordum. Yığını maks. 925m'ye ayarlar. Bu yeterli değil, ancak makinemdeki çeşitli rastgele faktörlere bağlı olarak yaklaşık 1200 m'den fazla ayarlayamadım.

Firefox'un beta 64 bit tarayıcısı Nightly'yi ve ayrıca JAVA 7 64 bit sürümünü indirdim.

Henüz yeni yığın sınırımı bulamadım, ancak 5900m yığın boyutuna sahip bir JVM açtım . Sorun değil!

24gb RAM'li bir makinede Win 7 64 bit Ultimate çalıştırıyorum.

32bit Linux makinesinde yığın boyutunu 2200M'ye ayarlamayı denedim ve JVM iyi çalıştı. JVM, 2300M olarak ayarladığımda başlamadı.

Bu ağır bir ayar, ancak 3 gb'lık bir yığın elde edebilirsiniz.

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

sıcak nokta 32-bit JVM için burada bir nokta daha var: - yerel yığın kapasitesi = 4 Gig - Java Yığını - PermGen;

Java Yığını ve yerel Yığın bir yarışta olduğundan, 32 bit JVM için özellikle zor olabilir. Java Heap'iniz ne kadar büyükse, yerel Heap o kadar küçük olur. 32 bitlik bir VM için büyük bir Yığın kurmaya çalışmak, örneğin .2,5 GB +, uygulamanızın (uygulamalarınızın) ayak izine, İş parçacığı sayısına, vb. Bağlı olarak yerel OutOfMemoryError riskini artırır.

Sınırlama aynı zamanda bir 32 bitVM için, heaptüm bunları istiyorsanız , kendisinin adres sıfırdan başlamak zorunda olmasından kaynaklanmaktadır.4GB .

Bir şeye şu yolla atıfta bulunmak istiyorsanız, düşünün:

0000....0001

yani: bu belirli bit temsiline sahip bir referans, bu, yığından ilk belleğe erişmeye çalıştığınız anlamına gelir. Bunun mümkün olması için, yığının sıfır adresinden başlaması gerekir. Ancak bu asla olmaz, sıfırdan bir farkla başlar:

    | ....               .... {heap_start .... heap_end} ... |
 --> (this can't be referenced) <--

Yığın hiçbir zaman bir sıfır adresinden başlamadığından, OSbir 32bit referansından asla kullanılmayan epeyce bit vardır ve bu nedenle başvurulabilen yığın daha düşüktür.

Teorik 4 gb, ancak pratikte (IBM JVM için):

Win 2k8 64, IBM Websphere Uygulama Sunucusu 8.5.5 32bit

C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/ CWSDK1001I: Задача managesdk выполнена успешно. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи ровать Could not create the Java virtual machine. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 2146435072 (2047.0 MiB) Free Memory: 3064536 (2.9225692749023438 MiB) C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк земпляр кучи; запрошено 2G Could not create the Java virtual machine.

RHEL 6.4 64, IBM Websphere Application Server 8.5.5 32bit

[bin]./java -Xmx3791M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3975151616 (3791.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [root@nagios1p bin]# ./java -Xmx3793M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3977248768 (3793.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose CWSDK1003I: Available SDKs : CWSDK1005I: SDK name: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=linux - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/ CWSDK1001I: Successfully performed the requested managesdk task.