The memory usage of Eclipse 3.4 is through the roof to the point where it's becoming an issue.
I have a simple BlackBerry project loaded and the usage skyrockets to nearly 400 MB, sometimes higher. Is there something that can be done to bring it down?
Eclipse 3.4 can consume a lot more memory than the previous versions, courtesy the spellchecker plug-in.
You can switch off the plug-in by going to Window -> Preferences -> General -> Editors -> Text Editors -> Spelling, and unchecking the box title 'Enable spell checking'.
Of course, the tips offered to use larger heap sizes and better garbage collectors would do you good as well.
Checking General -> Show heap status will enable this
in the bottom bar.
This way you can manually run the garbage collector whenever you want by clicking on the trash can. It's not a fix, more like a workaround, but it helped reduce massively my RAM / CPU usage.
Remove +UseG1GC option from eclipse.ini. I've read from here that It is only used for araound 6GB heap memory.
In Eclipse Luna 4.4.1
Was trying to cut my memory usage in Eclipse. I managed to shave mine from 600mb to 300mb. I did the following:
Turned off the plugins activated on startup that I wasn't using. Windows > Preferences > General > Startup and Shutdown
Closed projects I wasn't working on at the time.
Found the hints/tips here : http://blog.elijaa.org/2010/09/20/tricks-to-speed-up-eclipse-php-helios-pdt-2-2/
Modern versions of Eclipse do need quite a bit of RAM to do their thing. But should still run pretty fast on any modern machine.
Assuming you have enough physical memory (2GB is fine unless you have lots of other processes running, or you're using RAD), see this article on Eclipse's memory usage for some tips on tweaking the settings. The two most common culprits are Xmx and/or MaxPermSize being set too low (Xmx defaults to 256M and MaxPermSize defaults to 64M).
You modify the values by passing command line arguments or tweaking the eclipse.ini in the Eclipse install location.
You should end up with something like this:
...
-vmargs
-Xms128m
-Xmx1024m
-XX:MaxPermSize=128m
While you probably could tinker with the configuration, removing various plugins etc, it's likely to be more cost effective to buy more memory. How much do you currently have? I would consider a developer machine with less than 2GB of memory to be under spec, and I suspect many people would double that...
My Eclipse is taking over 800MB resident, and 2GB virtual (part of it swapped out perhaps).
Java can be a hog, it's giving Java bad press all the time.
However, there is a little something that many people don't know: the incremental garbage collector. -Xincgc
The side effect is that it hands memory back to the system from time to time.
By default Java just takes and takes, and when it doesn't need memory anymore, it keeps it for itself.
The incgc is a different strategy where it becomes more reasonable to assume that memory can be handed back the system without running into trouble.
This can however affect performance.
There are many garbage collection settings. You can also have multiple threads handle GC. The parallel GC does that. Not sure if that one hands memory back, don't think so.
If 400 Mb of RAM is a big issue for you, you might want to try another IDE. Eclipse stores a lot of state information, some or most of which you don't actually need. That's a design choice.
Right now, I have the same project open in both Eclipse and QtCreator: after a clean rebuild, Eclipse uses 156 Mb RAM, Qt Creator is happy with 66 Mb.
You can try the 64bit version of Eclipse with the 64bit version of JDK on Windows 7. Those both caused some odd issues with the 3rd party Framework I have to work with. The 32-bit of JRockit (free now) from Oracle seems to be faster and be a little better on memory. This is my Eclipse.ini settings:
This is my eclipse inn
-startup
plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222
-nosplash
org.eclipse.platform
--launcher.XXPermSize
512m
--launcher.XXMaxPermSize
512m
--launcher.defaultAction
openFile
-vm
C:/Program Files (x86)/Java/jrockit-jdk1.6.0_31-R28.2.3-4.1.0/jre/bin
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Xquickstart
-XX:+AggressiveHeap
-XX:+AggressiveOpts
-XX:+UseParallelOldGC
-XX:ParallelGCThreads=2
-XX:ThreadPriorityPolicy=1
-Xverify:none
-Xms1100m
-Xmx1100m
I switched to the 32 bit JRockit JDK which seems a little faster for Eclipse. I turn off and don't install more than I need. For each separate type of app development (Android, J2EE, just Spring, ...) I have different Eclipse installations. Hard drive space is cheap. Then I can have just the plugins I need for each one. I would never want all the Android tools loading if I wasn't using them. STS is also good for just the Spring stuff and I have one just for OpenShift Cloud work.
Try disabling your eclipse plugins. Eclipse was hogging half of my of my memory when I had the saros plugin open.
Related
I use ubuntu16.04 in VMware for learning Hadoop. The eclipse is Eclipse IDE for Java Developers at 2020.03 for linux_64.
And when use eclipse to write some java code, the IDE usually exits by itself without any error. And the eclipse is too slow when I use it. I guess that whether the memory is not enough for using IDE. But I found the memory is free when I check it. I allocated 2G of memory for ubuntu16.04.
And I search for this problem on web. I found many people believe the problem is eclipse caused. So they come up with a way to edit eclipse.ini.
-Dorg.eclipse.swt.browser.DefaultType=mozilla
Add this command to the last line of eclipse.ini.
Unfortunately, it doesn't work. So Do u know why? Should I allocate more memory for VMware?
Recently I bought a good computer with processor i5 3570k and 16GB of RAM, I wonder if there's a way to increase my Eclipse and Glassfish speed, to they can work together to startup and do the hot deploy while I'm developing my applications.
This is my eclipse.ini
-nosplash
-vmargs
-Xincgc
-Xss500k
-Dosgi.requiredJavaVersion=1.6
-Xms512m
-Xmx1024m
-XX:NewSize=8m
-XX:PermSize=1024m
-XX:MaxPermSize=1024m
-XX:MaxPermHeapExpansion=10m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseParNewGC
-XX:+CMSConcurrentMTEnabled
-XX:ConcGCThreads=2
-XX:ParallelGCThreads=2
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=5
-XX:GCTimeRatio=49
-XX:MaxGCPauseMillis=20
-XX:GCPauseIntervalMillis=1000
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSClassUnloadingEnabled
-XX:+DoEscapeAnalysis
-XX:+UseCompressedOops
-XX:+AggressiveOpts
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Any recommendations about it ?
Eclipse and Glassfish are just containers, their tuning depends heavily on how you use them (number of projects in eclipse, number of apps in glassfish, ...). However, I see some weird JVM options in your eclipse.ini. Here are the ones I would simply remove :
-Xincgc means -XX:+UseConcMarkSweepGC which is a low pause GC that implies a high overhead compared to parallel collectors. I would switch to parallel collectors.
-XX:NewSize=8m means that the young generation size is 8MB, this is really small and against the weak generational hypothesis. Remove this option and let the JVM adjust heap size depending on how you use the application.
-XX:PermSize=1024m is equal to MaxPermSize. Setting min=max is a nonsense. Remove the minimum size and let the JVM manage permanent generation size.
-XX:+UseConcMarkSweepGC, cf 1.
-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSConcurrentMTEnabled -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:ConcGCThreads=2 -XX:CMSIncrementalDutyCycle=5 -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses are CMS related. Cf 1, I would switch to parallel collectors so you should get rid of those options.
-XX:+UseParNewGC -XX:ParallelGCThreads=2 means that you were giving 2 threads for a parallel collector in the young generation (8 MB). This won't really do anything.
-XX:GCTimeRatio=49 -XX:MaxGCPauseMillis=20 -XX:GCPauseIntervalMillis=1000 here you are saying "I want my GC to take les than 49% of my time, with a pause of maximum 20ms and at least 1 second between each pause". You are asking for very short GC that will happen very often. Probably not what you want.
You may notice that these are almost all your JVM options. This is correct :)
Try this configuration and let us know if it solved your problem :
-nosplash
-vmargs
-Xss500k
-Dosgi.requiredJavaVersion=1.6
-Xms128m
-Xmx1024m
-XX:MaxPermSize=1024m
-XX:+UseParallelGC
-XX:+UseParallelOldGC
-XX:+DoEscapeAnalysis
-XX:+UseCompressedOops
-XX:+AggressiveOpts
-Xloggc:gc.log
-XX:+PrintGCDetails
Sources :
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
http://jvm-options.tech.xebia.fr/
Do you have an SSD? If not buying one will really improve your performance experience because development means a lot of IO.
If you want to speed up your development process, i think you are looking at the wrong place.
The performance of your system should be more than enough. Maybe you could raise the -Xmx a bit, depending on your application. Maybe an ssd would boost the performance too.
I for myself, could speed up my development with jrebel(http://zeroturnaround.com/software/jrebel/). This is a tool that allow you hot replacement of nearly any part of your application. So you do not have to redeploy the whole application every time. I know it costs money, but it paid of quickly. Maybe there are also some free alternatives i don't know yet.
win/linux/mac: you can put JDK into read-only RAM disk and run it from there
linux: you could use anything-sync-daemon to keep both Eclipse and Glassfish (and possibly maven local repository ".m2") in RAM and synchronize it into HDD/SSD periodically
I also recommend reading this:
Tip 1 : Always run the latest JDK and Eclipse.
Tip 2 : Tune Eclipse Preferences
Tip 3 : Keep your JDK on a RAM Disk
Tip 4 : Tweak your eclipse.ini
Tip 5: Get your anti-virus outta here
Tip 6: Keep SVN and GIT out of Eclipse
Tip 7: Use your keyboard
at http://www.nicolasbize.com/blog/7-tips-to-speed-up-eclipse/
I am using the latest eclipse version (Indigo) on a machine: CPU: Intel Core i5 2.4 GHz, 8 GB RAM, 64-bit Windows, and eclipse keeps freezing very frequently. I increased all the memory things (permgen ...), but it did not help. When it stops responding a window pops out with the following data:
Java was started but returned exit code= -805306369
-XX:PermSize=256M
-XX:MaxPermSize = 512M
-Xms512m
-Xmx1024m
...
If you need more input, please feel free to ask :)
Any help would be very appreciated. Thank you, in advance.
Looking at your 64 bit Windows; I remembered this thread. See if the solution there resolves it
https://superuser.com/questions/314015/eclipse-crashed
Also as my comments above suggests; a -clean start to eclipse is a good idea, as you have good enough RAM to get it cleaned faster. Slower machines will struggle cleaning every time you start eclipse.
Run eclipse with -clearPersistedState from terminal/command prompt
I am using a 32bit WinXP with no upgrade in sight, is there a way to limit how much memory Eclipse allocates throughout the day? I am also running Weblogic 10 server in debug mode inside eclipse. After a few hours I have an 700mb STS.exe (eclipse) and 400mb java.exe (server). Is there at least a way to force a GC on eclipse?
Here are the settings i surrently use, which seem to me are not being observed.
-vm
C:\bea\jdk160_05\bin\javaw.exe
-showsplash
--launcher.XXMaxPermSize
128M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m -Xmx512m
-Dsun.lang.ClassLoader.allowArraySyntax=true
EDIT: here's the monster of a project: Eclipse and Firefox 4.
is there a way to limit how much memory Eclipse allocates throughout the day?
The values of -Xmx and -XX:MaxPermSize place an upper bound on the memory that the JVM will use.
Is there at least a way to force a GC on eclipse?
AFAIK, no. Even if there was, it probably wouldn't help. The JVM is unlikely to give the memory back to the operating system.
Here are the settings i currently use, which seem to me are not being observed.
Based on what you've said (memory usage 700Mb for eclipse.exe), I'd say the settings ARE being observed.
What can you do to get Eclipse to use less memory?
Trim the values of -Xmx and -XX:MaxPermSize. However, if you do this too much you are liable to make Eclipse sluggish ('cos it has to GC more frequently) and ultimately flakey ('cos it will run out of memory and things will start failing with OOMEs)
Get rid of superfluous plugins.
Switch to a "smaller" Eclipse (e.g. the "Classic" distro) ... though you'll lose some of the J2EE support that you are probably using.
Close projects.
Close files.
Restart Eclipse more often.
But the best solution is to upgrade your platform:
Buy some more memory for your PC / laptop. You can probably max it out for a couple of hundred dollars. It is worth it.
Switch the OS to Linux. In my experience, Linux is a much better platform for doing Java software development than Windows XP. It seems to do a much better job in terms of both memory and file system management. The performance difference on identical hardware is significant.
You can always set up your machine to dual boot, so that you can still run XP for other things.
The 700MB of OS level process usuage is consistent with your memory settings. Take 512m for heap + 128m for permgen space + a bit of overhead for the JVM itself.
You cannot force GC. If memory was releasable, JVM would release it. Note that you cannot simply look at OS level process usage as that represents the point where the JVM memory usage peaked. JVM never releases heap or permgen space once it expands to a certain size. It is simply too expensive and not really necessary. The allocated space is in virtual address space of the JVM process. It doesn't represent actual physical memory usage. As physical memory gets tight, the OS will agressively swap out to disk memory pages that haven't been used recently.
So... You need specialized memory analysis tools to get accurate representation of Eclipse memory usage.
If you are seeing a lot of disk activity when there shouldn't be any, the OS may be indeed out of physical memory and doing a lot of swapping. Try closing a few projects or restarting Eclipse. It only takes one plugin with a memory leak to consume all of your available memory.
I'm assuming that you are running BEA JRockit judging by the path to javaw.exe. Note that the -X... options are JVM-specific, so they may not work the same way for JRockit as in Sun's JVM. This link seems to indicate that you should be using
... -Xms:40m -Xmx:512m ...
But setting a heap size limit will only cause Eclipse to fail once it reaches the limit, so you won't solve the real problem. Forcing a GC usually doesn't help; any sane VM will GC periodically or when needed.
Having a 700Mb Eclipse sounds like your Eclipse is either processing large amounts of data, or it is leaking memory. JRockit seems to have a memory leak detector which may be able to give you a hint of where the problem lies.
The ini file memory settings won't help for the Virtual machine. Change VM arguments, as here
Eclipse is very thirsty. Limiting it is most likely to crash it. You really need a new computer.
When i work with NetBeans 6.9 for PHP the javaw.exe is occupying more then 50% of CPU and about 450mb ram (ram is not really the problem) but CPU tend to overheat.
I had jdk6.5 for 64bit sys and now updated to latest jdk6.21 but it is the same, the CPU is always near 100%
is there a solution to this high requirements of javaw.exe?
OS: Win7 64bit
UPDATE:
I installed the NetBeans 6.7.1 the one that worked EXCELLENT to compare with 6.9.
so:
6.7.1 less memory usage by javaw.exe then 6.9 but cpu still in use > 50% nonstop
then:
I installed the JDK6_21 32bit cause i had 64bit and in the config (netbeans.conf) file set the path of the 32bit JDK.
6.9 less memory CPU still to high
6.7.1 less memory NO CPU usage when idle
SO im gonna downgrade to the 6.7.1 because it works for me and i dont really need the 6.9 cause i dont really use the new features that offers.
btw. 6.8 was crashing with no reason, so that option is out.
You could configure Netbeans to run java.exe instead of javaw.exe, and see if the behavior is still the same.
If it's the same, this is clearly a Netbeans problem, so I would suggest reporting this problem to Netbeans, since this is the way bugs get usually fixed :).
One thing you should consider doing on Netbeans (and Eclipse... and $insertOtherIDE) is to turn off automatic project indexing, compile on save, and other things that cause lots of work to happen in the background without your prompting.
In Netbeans 6.9, external scanning/indexing tends to be the biggest culprit when dealing with projects of considerable size. Try disabling it by (and these instructions are for the Mac, I assume they are similar on Windows)
Go to Preferences
Click on Miscellaneous
Click on the Files Tab
Deselect "Enable auto-scanning of sources"
After this you can force NB to re-scan by clicking Source->Scan For External Changes in the menu (might be Mac specific, again).
See if that helps you out at all...
I had the same problem (Win7 64bit). Everything was working, but suddenly (I think after refactoring some stuff) javaw.exe was constantly using the cpu.
After clearing the netbeans cache, everything was working again (delete the contents of the cache folder and restart Netbeans).
%UserProfile%\.netbeans\6.9\var\cache\
I had to do this before after getting strange errors in Netbeans and most of the time it solved the problems. I think sometimes it just gets out of sync.