I use CrashPlan for my online backup, & it’s great: reasonably priced, secure, easy to use. But there’s one problem. For better or worse, CrashPlan is a Java app, & one of the problems with Java apps is that they are greedy pigs when it comes to RAM usage. I’ve often noticed that Java was using close to 400 MB of RAM, even when nothing is happening (to be precise, when CrashPlan is just hanging out & not actually backing anything up).

Now, you can schedule CrashPlan to actually back up at certain times during the day, so I did that. CrashPlan only backs up from 5 p.m. to 9 a.m., but even so, I was still seeing the java process running constantly, and a steady growth of RAM usage over time.

Why? Well, it turns out that the CrashPlan service is running constantly, even if you’re only actually backing up between certain times (this is so other machines & people can back up to you—it’s one of the many locations to which you can backup using CrashPlan). But I don’t need it to run constantly. When I say I want it off, I want it off. And then I want it back on to run when I want it to back my stuff up.

Here’s how to fix that—and keep its Java from being a horrifically greedy pig (Java will always be a greedy pig; this keeps it somewhat under control, albeit with a sledgehammer, as you’ll see).

Table of Contents

  1. Turn off CrashPlan every day at 9 a.m.
  2. Turn on CrashPlan every day at 5 p.m.
  3. Make sure Java doesn’t go hog wild

Turn off CrashPlan every day at 9 a.m.

Create a file in ~/bin/cronjobs titled crashplanOFF.sh & put the following in it:

#!/bin/bash

# Turn OFF CrashPlan from 9 a.m.–5 p.m.
# Based on http://hints.macworld.com/article.php?story=20110124224322791

launchctl stop com.crashplan.engine
launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist

Save the file & make sure it’s executable:

$ chmod 755 ~/bin/cronjobs/crashplanOFF.sh

That turns off CrashPlan, but it has to be run manually. Let’s automate the process so it runs every day at 9 a.m.

As root, create a file1 in /Library/LaunchDaemons2 titled com.granneman.crashplanOFF.plist3 & put the following in it (replace granneman with your last name & <username> with your home folder’s name):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.granneman.crashplanOFF</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/<username>/bin/cronjobs/crashplanOFF.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
</dict>
</plist>

Save the file & change ownership:

$ sudo chown root:wheel /Library/LaunchDaemons/com.<lastname>.crashplanOFF.plist

Now load the plist so it’s active:

$ sudo launchctl load /Library/LaunchDaemons/com.granneman.crashplanOFF.plist

OK, you’re now turning off CrashPlan every day at 9 a.m. Now let’s make sure it starts running every day at 5 p.m.

Turn on CrashPlan every day at 5 p.m.

This is very similar to what we just did.

Create a file in ~/bin/cronjobs titled crashplanON.sh & put the following in it:

#!/bin/bash

# Turn ON CrashPlan from 5 p.m.–9 a.m.
# Based on http://hints.macworld.com/article.php?story=20110124224322791

sudo launchctl load /Library/LaunchDaemons/com.crashplan.engine.plist
sudo launchctl start com.crashplan.engine

Save the file & make sure it’s executable:

$ chmod 755 ~/bin/cronjobs/crashplanON.sh

That turns on CrashPlan, but it has to be run manually. Let’s automate the process so it runs every day at 5 p.m.

As root, create a file in /Library/LaunchDaemons titled com.granneman.crashplanON.plist4 & put the following in it (replace granneman with your last name & <username> with your home folder’s name):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.granneman.crashplanON</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/<username>/bin/cronjobs/crashplanON.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>17</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
</dict>
</plist>

Save the file & change ownership:

$ sudo chown root:wheel /Library/LaunchDaemons/com.<lastname>.crashplanON.plist

Now load the plist so it’s active:

$ sudo launchctl load /Library/LaunchDaemons/com.granneman.crashplanON.plist

OK, you’re now turning on CrashPlan every day at 5 p.m.

We’re not done.

Make sure Java doesn’t go hog wild

For months now the same series of events has been occurring: I would look at iStat Menus & notice that Java was eating up a bunch of RAM, so I would manually kill the java process.

$ sudo killall java

Java would die & then immediately restart, and soon enough (I’m talking often within a half hour), the java process would be back about 200 MB of RAM, & often well above that.

Limiting CrashPlan to running from 5 p.m. to 9 a.m. will help this problem quite a bit, but when it is running, Java is going to start grabbing RAM like a starving man at a banquet. To keep Java within limits, I did the following.

Create a file named kill_java_mem.sh in ~/bin/cronjobs & put the following in it:

#!/bin/bash

# Figure out how much RAM Java is using
# Uses the RSS column of ps (#6)
# RSS = the real memory (resident set) size of the process (in 1024 byte units)
javamem="$(ps aux | grep java | grep root | awk -F' ' '{print $6}')"

# Get Java’s PID (2nd column of ps)
javapid="$(ps aux | grep java | grep root | awk -F' ' '{print $2}')"

# If Java is using over 200 MB of RAM, kill the process
if [ $javamem gt 204800 ]
then
  kill $javapid
fi

What’s this do? The comments should make it clear, but it figures out how much RAM the java process is using. If it’s using over 200 MB of RAM, the script kills java. Java will immediately start up again, & I’ve never noticed a negative consequence of killing it, so I’m fine with it.

Save the file & make it executable:

$ chmod 755 ~/bin/kill_java_mem.sh

As root, create a file in /Library/LaunchDaemons titled com.granneman.killJavaMem.plist5 & put the following in it (replace granneman with your last name & <username> with your home folder’s name):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.granneman.killJavaMem</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/<username>/bin/cronjobs/kill_java_mem.sh</string>
    </array>
    <key>StartInterval</key>
    <integer>600</integer>
</dict>
</plist>

This will run the script every 10 minutes & help to keep Java’s memory usage under control.

I really wish CrashPlan wasn’t a Java app & didn’t require this much care & feeding, but now that I have these scripts & jobs in place, things should go a lot more smoothly.

  1. If you don’t know how to do that (with vim, for instance), you can also use a text editor like BBEdit & then save the file in that location. BBEdit will prompt you for your Admin password. ↩

  2. Note that’s the system Library folder in /, not your personal one in ~/. ↩

  3. Obviously, replace granneman with your last name. Unless your last name is Granneman. In which case, why don’t I know you?! ↩

  4. Notice the granneman in the file name & act accordingly! ↩

  5. granneman—change it. ↩