If you have noticed CrashPlan is using too much memory on your 64 bit Mac, one solution might be to run its server process in 32 bit mode. I’ve tried this, and so far it hasn’t caused any problems, and definitely seems to keep memory usage lower.
This requires a bit of hacking, but its not too terrible.
Start by opening your ‘Terminal’ program. You can find it in /Applications/Utilities/Terminal
At the command prompt, type this (all on one line):
sudo nano /Library/LaunchDaemons/com.crashplan.engine.plist
Find these two lines:
<string>-Dapp=CrashPlanService</string>
<string>-Xmn10m</string>
And insert a line so that it now looks like this:
<string>-Dapp=CrashPlanService</string>
<string>-d32</string>
<string>-Xmn10m</string>
Optional: A little further down the file, you will see this line:
<string>-Xmx512m</string>
You can change that line to be:
<string>-Xmx150m</string>
This will restrict CrashPlan to AT MOST 150 mb of ram. According to CrashPlan tech support this is perfectly safe (and you could go even lower if aren’t backing up 120gb like I am), but you might need to monitor CrashPlan for out-of-memory errors and such. If you see errors, just change that 150 back to a 512, and everything should be fine.
Now save the file and exit by pressing “Control-O”, Enter, then “Control-X”.
You are almost done.
The last step is to reload and relaunch CrashPlan with these commands:
sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
sudo launchctl load /Library/LaunchDaemons/com.crashplan.engine.plist
Now CrashPlan should be using much less memory.
Update: I neglected to point out HOW to check how much memory Crashplan is using. You can use Activity Monitor to do this, you can find it at /Applications/Utilities/Activity Monitor. Look for a process called ‘java’, started by ‘root’. There might be more than one ‘java’, so you might have to do some digging to figure out which one is Crashplan. I can’t find a specific way in Activity Monitor to check this, but one hint is to close any applications you have running and see if other ‘java’ instances go away. In my case, I normally just have the ‘Crashplan’ java running.
Thanks. Very timely post.
Define “too much memory”? I was at over 650MB when I started googling and found this.
Trying this now.
Feedback: Your instructions are very clear and pretty much noob ready, but you don’t hint that the bloated process in question is just going to appear in Activity Monitor as ‘java’ and won’t be called ‘Crashplan’ or anything easily identifiable.
In my case, Crashplan was using 350 mb of memory. So far after a few days of 32 bit mode, its holding steady at 245 mb or so and hasn’t gone up to much.
You might also find this thread useful: https://crashplan.zendesk.com/entries/116068
Good point re: ‘java’ vs. ‘crashplan’, I’ll update the post.
Worked well for me. Thanks a lot for distilling down the support thread this all comes from.
Thank you thank you thank you! This helped me so much on my dinosaur mac.
Just like the others said above the tutorial was easy to follow. Thanks again, no more beach ball from hell
P. S. By the way, I was blaming Firefox all this time for the memory issues. Java/Crash Plan was apparently using almost 600 .. sometimes 700 if i remember. Thats pretty awful way to design a product and misleading too. Crash plan should have come with a beachball warning of some kind. Seriously .. i’m a bit pissed off now, i have been dealing with a very slow computer for over a year now.
Pingback: Time Machine vs. CrashPlan for Backups : Ben Gross, PhD
Where would the ‘out of memory’ errors display?
Thanks for this post. Just got a new iMac i7 and have been watching all the new software like a hawk. I was also thinking it was firefox until I found your post. I’ll try the solution you suggest. Thanks also for letting us know it has Crashplan’s blessing.
Hi Andy, the out of memory errors would appear in one of the crashplan log files. You can see them by running the “Console” application (See Applications/Utilities), then look under /Library/Logs/CrashPlan. In one of the log files there, you will see out of memory errors.
Generally you can tell the OOM errors are happening because CrashPlan stops backing up your data.
You can determine the correct Java process using Activity Monitor. Select a Java process and press the “Sample Process” button. In the text file that is displayed, if you see a thread named “Java: BWQ-Backup::-0” (there are several similar threads with different numeric suffixes) then that’s the Crashplan process.
Thank you so much for this!
I’ve been wondering what that mysterious Java process eating up memory has been now for months. Every so often I google around but to no avail, until today when I found this post!
Problem solved (or at least understood…)
Thanks!
FYI: I look for this process using the command line: ps aux | grep CrashPlan
Looks like this remains a problem with CrashPlan at this time (was hitting 650MB+ recently). Switching to 32bit mode and reducing the max RAM usage solves things nicely. Thanks for the info!
Thank you very much for this tips. My inactive memory has been slowly getting filled up until it was fully consumed by the java (I couldn’t really figure which program was doing this until I read your post). Obviously that slowed down computer quite a bit, so I’ve started searching for solutions. Unchecking javas in Java Preferences (as some web sites suggested) did only that I couldn’t launch Crash Plan application. But this way I figured that it must be related to Crash Plan and found your post by searching for “Crash Plan+Java+Lion+Inactive Memory”. Surprisingly enough I couldn’t find anything to resolve the issue on Crash Plan web site: they proudly state “full Lion compatibility”, stupid baffoons! I must admit it was a bit scary to follow your instructions and get into the system files etc. but worked perfectly for me.
Thank you once again!!!
Thank you VERY, VERY much for sharing this.
Best regards
German
P.S. Do you have any idea why it becomes a problem in Lion? I have CrashPlan running since Tiger, it it’s never been a problem… Just curious
Hi, I don’t think it is a Lion vs Tiger or Snow Leopard issue. I think Crashplan takes up more memory when you have many more files. If you have a lot of files, Crashplan will start taking up a ton of ram.
Wow – just wow. I’m not sure what codefortytwo is doing, but if the apps I write in Java for work leaked/consumed this much memory, I’d get a serious talking-to. I just sampled the Java process and it was using 3.4GB of Virtual Memory which was paged-in, leaving me with very little free and a 1.2GB swap file (and accompanying terrible performance). Thanks for the pointer – although I just uninstalled CrashPlan altogether.
In Ubuntu/Debian/Linux the Crashplan config file is located at /usr/local/crashplan/bin/run.conf
You can adjust Xmx to 256 (or 150) as you wish. Notice two entries for the engine and the GUI.