Performance for SAN Media Server.

[PatS729]

Hello,

Environment details :

Master : RHEL 6.1 running NBU : 7612

Media : NetBackup-HP-UX11.31 7.6.1.2 (SAN MEDIA Server) with 5 LTO6 drives.

$ cat SIZE_DATA_BUFFERS
262144

$ cat NUMBER_DATA_BUFFERS
32

Need your advise on performance issue. Curently backups are running @ 65 MBPS average speed. and we are observing delays in job status.

16:26:14.728 [11855] <2> signal_parent: sending SIGUSR1 to bpbrm (pid = 11783)
16:26:15.210 [11859] <2> io_init: child delay = 10, parent delay = 15 (milliseconds)
16:26:15.950 [11859] <2> signal_parent: sending SIGUSR1 to bpbrm (pid = 11791)
16:27:21.908 [11979] <2> io_init: child delay = 10, parent delay = 15 (milliseconds)
16:27:22.891 [11979] <2> signal_parent: sending SIGUSR1 to bpbrm (pid = 11965)

11/04/2016 17:59:39 - Info bptm (pid=16466) waited for full buffer 31874 times, delayed 41943 times
11/04/2016 17:59:47 - Info bptm (pid=16466) EXITING with status 0 <----------

Do i need here PARENT_DELAY AND CHILD_DELAY settings ? Please advise values to be used for PARENT_DELAY and CHILD_DELAY.

Earlier we had LTO4 drives and backups were writing at average 90 MBPS. Now we have LTO6 drives, is it require to modify adequete BUFFER settings ?

We already have NOSHM touch file in place on SAN Media Server.

Thanks in Advance.

[Marianne]

Bigger buffers is not going to make a difference. bptm is already waiting for full buffers:

waited for full buffer 31874 times, delayed 41943 times

How fast can data be read from disk?
Have you performed bpbkar test?

Single stream or multiple streams?

Tape drive connection between server and drives?
Single or multiple hba's?

What kind of tests have you performed thus far?
Have you tried to write multiple streams (2-4) to just 1 drive?
Then 2 drives? And so on?
Is there a difference in performance between multi-stream to 1 drive and single stream to multiple drives?

There is unfortunately no magic as far as performance tuning is concerned - you need to carefully examine the capabilities of each component in the backup chain, then try different settings based on above, document results of different settings, make one change at a time, test, document, change, test, document....

[PatS729]

Hello Marianne,

Thanks for the inputs, but here is the answer inline

How fast can data be read from disk? -- Its a Oracle DB (17 TB) backup so not sure how to perform bpbkar null test on it. We have no other equivalent data to test bpbkar null test on it.
Have you performed bpbkar test? No.

Single stream or multiple streams? 4 channels allocated.

Tape drive connection between server and drives? LTO6 Drives connected over FC
Single or multiple hba's?

What kind of tests have you performed thus far? No tests performed so far.
Have you tried to write multiple streams (2-4) to just 1 drive? WE have multiplexing value set as "4" on STU.

Then 2 drives? And so on? You mean that we should use less number of drives (may be 2 drives) and test the performance ?
Is there a difference in performance between multi-stream to 1 drive and single stream to multiple drives? We have very less scope to test backups for this server. Perhaps not tested this yet.

[Marianne]

Your dba's should know how to write with rman to a null device to test both Oracle and disk read performance.

There are lots of info available on the web if you/dba google for rman performance tuning and effect of rman backups on memory and/or sga/pga memory... (I am no Oracle expert - just stuff that I've heard over the years that makes me realize how close the dba and backup admin should work together...) 

The sbt channels will determine how many jobs are initiated. 
The filesperset in the script is the Oracle multi-streaming.

Multiplexing in NBU is determined by the MPX setting in the STU as well as the MPX setting in the Default-Application schedule (the lowest value determines how many simultaneous streams to same tape drive).

As I've said - Performance Tuning is a LENGTHY exercise that requires investigation into each component of the backup chain, followed by small changes and proper documentation of each change and result.....