В обсуждении с коллегой было обнаружено, что разные настройки памяти IntelliJ IDEA по-разному влияют на скорость и отзывчивость IDE.
Не будьте Скруджем и дайте вашей IDE больше памяти
Не скупитесь, оставьте больше памяти для IDE.
Вчера все обсуждали, нужно ли настраивать параметры памяти IntelliJ IDEA, Кто-то выбирает настройки по умолчанию, кто-то вносит простые изменения в настройки по умолчанию, а некоторые разработчики делают комплексные и сложные настройки исходя из своих потребностей. Текущая работа автора заключается в работе с несколькими микросервисными проектами и старым проектом, а основные бизнес-потребности заказчика очень велики. После простой настройки памяти IntelliJ IDEA автор явно почувствовал улучшение IDE в плане скорости и отзывчивости. Но на тот момент автор не проводил конкретных замеров, так что это просто субъективное ощущение.
Однако один из разработчиков, участвовавших в обсуждении, прислал мне копию своего крайне сложного сетапа, хотя и для того же проекта. Я не недоволен своими настройками, но мне любопытно, как эти совершенно разные настройки соотносятся с настройками по умолчанию, предоставленными JetBrains.
Цель
План автора состоит в том, чтобы протестировать эффект каждой настройки в сценарии, близком к ежедневному проекту разработки (загрузить большой проект, загрузить 2 или 3 микросервиса, обновить большой проект после git pull), и выбрать потребление памяти и оптимальные настройки, когда обе скорости оптимальны.
Испытательные машины и проекты
Ноутбук: MacBook Pro Retina, Intel Core i7 2,3 ГГц, 16 ГБ памяти DDR3 1600 МГц, SSD-диск, OS X Yosemite
проект
Большой проект — Monolith, 700 тыс. строк кода (Java[1] 8 и Groovy), 303 модуля Gradle
Два микросервиса — около 10 000 — небольшие проекты по 20 000 строк кода (Java 8 и Groovy), каждый с модулем Gradle
сценарии тестирования
1. Закройте все проекты в Idea
2. Установить на основе тестового файла idea.vmoptions
3. Перезагрузите компьютер
4. Закройте все неактуальные проекты после запуска (коммуникаторы и т.д.)
5. Открытая идея (время тестирования)
6. Открывайте большие проекты (время тестирования)
7. Проверьте jstat -gcutil
8. Откройте два микросервисных проекта (время тестирования)
9. Проверьте jstat -gcutil
10. Вернитесь к большому проекту и нажмите кнопку «Обновить проект Gradle» (время тестирования)
11. Проверьте jstat -gcutil
jstat -gcutil
jstat — это инструмент, поставляемый с JDK, который в основном использует встроенные инструкции JVM для выполнения мониторинга ресурсов и производительности Java-приложений из командной строки в режиме реального времени, а также включает мониторинг размера кучи и состояния сборки мусора. Он имеет множество опций для сбора различных данных, но используется только здесь:
-gcutil :
-gcutil - Summary of garbage collection statistics.
S0: Survivor space 0 utilization as a percentage of the space's current capacity.
S1: Survivor space 1 utilization as a percentage of the space's current capacity.
E: Eden space utilization as a percentage of the space's current capacity.
O: Old space utilization as a percentage of the space's current capacity.
M: Metaspace utilization as a percentage of the space's current capacity.
CCS: Compressed class space utilization as a percentage.
YGC: Number of young generation GC events.
YGCT: Young generation garbage collection time.
FGC: Number of full GC events.
FGCT: Full garbage collection time.
GCT: Total garbage collection time.
Вывод этой команды выглядит следующим образом:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159
在本文中，最重要的参数是 GC 事件（ YGC 和 FGC ）次数和收集时间（ YGCT 和 FGCT ）。
Испытательная установка
Автор установил четыре разных параметра и дал им разные имена, чтобы их было легче запомнить.
По умолчанию (серая метка)
Настройки по умолчанию, предоставленные JetBrains:
-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
Большой (большой) (красный логотип)
С 4096 МБ для Xmx и 1024 МБ для ReservedCodeCacheSize это довольно много памяти:
-Xms1024m-Xmx4096m-XX:ReservedCodeCacheSize=1024m-XX:+UseCompressedOops
Balanced (сбалансированный) (синий логотип)
И Xmx, и Xms выделяют 2 ГБ, что является довольно сбалансированным потреблением памяти:
-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Сложный (в оранжевом цвете)
Как и выше, Xmx и Xms выделяют 2 ГБ, но указывают разные сборщики мусора и множество разных флагов для GC и управления памятью:
-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-ea
Выше приведены авторские настройки теста. Чтобы выполнить этот тестовый пример, вам нужно создать файл idea.vmoptions в папке ~/Library/Preferences/IntelliJIdea15/ (это настройка пути в системе Mac OS, установленная на основе вашей операционной системы). система)
Теперь выполните тестовый пример и сравните результаты.
результат
Время запуска идеи
Как показано на изображении выше, время запуска не зависит от настроек памяти. Время тестирования идеи во всех сценариях составляет 10 секунд, независимо от того, сколько памяти выделено. Это неудивительно, так как на этом раннем этапе эти настройки не влияют на поведение приложения.
Время, потраченное на загрузку больших проектов
Теперь загрузите проект Monolith и его 700 тысяч строк кода. В итоге выявились некоторые отличия. Настройка по умолчанию заняла почти в 3 раза больше времени. Очевидно, что для такой большой базы кода требуется больше памяти. Если мы выполним:
jstat -gcutil <IDEA_PID>
Вы обнаружите, что, по сравнению с другими настройками, GC очень занят настройками по умолчанию.
Мало того, что общее время сборки мусора для освобождения памяти очень велико (почти в 50 раз), среднее время выполнения полной сборки мусора также очень и очень велико. На Full GC тратится много времени, что является основной причиной низкой отзывчивости IDE.
Откройте два микросервиса в IDEA
Теперь загрузите эти два микросервисных проекта, откройте их в IDEA и сравните время, которое они занимают.
В этом тестовом случае разница все еще довольно заметна: комплексная настройка работает лучше всего, в то время как настройка по умолчанию все еще проигрывает двум другим настройкам.
Используйте снова jstat --gcutil
После загрузки двух проектов микросервиса давайте проверим производительность GC при одновременном открытии трех проектов. После тестирования выяснилось, что производительность 3-х разных пользовательских настроек практически одинакова, а настройки по умолчанию просто слабые.
Финальная гонка: перезарядка «Монолита»
Теперь мне нужно получить последнюю версию проекта Monolith из репозитория и обновить модуль Gradle, чтобы IDEA могла видеть все новые классы.
ВАЖНО: серые полосы, представляющие настройки по умолчанию, очень высокие, потому что во время обновления IDEA произошел сбой, и я не могу измерить фактическое время. Видимо, выделенной по умолчанию памяти недостаточно для выполнения операции.
Но из трех пользовательских примеров видно, что конфигурация с большой памятью занимает самое короткое время. Таким образом, распределение памяти по-прежнему играет роль.
Последнее использование jstat-gcutil
Поскольку IDEA не может обновить проект с настройками по умолчанию, настройки по умолчанию для этого теста не включены.
Как видно из рисунка выше, разница между тремя невелика, но время выполнения Full GC в конфигурации Big самое быстрое. Кроме того, большая память Xmx значительно помогает в быстродействии.
Суммировать
В этом кратком эксперименте видно, что даже тонкая настройка памяти IntelliJ IDEA может значительно повысить производительность IDE. Конечно, чем больше выделено памяти, тем лучше исполнение. Однако вы также обнаружите, что многие другие приложения за пределами IDE также потребляют память, поэтому вашей целью должен быть поиск баланса между повышением производительности и потреблением памяти.
На мой взгляд, установка значения Xmx между 2G и 3G оптимальна в большинстве случаев. Если у вас есть больше времени, вы можете использовать jstat и jvisualm, чтобы проверить, как различные настройки JVM влияют на производительность и использование памяти.
перевести:D zone.com/articles/days Later…
Автор: Сяоха изучает Java