Forum Discussion

BTLOMS's avatar
BTLOMS
Level 5
11 years ago

SLP fine tuning in NBU 7.6.02

We recently upgraded from 7.5.05 to 7.6.02.

 

SLPs were running fine in 7.5.05

In 7.6.02, we notice that at any given time, there are more than 3 SLP jobs waiting on the same tape. We also noticed that at times, the tapes jump back and forth between SLPs.

I do know about the new features in 7.6 and how one can set them in the Master Server config- SLP Parameters. I also read a whitepaper here.

My question is: Is there a calculation or any other way to arrive at a value for the SLP Properties in the SLP parameters GUI.

EDIT: I just saw 7 jobs waiting for the same tape.

Thanks,

4 Replies

  • I found the answer in page 160 in the fine tune guide that was just released.

     

    http://www.symantec.com/connect/forums/updated-netbackup-backup-planning-and-performance-tuning-guide-release-75-and-release-76

    Disabling the sharing of NetBackup reservations
    In NetBackup, shared reservations are enabled by default.
    In most cases, sharing reservations results in better performance.
    However, it may be helpful to disable sharing reservations in the following case:
    ■ Many duplication jobs are running (using a storage lifecycle policy, or Vault, or
    bpduplicate), and
    ■ Many read media are shared between different duplication jobs
    In this case, without shared reservations, one job runs and other jobs requiring the
    same media are queued because they cannot get a reservation. With shared
    reservations, the jobs can start simultaneously. However, with a limited set of
    resources (media/drive pair or disk drives), resources may bounce or "ping-pong"
    between different jobs as each job requests the resource.

     

     

    Thanks,

     

     

  • Are those SLP jobs trying to "read from" or "write to" the tape?

    Might want to check this TAPE_RESOURCE_MULTIPLIER out as well, details in: http://www.symantec.com/docs/HOWTO33715

    I have never play around with this setting, but guess it may impact how SLP jobs are queued.

  • This is not a drive issue. All the drives are being used. The problem here is there are about 6 SLP's queued requesting the same tape - and the tape ping-pongs between all 6. Kind of like one apple being shared by 6 people, one bite at a time ( few bytes in this case :)   )

  • My assumptions were wrong. The case was escalated to Symantec and they helped resolve it. We had to increase the "Maximum size per duplication job" and "Min size per dupe job" values. Also force interval and job submission intervals. Tape resource multiplier is still at default vaule.