CrashPlan Performance

[oshae]

I've been using CrashPlan on my Pro 6 for quite some time now and have been very happy with it. All of what I want to backup (to CrashPlan's cloud) is already there, and not much additional data is generated that I want to backup. So CrashPlan sits fairly idle most of the time on my NAS. In total I have somewhere between 1-2TB backed up.

Recently, I added a folder with about 40GB of data and as expected CrashPlan saw it and started sending it to the cloud. I got home today and found my NAS performing so slow I couldn't browse any shares and barely navigate the GUI. I have the CrashPlan settings set to use no more than 25% of the CPU and 2Mbps network upstream. I'm not really in any massive hurry to get the data up there. Stopping CrashPlan fixes the issue but as soon as it is started again and begins a backup it slows down. Running htop this is what I'm seeing below. I'm not familiar with the different colors used in htop, but I beleve the red in the CPU graph are kernel processes. From what I can tell, the java process that CrashPlan launches is obeying the 25% CPU limit. So then what is it that is eating up so much CPU power?

It seems I'm also running into a low RAM issue so I'm wondering if this is the cause? I only have the stock 1GB in my Pro 6. I read in another thread that someone ran into a RAM limitation due to amount of data/number of files. Does this appear to be the same issue that I'm running into as well? If it's RAM I need to add I was thinking of picking up some of these: http://www.memoryexpress.com/Products/MX20897 I believe they should work in the Pro 6?

[StephenB · Accepted solution]

---

@oshae wrote:

So you just leave the CPU% at 100%? It doesn't impact things like SMB performance if a backup is running at the same time?

---

It might slow it down some, but not enough to be a problem. 

---

@oshae wrote:
 I had some PC2-6400 DIMMs kicking around so I tested the unit with 2GB. It is seems to have completely resolved the issue so RAM does seem to be the culprit. I was thinking of ordering a new kit of 2 x 2GB, but now that you mention you upgraded your unit to 8GB I'm thinking that may be the way to go. Can I ask what brand/spec of RAM you're using in yours?

---

Crashplan itself can't use more the 3600MB of ram, so 8 GB was probably overkill.  I used Patriot Memory (Patriot Signature Line 8GB DDR2 800 PC2 6400 Memory Module PSD28G800K).

My volume size is likely bigger than yours (I'm backing up ~7-8 TB, and my crashplan central archive had reached over 20 TB last June).  It reached a point where crashplan started crashing because it had run out of memory.  If you are aren't seeing restart logs in /usr/local/crashplan you likely don't have that issue.

---

@oshae wrote:

Also, I'm not familiar with the -Xmx setting? Can you elaborate or point me in the right direction?

---

So what you've done so far is simply freeing more memory up for the rest of the NAS.  If you want to allow Crashplan to use more memory, then you need to increase the ceiling on the java VM heap size.  That's what -Xmx does.

If you click on the house on the upper right of the crashplan app, it will open a command interface on the PC.  If you just type "java mx" it will tell you the current heap max.  That should be 1024MB on your setup.  If you enter "java mx 1536" it would adjust it upward to 1536 MB.  The max is about 3700MB (if you go much above that, Java will actually crash).

You never want to set the value higher than your physical memory, because the pro doesn't handle swapping very well. 

Overall, since your performance problem is fixed, there is no reason to do anything just yet with "java mx".

I guess you could upgrade the ram under the theory that the old memory the pro uses will only harder to find later on.  Or just leave well enough alone.

 

[StephenB]

I've never limited the CPU% or internet bandwidth for Crashplan in my pro-6, and I haven't experienced your massive performance slowdown.

But I have upgraded the pro's memory twice because of Crashplan.  I doubled first it to 2 GB, and later to 8 GB.  I also of course had to change the -Xmx setting too. The max is ~3600 btw - crashplan has to run in a 32bit JVM, and some of that memory space is reserved.

So I do suggest increasing memory.  Also, you might try going into advanced backup settings and set deduplication to "minimal" and compression to "off".

[mdgm-ntgr]

Deduplication can be one of those things that sounds nice till you realise that if you need to deduplicate a lot of data then you can have high RAM requirements.

[oshae]

So you just leave the CPU% at 100%? It doesn't impact things like SMB performance if a backup is running at the same time?

I had some PC2-6400 DIMMs kicking around so I tested the unit with 2GB. It is seems to have completely resolved the issue so RAM does seem to be the culprit. I was thinking of ordering a new kit of 2 x 2GB, but now that you mention you upgraded your unit to 8GB I'm thinking that may be the way to go. Can I ask what brand/spec of RAM you're using in yours?

Also, I'm not familiar with the -Xmx setting? Can you elaborate or point me in the right direction?

I do have dedupe set to minimal and compression off.

Thanks for your reply!

[StephenB · Accepted solution]

---

@oshae wrote:

So you just leave the CPU% at 100%? It doesn't impact things like SMB performance if a backup is running at the same time?

---

It might slow it down some, but not enough to be a problem. 

---

@oshae wrote:
 I had some PC2-6400 DIMMs kicking around so I tested the unit with 2GB. It is seems to have completely resolved the issue so RAM does seem to be the culprit. I was thinking of ordering a new kit of 2 x 2GB, but now that you mention you upgraded your unit to 8GB I'm thinking that may be the way to go. Can I ask what brand/spec of RAM you're using in yours?

---

Crashplan itself can't use more the 3600MB of ram, so 8 GB was probably overkill.  I used Patriot Memory (Patriot Signature Line 8GB DDR2 800 PC2 6400 Memory Module PSD28G800K).

My volume size is likely bigger than yours (I'm backing up ~7-8 TB, and my crashplan central archive had reached over 20 TB last June).  It reached a point where crashplan started crashing because it had run out of memory.  If you are aren't seeing restart logs in /usr/local/crashplan you likely don't have that issue.

---

@oshae wrote:

Also, I'm not familiar with the -Xmx setting? Can you elaborate or point me in the right direction?

---

So what you've done so far is simply freeing more memory up for the rest of the NAS.  If you want to allow Crashplan to use more memory, then you need to increase the ceiling on the java VM heap size.  That's what -Xmx does.

If you click on the house on the upper right of the crashplan app, it will open a command interface on the PC.  If you just type "java mx" it will tell you the current heap max.  That should be 1024MB on your setup.  If you enter "java mx 1536" it would adjust it upward to 1536 MB.  The max is about 3700MB (if you go much above that, Java will actually crash).

You never want to set the value higher than your physical memory, because the pro doesn't handle swapping very well. 

Overall, since your performance problem is fixed, there is no reason to do anything just yet with "java mx".

I guess you could upgrade the ram under the theory that the old memory the pro uses will only harder to find later on.  Or just leave well enough alone.

 

[oshae]

All great info. I think I'll just grab a couple new 2GB DIMMs (cheaper than 2 x 4GB these days) and call it a day. I'll leave the java heap size alone for now.

Thanks a ton Stephen!