it-swarm-id.com

Berurusan dengan kesalahan "Java.lang.OutOfMemoryError: PermGen space"

Baru-baru ini saya mengalami kesalahan ini dalam aplikasi web saya:

Java.lang.OutOfMemoryError: Ruang PermGen

Ini adalah aplikasi khas Hibernate/JPA + IceFaces/JSF yang berjalan pada Tomcat 6 dan JDK 1.6. Rupanya ini dapat terjadi setelah memindahkan aplikasi beberapa kali.

Apa yang menyebabkannya dan apa yang bisa dilakukan untuk menghindarinya? Bagaimana cara saya memperbaiki masalah?

1206
Chris

Solusinya adalah menambahkan flag-flag ini ke baris perintah JVM ketika Tomcat dimulai:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Anda dapat melakukannya dengan mematikan layanan Tomcat, lalu masuk ke direktori Tomcat/bin dan menjalankan Tomcat6w.exe. Di bawah tab "Java", tambahkan argumen ke kotak "Java Options". Klik "OK" dan kemudian restart layanan.

Jika Anda mendapatkan kesalahan layanan yang ditentukan tidak ada sebagai layanan yang diinstal Anda harus menjalankan:

Tomcat6w //ES//servicename

di manaservicenameadalah nama server seperti yang dilihat di services.msc

Sumber: komentar orx di Eric's Agile Answers .

560
Chris

Anda sebaiknya mencoba-XX:MaxPermSize=128Mdaripada -XX:MaxPermGen=128M.

Saya tidak bisa mengatakan dengan tepat penggunaan kumpulan memori ini, tetapi itu ada hubungannya dengan jumlah kelas yang dimuat ke dalam JVM. (Dengan demikian mengaktifkan pembongkaran kelas untuk Tomcat dapat menyelesaikan masalah.) Jika aplikasi Anda menghasilkan dan mengkompilasi kelas yang sedang berjalan, kemungkinan besar membutuhkan kolam memori yang lebih besar daripada standar.

250
toesterdahl

Kesalahan umum yang dilakukan orang adalah berpikir bahwa tumpukan ruang dan ruang permgen adalah sama, yang sama sekali tidak benar. Anda bisa memiliki banyak ruang yang tersisa di tumpukan tetapi masih bisa kehabisan memori di permgen.

Penyebab umum OutofMemory di PermGen adalah ClassLoader. Setiap kali kelas dimuat ke JVM, semua meta datanya, bersama dengan Classloader, disimpan di area PermGen dan mereka akan menjadi sampah yang dikumpulkan ketika Classloader yang memuatnya siap untuk pengumpulan sampah. Dalam Kasus Classloader memiliki kebocoran kehabisan memori daripada semua kelas yang dimuat olehnya akan tetap ada dalam memori dan menyebabkan memori keluar setelah Anda mengulanginya beberapa kali. Contoh klasiknya adalah Java.lang.OutOfMemoryError: PermGen Space di Tomcat .

Sekarang ada dua cara untuk menyelesaikan ini:
1. Temukan penyebab Memory Leak atau jika ada kebocoran memori.
2. Meningkatkan ukuran Ruang PermGen dengan menggunakan JVM param -XX:MaxPermSize dan -XX:PermSize.

Anda juga dapat memeriksa 2 Solution Java.lang.OutOfMemoryError di Java untuk detail lebih lanjut.

67
Peter

Gunakan parameter baris perintah -XX:MaxPermSize=128m untuk Sun JVM (jelas-jelas mengganti 128 untuk ukuran apa pun yang Anda butuhkan).

40
user17163

Coba -XX:MaxPermSize=256m dan jika terus, coba -XX:MaxPermSize=512m

36
bassist

Saya menambahkan-XX: MaxPermSize = 128m (Anda dapat melakukan percobaan yang paling berhasil) ke VM Argumen karena saya menggunakan ide Eclipse. Di sebagian besar JVM, default PermSize sekitar 64MB yang kehabisan memori jika ada terlalu banyak kelas atau sejumlah besar String dalam proyek.

Untuk Eclipse, ini juga dijelaskan di answer .

LANGKAH 1: Klik dua kali pada server Tomcat di Tab Server

enter image description here

LANGKAH 2: Buka luncurkan Conf dan tambahkan -XX: MaxPermSize = 128m ke akhir yang sudah ada VM argumen.

enter image description here

26
prayagupd

Saya telah membenturkan kepala saya ke masalah ini ketika menggunakan dan tidak menggunakan aplikasi web yang rumit juga, dan berpikir saya akan menambahkan penjelasan dan solusi saya.

Ketika saya menyebarkan aplikasi di Apache Tomcat, ClassLoader baru dibuat untuk aplikasi itu. ClassLoader kemudian digunakan untuk memuat semua kelas aplikasi, dan saat tidak bekerja, semuanya seharusnya hilang dengan baik. Namun, pada kenyataannya itu tidak sesederhana itu.

Satu atau lebih kelas yang dibuat selama kehidupan aplikasi web memiliki referensi statis yang, di suatu tempat sepanjang garis, merujuk pada ClassLoader. Karena referensi awalnya statis, jumlah pengumpulan sampah tidak akan membersihkan referensi ini - ClassLoader, dan semua kelas yang dimuat, ada di sini untuk tinggal.

Dan setelah beberapa penugasan, kami menemukan OutOfMemoryError.

Sekarang ini telah menjadi masalah yang cukup serius. Saya bisa memastikan bahwa Tomcat dihidupkan ulang setelah setiap pemindahan, tetapi itu menurunkan seluruh server, bukan hanya aplikasi yang dipindah, yang seringkali tidak layak.

Jadi alih-alih saya telah mengumpulkan solusi dalam kode, yang berfungsi pada Apache Tomcat 6.0. Saya belum menguji pada server aplikasi lain, dan harus menekankan bahwa ini sangat mungkin tidak berfungsi tanpa modifikasi pada server aplikasi lain .

Saya juga ingin mengatakan bahwa secara pribadi saya benci kode ini, dan bahwa tidak seorang pun boleh menggunakan ini sebagai "perbaikan cepat" jika kode yang ada dapat diubah untuk menggunakan metode shutdown dan pembersihan yang benar . Satu-satunya saat ini harus digunakan adalah jika ada perpustakaan eksternal yang bergantung pada kode Anda (Dalam kasus saya, itu adalah klien RADIUS) yang tidak menyediakan sarana untuk membersihkan referensi statisnya sendiri.

Bagaimanapun, lanjutkan dengan kode. Ini harus disebut pada titik di mana aplikasi tidak dipekerjakan - seperti metode penghancuran servlet atau (pendekatan yang lebih baik) metode contextDestroyed konteks ServletContextListener.

//Get a list of all classes loaded by the current webapp classloader
WebappClassLoader classLoader = (WebappClassLoader) getClass().getClassLoader();
Field classLoaderClassesField = null;
Class clazz = WebappClassLoader.class;
while (classLoaderClassesField == null && clazz != null) {
    try {
        classLoaderClassesField = clazz.getDeclaredField("classes");
    } catch (Exception exception) {
        //do nothing
    }
    clazz = clazz.getSuperclass();
}
classLoaderClassesField.setAccessible(true);

List classes = new ArrayList((Vector)classLoaderClassesField.get(classLoader));

for (Object o : classes) {
    Class c = (Class)o;
    //Make sure you identify only the packages that are holding references to the classloader.
    //Allowing this code to clear all static references will result in all sorts
    //of horrible things (like Java segfaulting).
    if (c.getName().startsWith("com.whatever")) {
        //Kill any static references within all these classes.
        for (Field f : c.getDeclaredFields()) {
            if (Modifier.isStatic(f.getModifiers())
                    && !Modifier.isFinal(f.getModifiers())
                    && !f.getType().isPrimitive()) {
                try {
                    f.setAccessible(true);
                    f.set(null, null);
                } catch (Exception exception) {
                    //Log the exception
                }
            }
        }
    }
}

classes.clear();
22
Edward Torbett

1) Meningkatkan Ukuran Memori PermGen

Hal pertama yang bisa dilakukan adalah membuat ukuran ruang tumpukan generasi permanen lebih besar. Ini tidak dapat dilakukan dengan argumen JVM –Xms (atur ukuran heap awal) dan –Xmx (atur ukuran heap maksimum), karena seperti yang disebutkan, ruang heap generasi permanen sepenuhnya terpisah dari ruang Java Heap biasa, dan argumen ini di atur ruang untuk ruang heap Java biasa ini. Namun, ada argumen serupa yang dapat digunakan (setidaknya dengan jvms Sun/OpenJDK) untuk membuat ukuran generasi permanen lebih besar:

 -XX:MaxPermSize=128m

Standarnya adalah 64m.

2) Aktifkan Sweeping

Cara lain untuk mengatasinya adalah dengan membiarkan kelas diturunkan sehingga PermGen Anda tidak pernah habis:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Hal-hal seperti itu berhasil bagiku di masa lalu. Namun satu hal, ada pertukaran kinerja yang signifikan dalam menggunakannya, karena permgen sweep akan membuat seperti 2 permintaan tambahan untuk setiap permintaan yang Anda buat atau sesuatu di sepanjang garis itu. Anda harus menyeimbangkan penggunaan Anda dengan pengorbanan.

Anda dapat menemukan detail kesalahan ini.

http://faisalbhagat.blogspot.com/2014/09/Java-outofmemoryerror-permgen.html

15
faisalbhagat

Atau, Anda dapat beralih ke JRockit yang menangani permgen berbeda dari jvm Sun. Biasanya memiliki kinerja yang lebih baik.

http://www.Oracle.com/technetwork/middleware/jrockit/overview/index.html

15
Jeremy

Pesan ruang Java.lang.OutOfMemoryError: PermGen menunjukkan bahwa area Generasi Permanen dalam memori telah habis.

Aplikasi Java apa pun diizinkan untuk menggunakan memori dalam jumlah terbatas. Jumlah persis memori yang dapat digunakan aplikasi khusus Anda ditentukan saat startup aplikasi.

Memori Java dipisahkan menjadi beberapa wilayah yang dapat dilihat pada gambar berikut:

 enter image description here

Metaspace: Ruang memori baru dilahirkan

JDK 8 HotSpot JVM sekarang menggunakan memori asli untuk representasi metadata kelas dan disebut Metaspace; mirip dengan Oracle JRockit dan IBM JVM.

Berita baiknya adalah itu berarti tidak ada lagi masalah ruang Java.lang.OutOfMemoryError: PermGen dan tidak perlu lagi Anda mencari dan memantau ruang memori ini lagi menggunakan Java_8_Download atau lebih tinggi.

14
Santosh Jadi

Jawaban paling sederhana hari ini adalah menggunakan Java 8.

Ini tidak lagi menyimpan memori secara eksklusif untuk ruang PermGen, memungkinkan memori PermGen untuk bergabung dengan kumpulan memori biasa.

Perlu diingat bahwa Anda harus menghapus semua parameter startup JVM -XXPermGen...=... yang tidak standar jika Anda tidak ingin Java 8 mengeluh bahwa mereka tidak melakukan apa-apa.

13
Edwin Buck

Saya punya masalah yang kita bicarakan di sini, skenario saya adalah Eclipse-helios + Tomcat + jsf dan apa yang Anda lakukan adalah membuat penyebaran aplikasi sederhana ke Tomcat. Saya menunjukkan masalah yang sama di sini, menyelesaikannya sebagai berikut.

Dalam Eclipse pergi ke server tab klik dua kali pada server terdaftar dalam kasus saya Tomcat 7.0, itu membuka file server saya Informasi pendaftaran umum. Pada bagian "Informasi Umum" klik pada tautan "Buka konfigurasi peluncuran" , ini membuka eksekusi opsi server pada tab Argumen di VM argumen yang ditambahkan di akhir ini dua entri

-XX: MaxPermSize = 512m
-XX: PermSize = 512m

dan siap.

13
Hugo Mendoza
  1. Buka Tomcat7w dari direktori bin Tomcat atau ketik Monitor Tomcat di menu mulai (jendela tab dibuka dengan berbagai informasi layanan).
  2. Di area teks Opsi Java tambahkan baris ini:

    -XX:MaxPermSize=128m
    
  3. Setel Memori Awal ke 1024 (opsional).
  4. Atur Maximum Memory Pool ke 1024 (opsional).
  5. Klik Oke.
  6. Mulai ulang layanan Tomcat.
8
Lucky

Perm gen space error terjadi karena menggunakan ruang besar daripada jvm menyediakan ruang untuk mengeksekusi kode. Solusi terbaik untuk masalah ini dalam sistem operasi UNIX adalah mengubah beberapa konfigurasi pada file bash. Langkah-langkah berikut menyelesaikan masalah.

Jalankan perintah gedit .bashrc pada terminal.

Buat variabel Java_OTPS dengan nilai berikut:

export Java_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m"

Simpan file bash. Jalankan perintah exec bash di terminal. Mulai ulang server.

Saya harap pendekatan ini akan mengatasi masalah Anda. Jika Anda menggunakan versi Java lebih rendah dari 8 masalah ini kadang-kadang terjadi. Tetapi jika Anda menggunakan Java 8 masalah tidak pernah terjadi.

6
Darshan

Meningkatkan ukuran Generasi Permanen atau mengubah parameter GC TIDAK akan membantu jika Anda memiliki kebocoran memori nyata. Jika aplikasi Anda atau pustaka pihak ketiga yang digunakannya, kebocoran kelas loader satu-satunya solusi nyata dan permanen adalah menemukan kebocoran ini dan memperbaikinya. Ada sejumlah alat yang dapat membantu Anda, salah satunya adalah Plumbr , yang baru saja merilis versi baru dengan kemampuan yang diperlukan.

5
Nikem

Juga jika Anda menggunakan log4j di aplikasi web Anda, periksa paragraf ini di log4j dokumentasi .

Tampaknya jika Anda menggunakan PropertyConfigurator.configureAndWatch("log4j.properties"), Anda menyebabkan kebocoran memori saat Anda tidak menggunakan aplikasi web Anda.

5

jrockit menyelesaikan ini untuk saya juga; Namun, saya perhatikan bahwa waktu restart servlet jauh lebih buruk, jadi sementara itu lebih baik dalam produksi, itu semacam hambatan dalam pengembangan.

4
Tim Howland

Saya memiliki kombinasi Hibernate + Eclipse RCP, mencoba menggunakan -XX:MaxPermSize=512m dan -XX:PermSize=512m dan tampaknya berfungsi untuk saya.

4
Pankaj Shinde

Saya mencoba beberapa jawaban dan satu-satunya hal yang akhirnya berhasil adalah konfigurasi untuk plugin kompiler di pom:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <fork>true</fork>
        <meminitial>128m</meminitial>
        <maxmem>512m</maxmem>
        <source>1.6</source>
        <target>1.6</target>
        <!-- prevent PermGen space out of memory exception -->
        <!-- <argLine>-Xmx512m -XX:MaxPermSize=512m</argLine> -->
    </configuration>
</plugin>

semoga yang ini membantu.

4
kiwilisk

Set -XX:PermSize=64m -XX:MaxPermSize=128m. Kemudian, Anda juga dapat mencoba meningkatkan MaxPermSize. Semoga ini akan berhasil. Hal yang sama berlaku untuk saya. Pengaturan hanya MaxPermSize tidak berhasil untuk saya.

4
sandeep

Menugaskan Tomcat lebih banyak memori BUKAN solusi yang tepat.

Solusi yang benar adalah dengan melakukan pembersihan setelah konteksnya dihancurkan dan diciptakan kembali (penyebaran panas). Solusinya adalah menghentikan kebocoran memori.

Jika Tomcat/Webapp Server Anda memberi tahu Anda bahwa gagal untuk membatalkan registrasi driver (JDBC), maka batalkan registrasi. Ini akan menghentikan kebocoran memori.

Anda dapat membuat ServletContextListener dan mengkonfigurasinya di web.xml Anda. Berikut ini adalah contoh ServletContextListener:

import Java.sql.Driver;
import Java.sql.DriverManager;
import Java.sql.SQLException;
import Java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.Apache.log4j.Logger;

import com.mysql.jdbc.AbandonedConnectionCleanupThread;

/**
 * 
 * @author alejandro.tkachuk / calculistik.com
 *
 */
public class AppContextListener implements ServletContextListener {

    private static final Logger logger = Logger.getLogger(AppContextListener.class);

    @Override
    public void contextInitialized(ServletContextEvent arg0) {
        logger.info("AppContextListener started");
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0) {
        logger.info("AppContextListener destroyed");

        // manually unregister the JDBC drivers
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
                logger.info(String.format("Unregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                logger.info(String.format("Error unregistering driver %s", driver), e);
            }

        }

        // manually shutdown clean up threads
        try {
            AbandonedConnectionCleanupThread.shutdown();
            logger.info("Shutting down AbandonedConnectionCleanupThread");
        } catch (InterruptedException e) {
            logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
            e.printStackTrace();
        }        
    }
}

Dan di sini Anda mengkonfigurasinya di web.xml Anda:

<listener>
    <listener-class>
        com.calculistik.mediweb.context.AppContextListener 
    </listener-class>
</listener>  

Mereka mengatakan bahwa rev terbaru dari Tomcat (6.0.28 atau 6.0.29) menangani tugas penempatan kembali servlets jauh lebih baik.

3
Tony Ennis

Langkah pertama dalam kasus tersebut adalah memeriksa apakah GC diizinkan untuk menurunkan kelas dari PermGen. Standar JVM agak konservatif dalam hal ini - kelas dilahirkan untuk hidup selamanya. Jadi, sekali dimuat, kelas tetap berada dalam memori bahkan jika tidak ada kode yang menggunakannya lagi. Ini bisa menjadi masalah ketika aplikasi membuat banyak kelas secara dinamis dan kelas yang dihasilkan tidak diperlukan untuk periode yang lebih lama. Dalam kasus seperti itu, membiarkan JVM membongkar definisi kelas dapat membantu. Ini dapat dicapai dengan menambahkan hanya satu parameter konfigurasi ke skrip startup Anda:

-XX:+CMSClassUnloadingEnabled

Secara default ini disetel ke false dan untuk mengaktifkannya, Anda perlu secara eksplisit mengatur opsi berikut dalam opsi Java. Jika Anda mengaktifkan CMSClassUnloadingEnabled, GC juga akan menyapu PermGen dan menghapus kelas yang tidak lagi digunakan. Perlu diingat bahwa opsi ini hanya akan berfungsi ketika UseConcMarkSweepGC juga diaktifkan menggunakan opsi di bawah ini. Jadi ketika menjalankan ParallelGC atau, Tuhan melarang, Serial GC, pastikan Anda telah mengatur GC Anda ke CMS dengan menentukan:

-XX:+UseConcMarkSweepGC
3
sendon1982

Saya mengalami masalah yang persis sama, tetapi sayangnya tidak ada solusi yang disarankan yang bekerja untuk saya. Masalahnya tidak terjadi selama penyebaran, dan saya tidak melakukan penyebaran panas.

Dalam kasus saya, masalah terjadi setiap kali pada titik yang sama selama eksekusi aplikasi web saya, saat menghubungkan (via hibernate) ke database.

Tautan ini (juga disebutkan sebelumnya) memang menyediakan bagian dalam yang cukup untuk menyelesaikan masalah. Memindahkan driver jdbc- (mysql) dari WEB-INF dan ke folder jre/lib/ext/tampaknya telah menyelesaikan masalah. Ini bukan solusi yang ideal, karena memutakhirkan ke JRE yang lebih baru akan mengharuskan Anda untuk menginstal ulang driver. Kandidat lain yang dapat menyebabkan masalah serupa adalah log4j, jadi Anda mungkin ingin memindahkannya juga

3
Maze

Konfigurasi memori tergantung pada sifat aplikasi Anda.

Apa yang sedang kamu lakukan?

Berapa jumlah transaksi yang sudah dilakukan?

Berapa banyak data yang Anda muat?

dll.

dll.

dll

Mungkin Anda dapat membuat profil aplikasi Anda dan mulai membersihkan beberapa modul dari aplikasi Anda.

Rupanya ini dapat terjadi setelah memindahkan aplikasi beberapa kali

Tomcat memiliki penyebaran panas tetapi menghabiskan memori. Coba mulai ulang wadah Anda sesekali. Anda juga perlu mengetahui jumlah memori yang diperlukan untuk berjalan dalam mode produksi, ini sepertinya waktu yang tepat untuk penelitian itu.

3
OscarRyz

Jika Anda mendapatkan ini di Eclipse IDE, bahkan setelah mengatur parameter --launcher.XXMaxPermSize, -XX:MaxPermSize, dll, masih jika Anda mendapatkan kesalahan yang sama, kemungkinan besar Eclipse menggunakan versi kereta JRE yang akan diinstal oleh beberapa aplikasi pihak ketiga dan diatur ke default. Versi kereta ini tidak mengambil parameter PermSize dan jadi apa pun yang Anda atur, Anda masih terus mendapatkan kesalahan memori ini. Jadi, di Eclipse.ini Anda tambahkan parameter berikut:

-vm <path to the right JRE directory>/<name of javaw executable>

Pastikan juga Anda mengatur JRE default di preferensi di Eclipse ke versi Java yang benar.

2
Hrishikesh Kumar

Satu-satunya cara yang berhasil bagi saya adalah dengan JVM JRockit. Saya memiliki MyEclipse 8.6.

Tumpukan JVM menyimpan semua objek yang dihasilkan oleh program Java yang sedang berjalan. Java menggunakan operator new untuk membuat objek, dan memori untuk objek baru dialokasikan pada heap saat dijalankan. Pengumpulan sampah adalah mekanisme untuk secara otomatis membebaskan memori yang terkandung oleh objek yang tidak lagi dirujuk oleh program.

2
Daniel

Saya mengalami masalah serupa. Tambang saya adalah JDK 7 + Maven 3.0.2 + Struts 2.0 + proyek berbasis ketergantungan ketergantungan GUICE Google.

Setiap kali saya mencoba menjalankanmvn clean packageperintah, itu menunjukkan kesalahan berikut dan "BUILD FAILURE" terjadi

org.Apache.maven.surefire.util.SurefireReflectionException: Java.lang.reflect.InvocationTargetException; pengecualian bersarang adalah Java.lang.reflect.InvocationTargetException: null Java.lang.reflect.InvocationTargetException Disebabkan oleh: Java.lang.OutOfMemoryError: PermGen space

Saya mencoba semua tips dan trik yang berguna tetapi sayangnya tidak ada yang berhasil untuk saya. Apa yang berhasil bagi saya dijelaskan langkah demi langkah di bawah ini: =>

  1. Buka pom.xml Anda
  2. Cari <artifactId>maven-surefire-plugin</artifactId>
  3. Tambahkan elemen <configuration> baru dan kemudian sub elemen <argLine> di mana melewati -Xmx512m -XX:MaxPermSize=256m seperti yang ditunjukkan di bawah =>

<configuration> <argLine>-Xmx512m -XX:MaxPermSize=256m</argLine> </configuration>

Semoga bisa membantu, selamat pemrograman :)

2

"Mereka" salah karena saya menjalankan 6.0.29 dan memiliki masalah yang sama bahkan setelah mengatur semua opsi. Seperti yang dikatakan Tim Howland di atas, opsi-opsi ini hanya menunda yang tak terhindarkan. Mereka mengizinkan saya untuk memindahkan 3 kali sebelum memukul kesalahan daripada setiap kali saya memindahkan.

2
Ross Peoples

Anda juga dapat mengatasi masalah ini dengan melakukan:

rm -rf <Tomcat-dir>/work/* <Tomcat-dir>/temp/*

Menghapus direktori work dan temp membuat Tomcat melakukan startup yang bersih.

1
dev

Jika ada orang yang berjuang dengan kesalahan yang sama di netbeans, maka di sini adalah bagaimana saya memperbaikinya.

Di Netbeans:

Buka tab layanan -> Tepat di server -> Pilih properti -> buka tab platform -> Di dalam opsi vm ketik -Xms1024m

Dalam kasus saya, saya telah memberikan -Xms4096m

Berikut screenshotnya:

 enter image description here

0
Satyadev