Споживання пам'яті JVM

9

Я намагаюся запустити tomcat на низькій системі пам'яті (150-256Mb). Незважаючи на те, що я запускаю JVM з -Xmx64m (який у будь-якому випадку повинен бути типовим), процес негайно займає 200Mb +.

Цікаво, чому JVM потребує стільки самої пам’яті, чи є спосіб налаштування цього? Чи інші JVM краще, ніж сонце, для низького споживання пам’яті - і вони працюють з tomcat?

memory tomcat java

— Драмон
джерело

5

На додаток до купи (вказаної -Xmsі -Xmx) потрібно включити негромадні ділянки. До них відносяться

Пермський ген, який спочатку складає 64 Мбайт у 32-бітових системах, а на 64-бітних системах - 96 Мб
Кеш-код коду, який становить від 20 до 40 Мб залежно від JVM
Область буфера NIO (звідки виведені DirectByteBuffers), це спочатку 64 Мб

Є також робочий простір самого JVM, який становитиме кілька десятків мб.

Ви також повинні знати про автоматичний розмір Sun JVM під час використання машини серверного класу . З часом визначення класу серверів (2 Гб оперативної пам’яті, більше одного ядра) зазнало певної амортизації, і тепер більшість машин здатні викликати -serverоптимізацію. Моя порада завжди вказувати -Xmsта -Xmxналаштування та проходити, -serverякщо ви теж не можете придумати вагому причину.

— Дейв Чейні
джерело

Остерігайтеся також віртуальної пам’яті, що JVM лише резервує, та ще не використовує.

— Стів Шнепп

Правда, більшість цих сегментів, як PermGen і Кеш коду, виділяються при запуску, але більшість ядер уникатимуть виділення сторінок до цих сегментів, поки це не потрібно.

— Дейв Чейні

1

Дякую за інформацію - я думаю, це пояснює, куди йде пам’ять. Чи є спосіб змінити ці значення? Ще краще було б способом побачити, скільки використовувався кожен розділ - я не знаю, чи який-небудь із інструментів налагодження / моніторингу Java дозволив вам це зробити?

— Draemon

1

Ви можете використовувати pmap або jmap, щоб отримати уявлення про різні використовувані сегменти. Більшість поширених варіантів (та їх за замовчуванням) перераховані тут, java.sun.com/javase/technologies/hotspot/vmoptions.jsp . Вони часто змінюються і підлягають різниці в ОС (розмір стека зазвичай) та арці (64-бітова ОС, як правило, передбачає більші області JVM)

— Дейв Чейні,

3

За допомогою параметра -Xmx ви обмежуєте розмір купи, яку резервує JVM ... Є додаткові ресурси, необхідні JVM ...

"Дякую за пам'ять" * - це добра стаття, яка пояснює, як JVM використовує пам'ять ...

Крім того, що ви могли б спробувати JVM IBM, він повинен працювати з Tomcat, не знаю, чи працюють деякі безкоштовні JVM-програми.

Тим не менш, я не думаю, що машина з такою низькою пам’яттю не піде на користь. Яві просто потрібна пам'ять.

* Оскільки нові користувачі не можуть надсилати гіперпосилання, вам доведеться самостійно шукати цю статтю ... це перше звернення в Google за "спасибі за ibm пам'яті".

— дертоні
джерело

3

ibm.com/developerworks/java/library/j-nativememory-linux - Посилання на статтю "Спасибі за пам'ять"

— StackKrish

2

Спробуйте також JRockit JVM, який має менше пам’яті. Ви все ще можете завантажити безкоштовно ліцензовані версії JRockit BEA безкоштовно. тобто версії до того, як Oracle перейняв BEA.

Див. Http://forums.oracle.com/forums/thread.jspa?threadID=816133&tstart=0 для посилань на завантаження.

— StackKrish
джерело

0

Один з корисних методів, які я знайшов, - це використовувати моніторинг JMX, щоб точно побачити, скільки пам’яті використовує простір купи та пермгенів.

Налаштуйте JMX у Tomcat, як описано тут http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

Потім скористайтеся JConsole (поставляється з JDK 5 або JDK 6) - тег пам'яті буде відслідковувати споживання пам'яті з часом.

Також - остерігайтеся м'яких перезавантажень веб-сайтів. Якщо ви перезавантажите webapp, пермгенський простір не збиратиметься сміттям і накопичуватиметься з часом. Вам потрібно зробити повну зупинку / запуск Tomcat, щоб повернути пермгенський простір.

— Буде Глас
джерело

VisualVM також можна використовувати замість JConsole та надавати ще більше деталей при пошуку проблем із пам'яттю в JVM. Мені довелося використовувати це не один раз, щоб знайти проблеми.

— Джеремі Бауз