Подтвердить что ты не робот

Высокое использование ЦП в Eclipse при простоях

На моей многоядерной машине Eclipse использует от 100 до 250% мощности ЦП, даже при холостом ходу на новой простой установке и пустой рабочей области. Когда вы действительно делаете что-то, оно становится медленным и не реагирующим.

Я попытался установить настройки памяти, как предлагается здесь: Eclipse использует 100% -ный CPU случайно. Это не помогло. Я также пробовал разные версии Java, а именно OpenJDK и Oracle Java 7, а также версии Eclipse Juno и Indigo. Я на Ubuntu 12.04 LTS.

В качестве другой, возможно, несвязанной проблемы, когда я закрываю Eclipse, процесс Java остается открытым с более чем 200% использования процессора и должен быть убит вручную.

4b9b3361

Ответ 1

У меня была такая же проблема сегодня, и она оказалась потоком индексирования, который занимал центральный процессор. Недавно я добавил в проект немало файлов и забыл об этом. Я понимаю, что вряд ли кто-нибудь еще столкнется с этой проблемой, но может быть полезно опубликовать, как я ее исследовал.

Я запускаю Ubuntu 12.10 с помощью STS на основе eclipse Juno.

  • Запустите eclipse из командной строки и перенаправьте вывод в файл, чтобы мы могли получить дамп потока
  • Позвольте ему немного подойти, а затем получите список использования процессора для каждого потока: ps -mo 'pid lwp stime time pcpu' -C java. Здесь образец результата, который идентифицировал мой голодный поток процессора:

    PID LWP STIME TIME% CPU

    6974 - 07:42 00:15:51 133

    7067 07:42 00:09:49 86.1

  • Преобразуйте идентификатор потока (в моем случае 7067) в шестнадцатеричный 0x1b9b (например, в командной строке, используя: printf "0x% x\n" 7067)

  • Сделайте дамп потока java-процесса, используя kill -3: kill -3 6974. Выход сохраняется в файле, который вы перенаправили stdout при запуске eclipse

  • Откройте файл и найдите шестнадцатеричный идентификатор потока:

    "Link Indexer Delayed Write-10" prio = 10 tid = 0x00007f66b801a800 nid = 0x1b9b runnable [0x00007f66a9e46000]

    java.lang.Thread.State: RUNNABLE

    в com.ibm.etools.references.internal.bplustree.db.ExtentManager $WriteBack.r

Ответ 2

У меня была эта проблема с плагинами, но никогда не с Eclipse.

Вы можете попробовать отладить его, перейдя в Help > About Eclipse > Installation details и отключив плагины один за другим.

Ответ 3

Я видел такое поведение только тогда, когда сборщик мусора сошел с ума, потому что выделенная память действительно достигла заданных максимальных пределов памяти виртуальной машины. Если у вас большая установка Eclipse, ваш первый шаг всегда должен быть увеличить параметры памяти в eclipse.ini.

Также активируйте Окно → Настройки → Общие → Показать состояние кучи. Он покажет вам, сколько памяти Eclipse использует в настоящее время (в строке состояния). Если это доходит до допустимого максимума и больше не падает (т.е. Сборщик мусора не может очистить неиспользуемые объекты), то это точно указывает на то, что я описал выше.

Изменить: также было бы хорошо знать, какой пакет Eclipse вы используете, поскольку по умолчанию у них есть разные плагины. Классик, моделирование, разработчики Java EE,...?

Ответ 4

Многопользовательский мусорный сборщик мусора - мусор. add -XX: опция -UseLoopPredicate для командной строки java. См. ошибка https://bugzilla.redhat.com/show_bug.cgi?id=882968

Ответ 5

Столкнулась с той же проблемой, Пропустив следующий аргумент VM в eclipse, и это сработало для меня.

-Xmx1300m -XX: PermSize = 256m -XX: MaxPermSize = 256m