Linux для всех

индекс
247,21

Установка и ускорение Eclipse и Java Virtual Machine

Eclipse — замечательная IDE. Умеет все, бесплатна, куча расширений (бесплатных в большинстве!), кроссплатформенна. Все красиво. Но даже в эту бочку меда по умолчанию вставлена ложка дегтя, особенно в Unix системах.

В основном эта ложка дегтя проявляется в виде капитальных тормозов. Даже при банальном скроле и добавлении строки — видны добротные лаги. Про автозавершение кода — я вообще молчу. Такое ощущение как будто варианты завершения PDT каждый раз качает из инета.

Попытаемся уменьшить тормоза (настройки Eclipse актуальные и для Unix'а и для для Windows — внизу статьи). Ниже описан оптимальный с моей точки зрения базовый процесс установки и базовой настройки Eclipse для Unix систем. В первую очередь для таких же как я начинающих линуксоидов. Так как начинать бывает очень сложно, но хочется…


1. Установка Eclipse — только не из репозитория!
Репозитории, как известно, предназначены для удобного автоматического обновления дистрибутиво-зависимого софта. Но Eclipse не зависит от конкретного дистрибутива (спасибо яве), а также имеет свои замечательные средства для автоматического обновления.

У меня стоит Mandriva 2009.1. В ее репозитории до сих пор лежит Eclipse 3.4.2, хотя давно вышел Eclipse 3.5 с кучей очень позитивных обновлений. Репозиторий в данном случае — лишняя прослойка, основательно увеличивающая задержки в обновлении.

Проще всего получить нужный дистриб Eclipse зайдя на сайт интересующего подпроекта Eclipse и скачать там какой-нибудь all-in-one. Меня интересует PHP Development Tools, но думаю и у остальных проектов найти нужный инсталл будет легко.

2. Установка Java SE SDK
Из-за каких-то лицензионных проблем (даже не хочется сейчас вникать :)) по дефолту в дистрибах как правило стоит OpenJDK вместо нормального Sun Java SE SDK;
OpenJDK — это попытка Sun Microsystems создать полностью совместимый Java Development Kit, состоящий исключительно из свободного и открытого исходного кода. © wikipedia

И в итоге, эта попытка весьма плохо работает с эклипсом. Внезапных вылетов нет (раньше говорят были), но тормоза конкретные. Поэтому пускай они пока пытаются, а мы не будем мучаться и поставим нормальный дистриб ява машины. Благо это делается элементарно.

  1. Сперва надо скачать последнюю версию Java SE SDK. Сейчас это 1.6.0_14 (она то и нужна!). Я выбрал самый простой бинарный дистриб, чего советую и вам. (у меня — 64 битная система и дистриб соостветствующий)
  2. Cделать в chmod +x ./jdk-6u14-linux-x64.bin (ну или как там его… ну вы поняли)
  3. ./jdk-6u14-linux-x64.bin :)
  4. Теперь идем в /usr/bin/ Там у меня была символическая ссылка на java, только с какого-то черта она была сделана через update-alternatives. Я попробовал узнать что это за зверь. Пытался почитать ман и сделать update-alternatives --set… Но как-то не пошло. Особо желания разбираться не было — просто переименовал старую ссылку и создал новую, но уже на свежий дистриб явы
    mv java java_
    ln -s /home/sword/ware/jdk1.6.0_14/bin/java /usr/bin/java
Теперь эклипс должен запускаться на новой яве. В дальнейшем лучше подписаться на обновления с сайта Sun (мир его праху), качать бинарник и запускать — по сути только распаковывать. Надеюсь.
 
3. Общее Unix && Win — настройка параметров запуска Eclipse
В папке с эклипсом лежит файлик eclipse.ini внезависимости от ОС. Там прописаны параметры виртуальной машины.

У меня там было прописано что эклипс занимается не более 128mb оперативки. С учетом того что это основной рабочий инструмент, при двух гигах оперативы на борту я готов дать ему и побольше. Прописал побольше.
384m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=512m
-Xms128m
-Xmx384m
И еще добавил пару хитрых параметров настраивающих Garbage Collector, т.е. сборщика мусора. Эти параметры по идее должны заметно ускорить работу (сколько же там мусора?!) виртуальной машины на многопроцессорной машине, коей я обладаю.
-XX:-UseParallelGC
-XX:+UseConcMarkSweepGC
-XX:+AggressiveOpts
Особое внимание стоит обратить на -XX:+UseConcMarkSweepGC, который стал доступен в JDK 1.6.0_14, который мы установили. В OpenJDK 1.6.0_0 стоявшем у меня в системе до этого поддержки этой опции не было.

Кому интересен вопрос — читайте маны, по идее виртуальную машину можно еще разогнать. Опций — очень много всяких разных. Можно организовать очень эффективное взаимодействие с виртуальной машиной.

Результат
Вроде как стало быстрее и комфортней. Полностью лаги не исчезли, все таки Eclipse — монстр. И за это приходится платить. Но работать стало комфортней. А еще надо определенно поразбираться с разными ключами для запуска — думаю можно без особых проблем выжать еще скорости.

Основной минус подобной оптимизации — придется Java SDK ручками обновлять. Хотя и этого можно попробовать избежать — когда выйдет OpenJDK 1.6.0_14 (а может сразу еще свежей) — можно попробовать как эклипс будет работать с ним. Для этого надо только одну символическую ссылку поправить. Если устроит работа OpenJDK — его можно и оставить. Пускай обновляется из репы.
Update Кто-нибудь, подскажите, как объективно можно измерить производительность эклипса? (в идеале — лпроизводительность интерфейса)

Кросспост «Установка, настройка и ускорение Eclipse IDE» с моей Личной веб-лаборатории :)
+26
22 июля 2009, 08:08
76

комментарии (78)

+1
Bushka #
DenisO, вы ставили какой-нибудь плагин для работы с СУБД?
DBViewer или что-нибудь другое?
+1
DenisO #
К эклипсу не ставил. Можно вкратце — для чего он? И к чему вопрос? :)
0
BSDaemon #
Bushka, я пробовал юзать и Data Tools Platform и DBViewer и SQL explorer. Честно говоря — ничего не понравилось настолько сильно, чтобы я стал это постоянно использовать. На данный момент остановился на DTP. Но конечно же она не универсальна, но посмотреть таблицы и их структуру можно, а вот хранимки и работать с данными — не айс. А приходится работать с MySQL/MSSQL/Oracle. Поэтому редко использую… Жду пока что-нибудь напишут получше :)
0
DenisO #
Я в основном работаю с MySQL — для проектирования полностью устраивает MySQL Workbench. В ближаешей перспективе обещают прикрутить админинг и другие важные вещи.
–4
mrShadow #
Информация пользователям Ubuntu. Там все тормоза Eclipse связаны не с JDK, а с JVM. По умолчанию в Ubuntu с Eclipse устанавливается gcj, очень тормозное и глючное поделие, по словам знакомого программиста на Java. А вот использовать ли OpenJDK или версию от Sun — всё равно, разницы в производительности я не заметил. Как установить и настроить версию JVM от Sun, можно посмотреть здесь: ubuntuforums.org/showthread.php?t=201378.
0
DenisO #
Кажется вы запутались в терминах. JVM — является частью JDK. Если перейти по вашей ссылке — там написано
«sudo apt-get install eclipse sun-java6-jdk» :)

В принципе эта ссылка не помешала бы, только она 2006 года. Через 4 дня ей исполнится 3 года. :) Если товарищи убунтоводы подтвердят материал до сих пор актуален — добавлю ссылку в конец поста.

Товарищи убунтоводы, поможете? :)
0
mrShadow #
Что сказать, плохо я в явовской терминологии разбираюсь. Если JVM — часть JDK, тогда возможно, что нужен только JRE.

Насчёт того, что указано по ссылке. Надо брать только нужные части той инструкции (update-java-alternatives, /etc/jvm, /etc/eclipse/java_home), а устанавливать то, что нужно. Я бы попробовал установить сначала только JRE, если что-то пойдёт не так, тогда и JDK.

Насчёт актуальности. По-моему, я когда Eclipse ставил, именно этой ссылкой пользовался. Точно не скажу, может были ссылки получше, но сохранилась только эта.
+1
adnull #
А почему неактуальна? gcj все так же плох.
+4
Allen #
В ubuntu:

sudo apt-get install sun-java6-jdk
sudo update-alternatives --config java (выбираем sun 1.6)
java -version (проверяем)
0
obiwanus #
Для тех, кто будет ставить таким образом jdk в ubuntu 10.04, надо сначала сделать:
sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo apt-get update
и только потом
sudo apt-get install sun-java6-jdk

А то в репозитории нет этого пакета.
0
bobry #
а какие нибудь объективные показатели свидетельствующие об улучшении производительности можете привести?
0
DenisO #
С удовольствием, но только если мне кто-нибудь расскажет как замерить производительность эклипса?
–1
MaximKat #
Время компиляции большого проекта
0
u_story #
Это будет время работы компилятора + интерпретатора скрипта сборки. %)
0
MaximKat #
Хотя это пожалуй не совсем то. Тогда время рефакторинга какого-нибудь в большом проекте, время загрузки.
0
DenisO #
Мне кажется лучшим способом было бы
1. записать (чем?) макрос, который бы эмулировал интенсивную работу пользователя (мышка + клава) в течении нескольких (2-10) минут с наиболее типовыми действиями
2. отслеживать нагрузку на проц в процессе работы — это проблем не вызовет

По идее это примерно то что хотелось бы увидеть.
0
u_story #
Вы по сути настраиваете jvm, а эклипс это только приложение которое работает на ней.
Т.е. можно просто протестировать небольшие программки, с различными параметрами jvm, и разобраться каких случаях какие настройки jvm предпочтительнее использовать.
Хотя что-то мне подсказывает, ещё много будет зависеть от ОС, ибо методы работы с памятью в Solaris и WinXP отличаются.
0
DenisO #
По сути — да. Все свелось к jvm. Но!

Небольшие программки тестировать мне кажется смысла нет — моя цель конкретно настроить эклипс для комфортной работы. Боюсь у него специфика будет сильно отличаться от небольших программок.

По поводу ОС — было бы хорошо добиться хороших результатов в линуксе, на своем железе. А там может бы и на другом сравнить. Но в первую очередь — все для себя сделать удобно. :)
0
TheShade #
Вы можете попробовать взять бенчмарк eclipse из набора тестов Dacapo:
eclipse: executes some of the (non-gui) jdt performance tests for the Eclipse IDE
0
DenisO #
Спасибо, посмотрю. Хотя конечно смущает «non-gui» — хотелось бы как раз наоборот — ГУЙ потестить.
0
TheShade #
Я когда-то по работе (java performance engineering) написал на AutoIt/X11GuiTest автоматические скрипты, которые поднимали Eclipse с большим проектом и делали там нетривиальную дебаг-сессию (старт IDE, расстановка брекпоинтов, запуск, пара шагов, остановка, рефакторинг, закрытие IDE). К сожалению, эти скрипты не публичны, придётся вам отдельно попотеть, если хотите :)
0
DenisO #
Подразнили. :)

AutoIt'а нет под мою рабочую ОС.
0
DenisO #
Упс… Кажется есть. Спасибо за наводку, я думал это win-only.
0
TheShade #
Тогда, в далёком 2005-том, AutoIt был только под винду, поэтому для *nix мы использовали X11GuiTest.
0
TheShade #
Никакого дразнения :) Просто говорю, что это возможно. И даже описал путь, которым ходят специалисты по производительности Java.
0
DenisO #
Да я же шучу. :)

Спасибо конечно за наводку, тем более идущую от такого опыта.
–1
ganqqwerty #
Классная статья для тех линуксоидов, которые уже не совсем дятлы, но ядро пока компилять не пытались и LFS не настраивали. Спасибо вам большое!
+1
DenisO #
Ядро комплить просто. Более чем. В одном из старых номеров LXF (69?) была хорошая статья на эту тему. Все прошло как по маслу. :)
+2
u_story #
А почему "-XX:-UseParallelGC" ускорить работу? Это же по сути отключение параллельной работы GC. Да и по умолчанию для Sun JVM, как раз такое значение стоит, судя по: java.sun.com/javase/technologies/hotspot/vmoptions.jsp
0
DenisO #
-XX:UseParallelGC и -XX:UseConcMarkSweepGC являются взаимоисключающими решениями. Для многопроцессорных систем по идее лучше подойдет -XX:+UseConcMarkSweepGC.

Хотя это все конечно стоило бы замерить с помощью логов за пару рабочих суток. Только как такие логи получить?
0
u_story #
Про логи не знаю, но если сможете разобраться во всем этом будет очень круто. =)
Я себе сейчас ради эксперимента поставил: -XX:-UseParallelOldGC (Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC.) Пока полёт нормальный.

Ещё неплохо было бы погонять G1 (новый сборщик мусора), он как раз в 1.6_14 появился.
0
DenisO #
Вот прикольная страничка по теме:
java.sun.com/developer/technicalArticles/Programming/GCPortal/

Логи GC получить можно. Вопрос только что там будет. Мне кажется что лучше пытаться получить логи о работе эклипса в целом, вопрос только как.
0
DenisO #
Раз тематика столь интересна — попытаюсь поглубже разобраться.
+1
u_story #
Заранее спасибо. Надеюсь у вас получится.
Только в название статьи отобразите, что вы не только про Eclipse пишите, но и про настройки jvm, тогда количество людей прочитавших статью увеличится.
0
u_story #
Ещё по теме страничка: www.softwaresecretweapons.com/jspwiki/thelastjavagarbagecollectionguideyouwilleverneed
Только старая она. :( У нас уже 1.6 во всю используется, да и 1.7 не за горами.
0
TheShade #
Не обязательно смотреть в логи GC. На вашем месте я бы взял VisualVM, прицепился к вашему эклипсу и посмотрел на GC activity через VisualGC.
0
DenisO #
Список потенциальных инструментов пополнился.
+1
shuvalov #
Очень странный способ. Если менять симлинк на java — то вы просто поменяли код для запуска java приложений. Причем во всей системе. Причем симлинк ведет в хомдир! Ну да ладно, только вот, насколько мне известно, в Linux есть файл /etc/eclipse/java_home, который опеределяет какую версию Java нужно использовать.
–1
DenisO #
Хотелось сделать чтоб без запар и побыстрее заработало. Все работает.

Не сервер, поэтому так можно. :)
+1
shuvalov #
Для себя то конечно можно и не такое. Но вот на Хабр можно и без симлинков на хомдир и замещения важных команд текст отправлять. Вы же все таки претендуете на мануал. Если этим мануалом будут пользоваться Java программисты, то они могут встретить некоторые трудности в резултьтате таких экспериментов с java launcher`ом.
0
DenisO #
Я исправлюсь :)))
0
giner #
Это верно.
Данную задачу лучше решать через изменение переменных окружения в отдельном скрипте, например:
#!/bin/sh
PATH=xxx:$PATH
JAVA_VAR1=yyy
JAVA_VAR2=zzz
export PATH JAVA_VAR1 JAVA_VAR2
а ниже строка запуска приложения
+1
jcd #
На днях появилась новая Aptana Studio 1.5 — на базе Eclipse 3.5. Для правки параметров в Standalone-версии надо открывать AptanaStudio.ini, ну а там все по аналогии с инструкциями автора статьи. Я тоже первым делом увеличил лимиты по оперативной памяти, вроде быстрее стало работать.

0
Masterme #
проц/частота какие?
0
DenisO #
Pentium Dual Core 1.8
0
Masterme #
Эклипс с обоими ядрами работает или с одним?
0
DenisO #
С обоими.
0
Masterme #
Почему спрашиваю. Я когда поставил себе Zend Studio (6.1) на эклипсе, он тоже сперва слегка тормозил, когда использовал WYSIWY, и пиковая загрузка была 50%, т.е. одно использовалось ядро из двух. Я даже тему в php-сообществе создал, как заставить эклипс работать с 2мя ядрами, но никто не знал.
Сейчас обращаю внимание — эклипс систему практически не грузит, запуск и дебаг быстрые, т.е. как надо. Как так получилось — не знаю, может дело в том, что в Startup and Shutdown всё поотрубал :)
Проц E8400/3.6ГГц
0
TheShade #
Да, кстати, проверьте, что у вас эргономика включила серверный режим (у меня по умолчанию включает). С серверным компилятором на борту быстрее (ThinkPad T61 [C2D 2.0Ghz] / Gentoo Linux x86):

/opt/jdk1.6.0_14/bin/java -client -jar dacapo-2006-10-MR2.jar -converge eclipse
===== DaCapo eclipse PASSED in 35376 msec =====

/opt/jdk1.6.0_14/bin/java -server -jar dacapo-2006-10-MR2.jar -converge eclipse
===== DaCapo eclipse PASSED in 24788 msec =====

… а теперь небольшая иллюстрация к тезису «Premature optimization is the root of all evil», добавим к серверному ключик AggressiveOpts:

/opt/jdk1.6.0_14/bin/java -server -XX:+AggressiveOpts -jar dacapo-2006-10-MR2.jar -converge eclipse
===== DaCapo eclipse PASSED in 26705 msec =====


–1
dea #
-server дает предкомпиляцию байткода в JIT, так что ускорение получится только для однократного запуска теста, что собственно и наблюдаем, а для продолжительной работы с IDE разница, скорее всего, будет незначительной (все скомпилируется и так со временем), а вот время загрузки eclipse будет существенно выше без -server, хотя это, конечно, тоже не всегда существенно

то же самое, возможно, справедливо для +AggressiveOpts
0
TheShade #
Извините, но вы сейчас чушь сказали. И -client, и -server включают компиляцию после интерпретации байт-кода. Но -server включает в себя более агрессивные оптимизации, поэтому как раз для однократного запуска -server будет медленнее -client. А вот дальше, когда код хорошо соптимизируется серверным компилятором, он будет быстрее клиентского. И поэтому в случае продолжительной работы с IDE (а не просто запустили/закрыли) серверный компилятор будет давать лучшую производительность.

То, что написано в прошлом комменте — это результаты после того, как код был скомпилирован. Для учёта накладных расходов на компиляцию в Dacapo сделан специальный ключик -converge, который делает несколько итераций, пока результаты не начнут укладываться в некоторое значение отклонения. Краем глаза наблюдал, что она сделала по 10 итераций, пока всё не устаканилось.
0
dea #
Согласен, правда я не говорил, что -client JIT не использует. Посмотрел сейчас — client сразу вызывает JIT по загрузке класса, а -server интерпретирует пока не собрал достаточно данных от профайлера.

про -converge тоже убедили
0
TheShade #
И всё-таки -client ждёт, пока метод не станет горячим, и только потом отдаёт его компилятору. «Горячесть» метода определяется по количеству вызовов / переходов по обратным дугам и в HotSpot'е контролируется опцией -XX:CompileThreshold. Попробуйте собрать два лога с +XX:+PrintCompilation: один с -XX:CompileThreshold=1, другой со значением по-умолчанию — сразу увидите разницу.
0
gadub #
performance.netbeans.org/howto/jvmswitches/
тут написано, как настраивать jvm для netbeans, но и для eclipse советы тоже пригодятся
0
u_story #
Там написано — «The switches discussed on this page are available on Sun Microsystems J2SE 1.5.0 — users of other JVM implementations may need to remove these switches in order to run NetBeans. ».
0
gadub #
и что?
0
u_story #
Автор в статье использует 1.6.0_14.
0
gadub #
там же не голая строчка параметров дана, а объяснено, что, куда и при каких обстоятельствах совать. в 6 большинство параметров сохранились
0
nukie #
Кстати о бобах. Их неспешность по сравнению с Eclipse заставляет класифицировать реакцию Eclipse как realtime )
–1
gadub #
вы, наверно, про windows говорите
а под линуксом ui в nb реагирует гораздо быстрее еклипсовского. у меня, по крайней мере, если включить родной явовский облик виджетов. SWT под линуксом очень нетороплив
0
nukie #
Да, вы совершенно правы. Я работаю в Windows.
0
gadub #
netbeans под виндой, вроде, пытается отрисовывать нативные виджеты своими средствами, и делает это медленно. можно попробовать поискать ключик, который переключает на родную тему metal. пошустрее будет работать
0
nukie #
Спасибо, попробую. Хотя метал немного «трешово» выглядит )
+1
dborovikov #
Добавил в качестве параметров сборщика мусора вот это:

-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC

Вроде полет нормальный=)
0
u_story #
Долго уже используешь или только что добавил?
0
dborovikov #
Можно сказать только что, точнее утром. А что, уже были какие-то проблемы с этим G1?
0
u_story #
я не видел, просто написано что он пока экспериментальный :)
0
metakey #
Лучше всего себя вела IBM-овская JVM, я ее выдирал из дистрибутива WSAD и подставлял при помощи .ini-файла. Полагаю, сейчас можно взять где-то здесь www.ibm.com/developerworks/java/jdk/eclipse/index.html
0
DenisO #
Были бы там еще 64 бита
НЛО прилетело и опубликовало эту надпись здесь
+1
DenisO #
Не вижу смысла в этом.

Но даже если все так — eclipse очень легко перенастраивается. Window->Preferencies->Editors и т.д.
НЛО прилетело и опубликовало эту надпись здесь
0
Treg #
Может кто-нибудь знает как в eclipse настроить word-jumping, всмысле, когда нажимаешь ctrl+стрелка? В отличие от других редакторов, эклипс за слова считает и скобки и знаки препинания от чего навигация по коду существенно замедляется…
+4
joedm #
Автор, простите, но от меня минус.
Вы правильно указали, что не стоит ставить Eclipse из репозитария и гонять его на чём-то, отличном от Sun's JDK. Но далее:
1. Eclipse по-умолчанию использует 128m не оперативки, а Java heap. А это разные вещи.
2. Зачем PermGen выставили в 512m? 128m достаточно, 256m — более, чем.
3. Alternatives для установки надо было всё же осилить, т.к. потом могут быть проблемы, если вдруг понадобится другая версия JVM рядом.
4. Собственно, Eclipse Вы так и не ускорили :-) Так, чуть-чуть поигрались с JVM :-)

Теперь поделюсь собственным опытом:
0. Не понимаю, чем вызваны такие тормоза Eclipse? Ну я понимаю, когда первый раз Code Assist запускается: классы там грузит, кеши обноалчет и т.д., но так, чтобы каждый раз «как из инета»… такое я наблюдал только в 2003-м году на машине с 256M оперативки. :-)
1. «Новый» GC из 14-й ревизии не даёт ровным счётом ничего (по крайней мере на двуядернике).
2. Не пытайтесь давать хипа с большой разницей в макс-мин, особенно чересчур много (от гигабайта). Иначе будет приходить GC и тормозить вашу работу вплоть до матюков с вашей стороны :-) Можно, конечно, настроить его так, чтобы он приходил часто, но понемногу, но для Eclipse это неоправдано.
3. Про -server тут уже сказали. Добавлю лишь, эта опция кушает больше (именно) оперативки. Кстати, в 64-bit JVM используется серверная VM по-умолчанию.
Кстати-2, никто не замечал падения 64-bit JVM при компиляции в Eclipse? Стабильно падает при компиляции большого workspace (20+ проектов). Приходится отключать JIT, а это как раз тормоза. Наблюдается как в Ubuntu 8.04 x64_64, так и в MacOSX 10.5.7 Java6 x86_64.
0
joedm #
Следует читать: «0. Не понимаю, чем *у Вас*» и далее по тексту. :-)
0
uranik #
Автор, признайтесь, статья скорее теоретическая, на практике изменение настроек не привело ни к чему, заметному для глаза. (попробовал на windows xp + eclipse galileo)
0
DenisO #
Зачет :))))
0
DenisO #
Если серьезно — вам неудастся почувствовать эффект, потому как у вас изначально был SE, а не Open JDK.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.