java - roja - Alto uso de CPU en Eclipse cuando está inactivo
luna de sangre (6)
El recolector de basura multi thread de Java es una basura. agregue la opción -XX: -UseLoopPredicate a la línea de comandos de java. Ver, por ejemplo, el error https://bugzilla.redhat.com/show_bug.cgi?id=882968
En mi máquina multinúcleo, Eclipse usa entre 100 y 250% de potencia de la CPU, incluso cuando está inactivo en una nueva instalación simple y un espacio de trabajo vacío. Cuando realmente hace cosas, se vuelve lento y no responde.
He intentado configurar la configuración de memoria como se sugiere aquí: Eclipse usa 100% de CPU al azar . Eso no ayudó. También probé diferentes versiones de Java, a saber, OpenJDK y Oracle Java 7, y las versiones de Eclipse Juno e Indigo. Estoy en Ubuntu 12.04 LTS.
Como otro problema quizás no relacionado cuando cierro Eclipse, el proceso de Java aún permanece abierto con más del 200% de uso de la CPU y necesita ser eliminado manualmente.
Estaba enfrentando el mismo problema, Pasé después de VM Argument en eclipse y funcionó bien para mí.
-Xmx1300m -XX: PermSize = 256m -XX: MaxPermSize = 256m
Estaba teniendo el mismo problema hoy, y resultó ser un hilo de indexación que estaba ocupando la CPU. Recientemente agregué bastantes archivos a un proyecto y me olvidé de él. Me doy cuenta de que no es probable que alguien más tenga este problema, pero podría ser útil publicar cómo lo investigué.
Estoy ejecutando Ubuntu 12.10 con STS basado en el eclipse Juno.
- Comience eclipse desde la línea de comando y redirija la salida a un archivo para que podamos obtener un volcado de hilo
Permita que se conforme un poco, luego obtenga una lista del uso de la CPU para cada hilo: ps -mo ''pid lwp stime time pcpu'' -Cjava. Aquí hay una muestra de la salida que identificó mi hilo hambriento de CPU:
PID LWP TIEMPO TIEMPO% CPU
6974 - 07:42 00:15:51 133
7067 07:42 00:09:49 86.1
Convierta el id. Del subproceso (en mi caso 7067) al hex 0x1b9b (p. Ej. En la línea de comando usando: printf "0x% x / n" 7067)
Realice un volcado de subprocesos del proceso de Java con kill -3: kill -3 6974. La salida se guarda en el archivo que redirigió stdout cuando comenzó eclipse
Abra el archivo y busque el ID hexadecimal del hilo:
"Indexador de enlace Escritura diferida-10" prio = 10 tid = 0x00007f66b801a800 nid = 0x1b9b ejecutable [0x00007f66a9e46000]
java.lang.Thread.State: RUNNABLE
en com.ibm.etools.references.internal.bplustree.db.ExtentManager $ WriteBack.r
He visto ese comportamiento solo cuando el recolector de basura se volvió loco porque la memoria asignada realmente alcanzó los límites máximos de memoria configurados de la máquina virtual. Si tiene una instalación grande de Eclipse, su primer paso siempre debería ser aumentar la configuración de memoria en eclipse.ini .
Active también Ventana -> Preferencias -> General -> Mostrar estado del montón . Le mostrará cuánta memoria usa actualmente Eclipse (en la línea de estado). Si eso va hasta el máximo permitido y no cae más (es decir, el recolector de basura no puede limpiar los objetos no utilizados), entonces esa es exactamente la indicación de lo que describí anteriormente.
Editar: También sería bueno saber qué paquete de Eclipse utiliza, ya que contiene diferentes complementos de manera predeterminada. Clásico, Modelado, desarrolladores de Java EE, ...?
La desinstalación de los complementos de mylyn me solucionó el problema y el aumento del rendimiento fue tan drástico que lo publico como respuesta a una pregunta de hace 6 años.
Vaya a Help->About Eclipse->Installation Details->Installed Software
y desinstale todos los complementos que sabe que no está usando. Desinstalé solo los complementos de mylyn y me sorprendió.
Tuve este problema con los complementos, pero nunca con Eclipse.
Puede intentar depurarlo yendo a Help > About Eclipse > Installation details
y deshabilitando los complementos uno por uno.