beremote takes 99% of the CPU time

[Marco_67]

the backup exec process (beremote) is taking almost all the CPU time on the XP-UX 11.11 client.
Also the overall performance in terms of transfer rate is very bad.
The issue does not appear on Win's clients.
Symantec support is very badly on HP-UX.

Is there someone who experienced the same and perhaps found a solution to the problem ?

[Gokul Chandola]

Hi,
Check all services running.
Kill those who are not important.
May be required Kernal Tunning and memory tunning for Applications.

Regards,
Gokul Chandola

[Tim Nelson]

What version of BackupExec are you using ?

I have BackupExec clients on HPUX 11.* and they use agent.be process names not beremote.


And yes Symantec support is rated an "F".

Moral of story, do not use Intel/MS based products to run your entrerprise. UNIX !!!

[Bill Hassell]

A Google search produces this link:

http://support.microsoft.com/kb/867667

The title is: The Beremote.exe process uses up to 100 percent of CPU resources

Of that's right, you aren't running Windows -- ignore this link. Or perhaps it is quite telling as it fails the same way on HP-UX.

Bottom line: never use Windows products, especially an application that is so critically dependent on hardware (CPU, I/O, disk, tape) on an enterprise class computer. And don't buy any production product for HP-UX from a vendor that asks: "You're running what?"

Chalk up the BackupExec to a learning experience and take a look at HP's Data Protector or other enterprise class backup tools. Backup software is like insurance. You don't see much value in it until you need it. But when you need it, bad insurance is worthless.

[Marco_67]

The version of VRTSralus is the 11.00.7170.

Unfortunately Backup Exec has been forced us....it's a company decision.

[Duncan Edmonstone · Accepted solution]

What sort of CPU utilization are you seeing? User mode or Sys mode?

If you're seeing a lot of sys mode CPU utilisation from a backup product, it's usually due to a stupidly small default block size for reads (IBM's TSM has this problem for instance). This results in the system having to do A LOT of expensive read system calls off your filesystems, resulting in A LOT of SYS CPU.

I'm not familiar with backup exec (again I agree with others - this is a "departmental" backup product, not suitable for enterprise operating systems or environments), but I would hope there was some way to adjust the read block size upwards. Usually going up to 256K blocks gives a meaningful increase in throughput.

HTH

Duncan

[Marco_67]

Hi Duncan,

it seems to be more sys cpu (57%) than user (17%).
So your suggestionis to review the kernel parameter for what concern the default block size read ?

[Duncan Edmonstone]

No, nothing to do with kernel parameters - they can't control the size of data that BE reads with each read() system call. It would have to be some parameter in backup exec somewhere...

If you have glance on this system you could test this theory by attaching to the process and looking at system calls

1. run glance
2. find your beremote process and make a note of its PID
3. press "s" to select a process, and enter the PID of the beremote process
4. now press "L" (shift-l) to got to the process sys calls screen
5. It might take a few seconds to attach to the process, but eventually you should see a count of the system calls the process is making... are there a LOT of read calls compared to writes?

HTH

Duncan

[Marco_67]

Infortunately we don't have glance...

[Duncan Edmonstone]

Then download and install a copy of tusc from here:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.9/

You can then analyse what system calls your beremote process is doing by issuing:

/usr/local/bin/tusc -c -p

Replacing with the process ID of the beremote process. It won't generate any output, but let it run for a while (at least 5 minutes), then use ctrl-c to terminate tusc and you should get a report of system calls used and time spent on each call.

HTH

Duncan

[Duncan Edmonstone]

Incidentally, I'm presuming Backup Exec is sending its data over the network yes? Have done some tests to work out the maximum throughput of your network? You say it's slow, but maybe you have a bottleneck on the network somewhere?

HTH

Duncan