CrashPlan keeps stopping and starting
In some cases a large file selection (>1TiB or 1 million files) can cause CrashPlan to crash.
This can be noticed by continuous stopping and starting. You may also see the CrashPlan version 2010 application and System Tray icon disappearing in the middle of a backup.
Or the main CrashPlan program will run for about 30 seconds then close down with no error message. After launching the Crashplan GUI, itwill run for a little bit, hang and then finally crash. When the UI is crashing no error message will show up in the Windows event log. CrashPlan log file service.log.0 will show:
java.lang.UnsatisfiedLinkError: Unable to load library 'cpnative64': The specified module could not be found.
When starting and stopping in the CrashPlan application its History tab, you may repeatedly see CrashPlan stopped and started:
In the Windows System Event Viewer you may see this message repeatedly:
Event Type: Information
Event Source: Service Control Manager
Event Category: None
Event ID: 7036
Description: The CrashPlan Backup Service service entered the stopped state.
In one of the CrashPlan service.log.# log files will appear "OutOfMemoryError" messages, like:
ERROR QPub-BackupMgr backup42.service.backup.BackupController] OutOfMemoryError occurred...RESTARTING! message=OutOfMemoryError in BackupQueue!
ERROR QPub-BackupMgr backup42.service.backup.BackupController] OutOfMemoryError occurred...RESTARTING! oomStack=java.lang.OutOfMemoryError: Java heap space
The CrashPlan engine by default is limited to 512MB of main memory. The CrashPlan engine won’t use more memory than that, even if the CrashPlan engine needs more working memory and the computer has memory available. When the CrashPlan engine is running out of memory it crashes.
Allocate more memory to CrashPlan. The configuration file is located at:
- C:\Program Files\CrashPlan\CrashPlanService.ini « Windows
- C:\Users\<username>\AppData\<Local or Roaming>\Programs\CrashPlan\CrashPlanService.ini « Windows with a per user CrashPlan installation
- /library/launchdaemons/com.crashplan.engine.plist « Mac
- /usr/local/crashplan/bin/run.conf « Linux
The "-Xmx" switch sets the maximum amount of memory that CrashPlan can use. CrashPlan will not use that much until it needs it.
As a rule of thumb set about one gigabyte (=1024 MB) RAM for every terabyte in the file selection.
For example, if you're backing up 1 terabyte of data set the "-Xmx" value to 1024 like so: -Xmx1024m. This will increase the amount of memory that CrashPlan can use to 1024MB.
Make sure your computer has enough memory (RAM/SWAP) before you make this change.
- Stop the CrashPlan service. On most Windows computers this is in the „Control Panel > Administrative Tools > Services”
- Open Windows Explorer and browse to C:\Program Files\CrashPlan and double-click the CrashPlanService.ini file
- Look for the following setting: -Xmx512m
- Change "-Xmx512m" to -Xmx1024m
- Save the file
- Start the CrashPlan service
- Launch a terminal window
- Shutdown the CrashPlan daemon:
$ sudo launchctl unload /library/launchdaemons/com.crashplan.engine.plist
You will be asked for your admin password.
- Now edit the plist file using a text editor, for example:
$ sudo nano /library/launchdaemons/com.crashplan.engine.plist
- Find -Xmx512m, for example by using Ctrl+W.
- Change the value to -Xmx1024m.
This will allocate 1024MB of memory instead of the default 512MB.
- Save the file, in nano with Ctrl+O
- Exit nano by using Ctrl+X
- Relaunch the CrashPlan daemon
$ sudo launchctl load /library/launchdaemons/com.crashplan.engine.plist
Still having problems?
If you still have the problem, change the setting to a higher value. You should be able to increase it to 1536 or 2048 on 32-bit systems. Especially on 64-bit systems it might be possible to go higher, for example 4096.
Too much memory in use?
If you notice that CrashPlan is using too much memory while backups are running fine, you may also reduce the memory assignment to 384, 256, 150, 128, 100, 80 or even 50 for small backup sets.
In Mac OS X 64-bit if you set "-Xmx" to 100MB, your "real memory" usage will read about 150/180MB. It will not go over that. In 32-bit it should read around 140MB, it won't go over that.
For Linux, stay on 64-bit (if you have a 64-bit cpu), lower the memory maximum, and use compressed ops. Compressed oops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, use of compressed oops is the default for 64-bit JVM processes when
-Xmx isn't specified and for values of
-Xmx less than 32 gigabytes. For JDK 6 before the 6u23 release, use the