Koozali.org: home of the SME Server

Obsolete Releases => SME 7.x Contribs => Topic started by: bcdaus on June 15, 2006, 07:06:27 AM

Title: RAR causing 98% processor in Backup2 job
Post by: bcdaus 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.
Title: Re: RAR causing 98% processor in Backup2 job
Post by: raem on June 15, 2006, 04:16:20 PM
bcdaus

What directories are included in the backup job.
You didn't incude all did you ?
Title: Re: RAR causing 98% processor in Backup2 job
Post by: CharlieBrady 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.
Title: RAR causing 98% processor in Backup2 job
Post by: ksc133 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
Title: RAR causing 98% processor in Backup2 job
Post by: bcdaus 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
Title: RAR causing 98% processor in Backup2 job
Post by: ksc133 on June 21, 2006, 12:37:35 PM
hi folks,

do those linux RAR trial versions expire?
Title: RAR causing 98% processor in Backup2 job
Post by: uli334 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
Title: RAR causing 98% processor in Backup2 job
Post by: raem 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
Title: RAR causing 98% processor in Backup2 job
Post by: judgej 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://
Title: RAR causing 98% processor in Backup2 job
Post by: raem 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.
Title: RAR causing 98% processor in Backup2 job
Post by: judgej 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
Title: RAR causing 98% processor in Backup2 job
Post by: bcdaus 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.