Koozali.org: home of the SME Server

RAR causing 98% processor in Backup2 job

bcdaus

RAR causing 98% processor in Backup2 job
« on: June 15, 2006, 07:06:27 AM »
Hi,

I installed RAR 3.5.1.-7 from D May on my freshly installed SME 7rc3 box to use with the excellent Backup2 contirb.

However - it seems to clag my processor to 98% for hours.  I tired a 911 backup and it churned away for more than a day before I killed it.

Server is a P4 HT 2.8GHz with 1G of RAM backing up 110Gb to an external USB drive with compression set to 0.

Has anybody else seen a big memory usage spike with RAR ??  Also interesting is when I run RAR -V it reports back as being 3.60b4

Bill.

Offline raem

  • *
  • 3,972
  • +4/-0
Re: RAR causing 98% processor in Backup2 job
« Reply #1 on: June 15, 2006, 04:16:20 PM »
bcdaus

What directories are included in the backup job.
You didn't incude all did you ?
...

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: RAR causing 98% processor in Backup2 job
« Reply #2 on: June 15, 2006, 07:49:42 PM »
Quote from: "bcdaus"

I installed RAR 3.5.1.-7 from D May on my freshly installed SME 7rc3 box to use with the excellent Backup2 contirb.

However - it seems to clag my processor to 98% for hours.  I tired a 911 backup and it churned away for more than a day before I killed it.


Problems with contribs should be reported via the bug tracker.

ksc133

RAR causing 98% processor in Backup2 job
« Reply #3 on: June 21, 2006, 05:15:30 AM »
where do u guys get ther free RAR for linux?
i thought they are only trial -verisons on the web?

thanks

bcdaus

RAR causing 98% processor in Backup2 job
« Reply #4 on: June 21, 2006, 06:13:15 AM »
Its the Linux RAR trial version.
Seemed to have solved the issue by uninstalling the TWO coppies of RAR I had somehow installed.  Must stop rebuilding servers in the middle of the night....


Bill

ksc133

RAR causing 98% processor in Backup2 job
« Reply #5 on: June 21, 2006, 12:37:35 PM »
hi folks,

do those linux RAR trial versions expire?

Offline uli334

  • ***
  • 128
  • +0/-0
RAR causing 98% processor in Backup2 job
« Reply #6 on: June 30, 2006, 05:07:13 AM »
On my SME7 rc3 machine the installation of RAR 3.5.1.-7 from dmay fails, telling:

" Failed dependencies:
        libstdc++.so.5 is needed by rar-3.5.1-7dmay.i386
        libstdc++.so.5(CXXABI_1.2) is needed by rar-3.5.1-7dmay.i386
        libstdc++.so.5(GLIBCPP_3.2) is needed by rar-3.5.1-7dmay.i386
    Suggested resolutions:        /home/buildcentos/CENTOS/en/4.0/i386/CentOS/RPMS/compat-libstdc++-33-3.2.3-47.3.i386.rpm"

Does anyone have the same problem or even a solution?

Uli

Offline raem

  • *
  • 3,972
  • +4/-0
RAR causing 98% processor in Backup2 job
« Reply #7 on: June 30, 2006, 08:47:18 AM »
uli334

>...or even a solution?

The answer has been posted in these forums a number of times already. Just search on libstdc
...

Offline judgej

  • *
  • 375
  • +0/-0
RAR causing 98% processor in Backup2 job
« Reply #8 on: July 05, 2006, 10:18:26 AM »
Quote from: "RayMitchell"
The answer has been posted in these forums a number of times already. Just search on libstdc


And when I did a search and found this thread - surprise - it was not posted here.

Just to try and inject a solution into the noise of 'do a search', this handles the install of rar in 7.0:

# yum install rar-3.5.1-7dmay.i386.rpm

That command was posted in this thread:

http://forums.contribs.org/index.php?topic=29527.0

http://
-- Jason

Offline raem

  • *
  • 3,972
  • +4/-0
RAR causing 98% processor in Backup2 job
« Reply #9 on: July 05, 2006, 11:46:47 AM »
judgej

>... Just to try and inject a solution into the noise of 'do a search'...

By all means post a direct link to the answer.
I wish everyone would post their resolutions when they report problems in forums, rather than just say "It's OK now, I fixed it". So often I would like to know the outcome but people often don't bother to give final feedback re the outcome, leaving many posts as a dead end.

Many people including myself, suggest people to search, when we feel it is appropriate.
Mainly it's because we know the answer is there and usually easily found. Sometimes a push in the right direction is needed though, resulting in answers like "search on libstdc" etc. Some people seem to object to this approach, but isn't any answer better than no answer.

More importantly it teaches people how to find answers for themsleves, so they will be able to find an answer for the next question and the next and the next, without needing to use other peoples time repeating the same answer to the same question over and over.

I assume that's the very reason you chose to ad the answer to this thread, isn't it. So that someone else could find (ie search for) the answer in the future.


> That command was posted in this thread:
> http://forums.contribs.org/index.php?topic=29527.0

Which is indeed found by a search on libstdc, especially if you remember to click on the new bright red "Show all Results" link and look for posts related to backup2ws.
...

Offline judgej

  • *
  • 375
  • +0/-0
RAR causing 98% processor in Backup2 job
« Reply #10 on: July 05, 2006, 06:13:47 PM »
Agreed - people should not just leave the thread hanging when they have their solution.

I wonder if there is some way threads can be labelled, so we can tell, when scanning or searching, whether a conclusion was ever reached?

-- JJ
-- Jason

bcdaus

RAR causing 98% processor in Backup2 job
« Reply #11 on: July 06, 2006, 03:54:05 AM »
Followup to RAR and processor usage.

I still see a big spike when running a backup job using RAR, but am now better handling the scheduling of the backup jobs to ensure it does not affect the server usage.

Backup2 is working well to both USB hard drive and Iomega REV drive.

Bill.