cancel
Showing results for 
Search instead for 
Did you mean: 

bpbkar slow and taking 100% CPU.

james_ritchie
Level 2
Prelude: New to Veritas I concede. No root access right now.
Full system backup writing to DLT(s).
Total backup payload 172G (so fairly substantial).

18 hrs in and we're still writing ( 50% complete ), so its gonna be a a 36 hr job. We have backed up 81G in 18 hrs, so our backup rate is 4.5G/hr. Not sure if this is a healthy write/rate to a DLT? - I assume NOT.

bpbkar has hogged 100% cpu for the whole duration - seems v.strange.

Basically, can someone give me directions for analysis ?
I need to determine what, if anything, is wrong. THanks.
5 REPLIES 5

MayurS
Level 6
Hi,

Can you check whether the tracker.exe is running in the process.
If it is kill it.

I had faced similar slow backups...Tracker was the culprit.

james_ritchie
Level 2
> Hi,
>
> Can you check whether the tracker.exe is running in
> the process.
> If it is kill it.
>
> I had faced similar slow backups...Tracker was the
> culprit.

TRacker.exe does not appear to be running.
Forgot to mention its running on Solaris.

How does one determine number/size of buffers, or number of worker-threads ?

Satish_Kumar_3
Level 4
Hi,

I too faced a similar problem and this is what I did and it worked.

1. Disabled Auto-negotiation on the NIC card and made it 100 Mbps FULL-Duplex. I used mii-tool and ethtool. I am running RHEL 3.0 box with Master+ Media server.
2. Tracker.exe was running on my windows server and disabled that.
3. Edit your bp.conf file and enter VERBOSE = 5, and then create in the /usr/openv/netbackup/log/ folder the bptm file and ckeck the log.

Regards
SK

AKopel
Level 6
Couple of other things...
How fragmented is the drive. Are you using compression (software). Are the files millions of small files?
All of these will cause bpbkar to work very hard.

james_ritchie
Level 2
THanks for the response aARON.

The culprit was indeed COMPRESSION. Our DLT device driver is a compressing device anyways, so Veritas Netbackup compression is de trop.

Compression also caused bpbkar to tight-loop, hogging its cpu and writing at best at 300kb/sec. Switching off Netbackup compression upped our write-speed to circa 8M/sec, which fits our requirements just fine, and uses virtually no cpu.

Result.