CrashPlan using too much memory on Mac OS X

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.

About admin

A software architect and engineer with a fine arts background. You can connect with him on Google+.
This entry was posted in Tech. Bookmark the permalink.

33 Responses to CrashPlan using too much memory on Mac OS X

  1. Andrew says:

    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.

  2. pardsbane says:

    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.

  3. Mario says:

    Worked well for me. Thanks a lot for distilling down the support thread this all comes from.

  4. Winter says:

    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

  5. Winter says:

    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.

  6. Pingback: Time Machine vs. CrashPlan for Backups : Ben Gross, PhD

  7. Andy says:

    Where would the ‘out of memory’ errors display?

  8. Matt C says:

    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.

  9. pardsbane says:

    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.

  10. Steve Bate says:

    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.

  11. hb says:

    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…)

  12. Matt Scilipoti says:

    Thanks!
    FYI: I look for this process using the command line: ps aux | grep CrashPlan

  13. Endareth says:

    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!

  14. German Yakushkin says:

    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 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 :) Thank you once again!!!

  15. Josh says:

    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.

  16. Jonathan Edwards says:

    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.

  17. Mike Galicki says:

    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.

  18. Dave Parizek says:

    Thanks for the tips but it pisses me off to have to go to so much trouble and Crashplan cannot make it work better on there end. Seems like Mac users should boycott crash plan.

  19. John Kershaw says:

    Never mind memory usage, CrashPlan’s activities have been killing my battery! After much frustration with poor battery life (even with a brand new battery I was only getting 2.5 hours!), so I created a ‘clean’ account and booted into that – whadya know, normal battery life. A bit of sleuthing led me to the catchall ‘java’ process (or rather, 68 processes taking 380Mb) and breaking those down with ‘ps’ showed CrashPlan to be the culprit. I’ve set it to back up only between 1am and 6am – let’s see whether that stops it chewing up battery life.

  20. Bob says:

    Has anyone had CrashPlan mysteriously close (and not reopen) after throttling it down to use only 150mb of RAM with the “-Xmx150m” edit?

    Was hoping I wouldn’t have to change it back to 512 :(

  21. Mauricio says:

    Great post – only it doesn’t seem to work with OS X 10.8 Mountain Lion. Anybody else having any luck?

  22. Josh says:

    When I lowered the ram for Crashplan I definitely have had that problem. I think 150mb might be a bit too small. Crashplan seems to need more ram based on the amount of data you are backing up. If you only have a small or moderate amount of data, try 256 or 384 mb.

  23. R. E. Hand says:

    Worked fine for me in Mountain Lion, with 2 changes:

    • I did not add the -d32 (kept it running 64-bit)
    • Only lowered it to 256m

    When I tried the -d32 and 150m, it kept crashing when it would attempt a backup.

  24. Have you tried using -XX:+UseCompressedOops instead of -d32?

  25. Well I tried it and it still needed 512m. I’ve set it to d32 and 256 and will see if it OOM or not.

  26. Matt M. says:

    Has anyone tried other online cloud backups? Recommendations?

  27. Allen Watson says:

    Just followed the instructions. Java was using 795 MB for me. I found max memory was set to something like 768; not sure why it went above that. But after making suggested changes, java is only using 79 MB! Woopie!

  28. Ben says:

    I switched to Arq (Mac specific) http://www.haystacksoftware.com/arq/ which now supports Amazon Web Services Glacier. My entire Macbook Pro is backed up for $.60/month. And Arq is CPU (and network) friendly!

  29. I’ve tried -d32 and -XX:+UseCompressedOops and lowering the max ram but at the end of the day CrashPlan is just memory hungry. I was told by support that you can reduce the frequency from the default of every 15 min to every 1 hour or more to have it need less resources but even doing that has not allowed me to reduce the max ram below 512mb. Rather frustrating.

  30. Luke says:

    Thanks for this. Finally my Java RAM isn’t hovering above 550MB at all hours of the day.

    Great article.

  31. ilium007 says:

    @Ben – have you looked at how much AWS Glacier will cost to restore your files ??? !!!!! I think you will revert to CrashPlan when you find out !

  32. Rein says:

    It doesn’t seem to work for me :-(.
    When the number is below 512 the app is just crashing after a few seconds.
    I’ve tried with and without the -d32 both crashing.
    Maybe it’s because of Mavericks or java7.

    Anybody got it working?

  33. admin says:

    Rein,

    If its crashing for you, you probably have a really large backup set so CrashPlan is running out of memory trying to figure out which files need to be backed up. If that is the case, your only option is to increase the amount of ram you give CrashPlan, and if necessary, upgrade your laptop’s ram.

    Honestly, its been a long time since I wrote this post, and these days I leave CrashPlan at the default settings because my current Mac has 16 gb of ram.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>