Kích thước đống Java tối đa của JVM 32 bit trên hệ điều hành 64 bit

Câu hỏi không phải là về kích thước heap tối đa trên hệ điều hành 32 bit, vì hệ điều hành 32 bit có kích thước bộ nhớ địa chỉ tối đa là 4GB và kích thước heap tối đa của JVM phụ thuộc vào lượng bộ nhớ trống liền kề có thể được dự trữ.

Tôi quan tâm hơn đến việc biết kích thước đống tối đa (cả lý thuyết và thực tế có thể đạt được) cho một JVM 32 bit chạy trong hệ điều hành 64 bit. Về cơ bản, tôi đang xem các câu trả lời tương tự như các số liệu trong một câu hỏi liên quan trên SO .

Về lý do tại sao JVM 32 bit được sử dụng thay vì 64 bit, lý do không phải là kỹ thuật mà là do hành chính / quan liêu - có lẽ đã quá muộn để cài đặt JVM 64 bit trong môi trường sản xuất.

Các JVM 32-bit mong muốn có một bộ nhớ lớn và sử dụng con trỏ thô không được sử dụng nhiều hơn 4 Gb (vì đó là giới hạn 32 bit cũng áp dụng cho con trỏ). Điều này bao gồm Sun và - tôi khá chắc chắn - cũng như các triển khai của IBM. Tôi không biết liệu JRockit hoặc những người khác có tùy chọn bộ nhớ lớn với các triển khai 32-bit của họ hay không.

Nếu bạn mong đợi đạt đến giới hạn này, bạn nên cân nhắc việc bắt đầu theo dõi song song xác thực JVM 64 bit cho môi trường sản xuất của bạn để bạn có thể sẵn sàng khi môi trường 32 bit bị hỏng. Nếu không, bạn sẽ phải làm công việc đó dưới áp lực, điều này không bao giờ tốt đẹp.

Chỉnh sửa 2014-05-15: Câu hỏi thường gặp về Oracle:

Giới hạn đống lý thuyết tối đa cho JVM 32-bit là 4G. Do các ràng buộc bổ sung khác nhau như hoán đổi có sẵn, sử dụng không gian địa chỉ hạt nhân, phân mảnh bộ nhớ và chi phí VM, trên thực tế, giới hạn có thể thấp hơn nhiều. Trên hầu hết các hệ thống Windows 32-bit hiện đại, kích thước heap tối đa sẽ nằm trong khoảng từ 1,4G đến 1,6G. Trên hạt nhân Solaris 32-bit, không gian địa chỉ được giới hạn ở 2G. Trên hệ điều hành 64-bit chạy VM 32-bit, kích thước heap tối đa có thể cao hơn, đạt tới mức 4G trên nhiều hệ thống Solaris.

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

Bạn có thể hỏi Java Runtime:

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)");
    }
}

Điều này sẽ báo cáo "Bộ nhớ tối đa" dựa trên phân bổ heap mặc định. Vì vậy, bạn vẫn cần chơi với -Xmx(trên HotSpot ). Tôi nhận thấy rằng đang chạy trên Windows 7 Enterprise 64-bit, HotSpot JVM 32-bit của tôi có thể phân bổ tối đa 1577MiB:

[C: xước]> java -Xmx1600M MaxMemory
Lỗi xảy ra trong quá trình khởi tạo máy ảo
Không thể dành đủ dung lượng cho đống đối tượng
Không thể tạo máy ảo Java.
[C: xước]> java -Xmx1590M MaxMemory
Tổng bộ nhớ: 2031616 (1,9375 MiB)
Bộ nhớ tối đa: 1654456320 (1577,8125 MiB)
Bộ nhớ trống: 1840872 (1.75559234619 MiB)
[C: xước]>

Trong khi với JVM 64-bit trên cùng một hệ điều hành, tất nhiên nó sẽ cao hơn nhiều (khoảng 3TiB)

[C: xước]> java -Xmx3560G MaxMemory
Lỗi xảy ra trong quá trình khởi tạo máy ảo
Không thể dành đủ dung lượng cho đống đối tượng
[C: xước]> java -Xmx3550G MaxMemory
Tổng bộ nhớ: 94240768 (89,875 MiB)
Bộ nhớ tối đa: 3388252028928 (3184151.84297 MiB)
Bộ nhớ trống: 93747752 (89.4048233032 MiB)
[C: xước]>

Như những người khác đã đề cập, nó phụ thuộc vào hệ điều hành.

• Đối với Windows 32-bit: nó sẽ là <2GB ( Sách nội bộ của Windows nói rằng 2GB cho các quy trình của người dùng)
• Đối với BSD / Linux 32-bit: <3GB (từ Sách Quỷ)
• Đối với MacOS X 32-bit: <4GB (từ sách nội bộ Mac OS X )
• Bạn không chắc chắn về Solaris 32-bit, hãy thử đoạn mã trên và cho chúng tôi biết.

Đối với hệ điều hành máy chủ 64-bit, nếu JVM là 32-bit, nó sẽ vẫn phụ thuộc, rất có thể giống như ở trên như đã trình bày.

- CẬP NHẬT 20110905 : Tôi chỉ muốn chỉ ra một số quan sát / chi tiết khác:

• Phần cứng mà tôi chạy phần cứng này là 64-bit với 6GB RAM thực được cài đặt. Hệ điều hành là Windows 7 Enterprise, 64-bit
• Số lượng thực tế Runtime.MaxMemorycó thể được phân bổ cũng phụ thuộc vào bộ làm việc của hệ điều hành . Tôi đã từng chạy điều này trong khi tôi cũng đang chạy VirtualBox và nhận thấy rằng tôi không thể khởi động thành công HotSpot JVM với -Xmx1590Mvà phải nhỏ hơn. Điều này cũng ngụ ý rằng bạn có thể nhận được hơn 1590M tùy thuộc vào kích thước tập hợp làm việc của bạn vào thời điểm đó (mặc dù tôi vẫn duy trì nó sẽ dưới 2GiB cho 32 bit do thiết kế của Windows)

Bạn không chỉ định mà hệ điều hành.

Trong Windows (đối với ứng dụng của tôi - một ứng dụng quản lý rủi ro đang hoạt động lâu dài), chúng tôi nhận thấy rằng chúng tôi không thể vượt quá 1280MB trên Windows 32bit. Tôi nghi ngờ rằng việc chạy JVM 32bit dưới 64bit sẽ tạo ra bất kỳ sự khác biệt nào.

Chúng tôi đã chuyển ứng dụng sang Linux và chúng tôi đang chạy JVM 32 bit trên phần cứng 64 bit và đã có một máy ảo 2,2GB chạy khá dễ dàng.

Vấn đề lớn nhất bạn có thể gặp phải là GC phụ thuộc vào những gì bạn đang sử dụng bộ nhớ.

Từ 4.1.2 Định cỡ đống :

"Đối với mô hình quy trình 32 bit, kích thước địa chỉ ảo tối đa của quy trình thường là 4 GB, mặc dù một số hệ điều hành giới hạn mức này là 2 GB hoặc 3 GB. Kích thước đống tối đa thường là -Xmx3800m (1600m) cho giới hạn 2 GB ), mặc dù giới hạn thực tế là phụ thuộc vào ứng dụng. Đối với các mô hình xử lý 64-bit, mức tối đa về cơ bản là không giới hạn. "

Tìm thấy một câu trả lời khá hay ở đây: Bộ nhớ tối đa của Java trên Windows XP .

Gần đây chúng tôi đã có một số kinh nghiệm về điều này. Gần đây, chúng tôi đã chuyển từ Solaris (x86-64 Phiên bản 5.10) sang Linux (RedHat x86-64) và nhận ra rằng chúng tôi có ít bộ nhớ hơn cho quy trình JVM 32 bit trên Linux so với Solaris.

Đối với Solaris, con số này gần như chỉ có 4GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Chúng tôi đã chạy ứng dụng của mình với -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m mà không gặp sự cố nào trên Solaris trong vài năm qua. Đã cố gắng chuyển nó sang linux và chúng tôi gặp sự cố với lỗi ngẫu nhiên hết bộ nhớ khi khởi động. Chúng tôi chỉ có thể giúp nó khởi động liên tục trên -Xms2300 -Xmx2300 . Sau đó, chúng tôi đã được hỗ trợ tư vấn về điều này.

Quy trình 32 bit trên Linux có không gian địa chỉ có thể định địa chỉ tối đa là 3gb (3072mb) trong khi trên Solaris là 4gb đầy đủ (4096mb).

Các hạn chế của JVM 32-bit trên HĐH 64-bit sẽ giống hệt như các hạn chế của JVM 32-bit trên HĐH 32-bit. Rốt cuộc, JVM 32-bit sẽ chạy trong máy ảo 32-bit (theo nghĩa ảo hóa) nên nó sẽ không biết rằng nó đang chạy trên hệ điều hành / máy 64-bit.

Một lợi thế khi chạy JVM 32-bit trên HĐH 64-bit so với HĐH 32-bit là bạn có thể có nhiều bộ nhớ vật lý hơn và do đó sẽ ít gặp phải việc hoán đổi / phân trang hơn. Tuy nhiên, lợi thế này chỉ thực sự được thực hiện đầy đủ khi bạn có nhiều quy trình.

Về lý do tại sao JVM 32 bit được sử dụng thay vì 64 bit, lý do không phải là kỹ thuật mà là hành chính / quan liêu ...

Khi tôi làm việc cho BEA, chúng tôi thấy rằng ứng dụng trung bình thực sự chạy chậm hơn trong JVM 64-bit, sau đó chạy trong JVM 32-bit. Trong một số trường hợp, hiệu suất đạt được cao hơn tới 25%. Vì vậy, trừ khi ứng dụng của bạn thực sự cần tất cả bộ nhớ bổ sung đó, bạn nên thiết lập nhiều máy chủ 32-bit hơn.

Như tôi nhớ lại, ba lý do kỹ thuật phổ biến nhất cho việc sử dụng 64-bit mà các nhân viên dịch vụ chuyên nghiệp của BEA gặp phải là:

1. Ứng dụng đang thao tác nhiều hình ảnh lớn,
2. Ứng dụng đang thực hiện một số lượng lớn,
3. Ứng dụng bị rò rỉ bộ nhớ, khách hàng là người đứng đầu trong hợp đồng với chính phủ, và họ không muốn mất thời gian và chi phí để theo dõi rò rỉ bộ nhớ. (Sử dụng một đống bộ nhớ lớn sẽ làm tăng MTBF và bản chính vẫn được trả tiền)

.

JROCKIT JVM hiện do Oracle sở hữu hỗ trợ sử dụng heap không liền kề, do đó cho phép JVM 32 bit truy cập nhiều hơn 3,8 GB bộ nhớ khi JVM đang chạy trên hệ điều hành windows 64 bit. (2,8 GB khi chạy trên hệ điều hành 32 bit).

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

JVM có thể được tải xuống miễn phí (yêu cầu đăng ký) tại

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

Đây là một số thử nghiệm trong Solaris và Linux 64-bit

Máy Solaris 10 - SPARC - T5220 có RAM 32 GB (còn khoảng 9 GB trống)

$ 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: Rõ ràng Java không cấp phát nhiều bộ nhớ thực khi khởi động. Dường như chỉ mất khoảng 100 MB cho mỗi phiên bản bắt đầu (tôi đã bắt đầu 10)

Solaris 10 - x86 - VMWare VM với RAM 8 GB (khoảng 3 GB trống *)

RAM 3 GB trống không thực sự đúng. Có một lượng lớn RAM mà bộ nhớ đệm ZFS sử dụng, nhưng tôi không có quyền truy cập root để kiểm tra chính xác dung lượng

$ 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 - VMWare VM với RAM 4 GB (khoảng 3,8 GB được sử dụng - 200 MB trong bộ đệm và 3,1 GB trong bộ nhớ đệm, vì vậy còn khoảng 3 GB trống)

$ 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

Cùng một máy sử dụng JRE 7

$ 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

Sẽ tốt hơn rất nhiều

Đối với JVM 32-bit chạy trên máy chủ lưu trữ 64-bit, tôi tưởng tượng những gì còn lại trên heap sẽ là bất kỳ không gian ảo không phân mảnh nào có sẵn sau JVM, đó là DLL của riêng nó và mọi thứ tương thích với hệ điều hành 32-bit đã được tải. Theo một dự đoán hoang dã, tôi sẽ nghĩ rằng 3GB là có thể, nhưng điều đó tốt hơn bao nhiêu tùy thuộc vào mức độ bạn đang làm ở 32-bit-host-land.

Ngoài ra, ngay cả khi bạn có thể tạo ra một đống 3GB khổng lồ, bạn có thể không muốn, vì điều này sẽ khiến việc tạm dừng GC trở nên có khả năng gây rắc rối. Một số người chỉ chạy thêm JVM để sử dụng thêm bộ nhớ thay vì một bộ nhớ khổng lồ. Tôi tưởng tượng họ đang điều chỉnh JVM ngay bây giờ để hoạt động tốt hơn với các đống khổng lồ.

Hơi khó để biết chính xác bạn có thể làm tốt hơn bao nhiêu. Tôi đoán tình huống 32-bit của bạn có thể dễ dàng xác định bằng thử nghiệm. Chắc chắn là khó có thể dự đoán một cách trừu tượng, vì có rất nhiều thứ ảnh hưởng đến nó, đặc biệt là vì không gian ảo có sẵn trên các máy chủ 32-bit khá hạn chế. dll và việc sử dụng bên trong không gian địa chỉ của nhân hệ điều hành sẽ xác định phạm vi phân bổ có thể.

Hệ điều hành sẽ sử dụng một số không gian địa chỉ để ánh xạ các thiết bị HW và phân bổ động của riêng nó. Mặc dù bộ nhớ này không được ánh xạ vào không gian địa chỉ quy trình java, nhưng nhân hệ điều hành không thể truy cập nó và không gian địa chỉ của bạn cùng một lúc, vì vậy nó sẽ giới hạn kích thước của không gian ảo của bất kỳ chương trình nào.

Việc tải DLL phụ thuộc vào việc triển khai và phát hành JVM. Việc tải nhân hệ điều hành phụ thuộc vào rất nhiều thứ, bản phát hành, HW, bao nhiêu thứ mà nó đã ánh xạ cho đến nay kể từ lần khởi động lại cuối cùng, ai biết được ...

Tóm tắt

Tôi cá là bạn nhận được 1-2 GB ở 32-bit-land và khoảng 3 GB ở 64-bit, vì vậy tổng thể cải thiện khoảng 2 lần .

Trên Solaris, giới hạn đã là khoảng 3,5 GB kể từ Solaris 2,5. (khoảng 10 năm trước)

Tôi đang gặp vấn đề tương tự với JVM mà App Inventor cho Android Blocks Editor sử dụng. Nó đặt đống ở tối đa 925m. Điều này là chưa đủ nhưng tôi không thể đặt nó quá 1200m, tùy thuộc vào các yếu tố ngẫu nhiên khác nhau trên máy của tôi.

Tôi đã tải xuống Nightly, trình duyệt 64 bit beta từ Firefox và cả phiên bản JAVA 7 64 bit.

Tôi chưa tìm thấy giới hạn heap mới của mình, nhưng tôi vừa mở JVM với kích thước heap là 5900m . Không vấn đề gì!

Tôi đang chạy Win 7 64 bit Ultimate trên máy có RAM 24gb.

Tôi đã thử đặt kích thước đống lên đến 2200M trên máy Linux 32bit và JVM hoạt động tốt. JVM không bắt đầu khi tôi đặt nó thành 2300M.

Đây là một thủ thuật nặng nề, nhưng bạn có thể nhận được một đống 3gb.

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

một điểm nữa ở đây cho điểm phát sóng JVM 32-bit: - dung lượng heap gốc = 4 Gig - Java Heap - PermGen;

Nó có thể trở nên đặc biệt phức tạp đối với JVM 32-bit vì Java Heap và Heap gốc đang trong một cuộc đua. Heap Java của bạn càng lớn thì Heap gốc càng nhỏ. Cố gắng thiết lập một Heap lớn cho một máy ảo 32 bit, ví dụ 2,5 GB + sẽ làm tăng nguy cơ xuất hiện OutOfMemoryError gốc tùy thuộc vào (các) ứng dụng của bạn, số lượng Luồng, v.v.

Hạn chế cũng đến từ thực tế là đối với một 32 bitmáy ảo, heapbản thân nó phải bắt đầu từ địa chỉ 0 nếu bạn muốn tất cả những điều đó 4GB.

Hãy nghĩ về nó, nếu bạn muốn tham khảo điều gì đó qua:

0000....0001

tức là: một tham chiếu có biểu diễn bit cụ thể này, nó có nghĩa là bạn đang cố gắng truy cập vào bộ nhớ đầu tiên từ heap. Để có thể thực hiện được điều đó, heap phải bắt đầu từ địa chỉ số không. Nhưng điều đó không bao giờ xảy ra, nó bắt đầu ở một số điểm bù từ 0:

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

Bởi vì heap không bao giờ bắt đầu từ địa chỉ 0 trong an OS, có khá nhiều bit không bao giờ được sử dụng từ 32tham chiếu bit, và như vậy, heap có thể được tham chiếu sẽ thấp hơn.

Về lý thuyết thì 4gb, nhưng trong thực tế (đối với IBM JVM):

Win 2k8 64, Máy chủ ứng dụng Websphere của IBM 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, Máy chủ ứng dụng Websphere của IBM 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.