Forum Discussion

raffl's avatar
raffl
Level 4
8 years ago

media multiplexing

i am duplicating images from tape to disk and getting 20-30 GB/Hour. These are LTO 4 tapes and duplicating them to advanced disk.

If these tapes are multiplexed will it imact the duplication ?I see in tape report that they were multiplexed but doesn't show what multiplexing number was used.

Pls help me with my performnce.

I have 1 master and 4 media server. 1 server reading 4 drives.

number data buffers = 32

size data buffer = 262144

 

 

  • 01:55:10.752 [25808.14272] <2> read_data: waited for empty buffer 1608 times, delayed 17063 times

    01:55:24.908 [21596.7104] <2> write_data: waited for full buffer 365295 times, delayed 1395403 times

     
    For a duplication, bptm does both the read and the write.

    So we have:

    Source side  data   --->  Buffers  ---->  Duplication side

    The source side fills up the buffer, and was delayed from doing so 17063 times, each delay is I think 15 milli seconds, so in the dupration of the job, there was a (15 x 17063)/ 1000 second delay = about 255 seconds, where the read side process was doing nothing (well it was waiting for a buffer to become free).  Presuming the job length was 'kinda long' , 255 sec isn't worth bothering about (in fact, you usually will get some delays, even in the best tuned system), as it is a small % of the totakl job length.  that said, I don;t know what the job length was, so you have to make a judgement as to how significant the delay is.

    The write side is the bigget problem:

    01:55:24.908 [21596.7104] <2> write_data: waited for full buffer 365295 times, delayed 1395403 times

    Here bptm, waited 1395403 for data to be duplicated to be written to the buffer - so although the bptm read process was going through the tape, it was only finding relevant data 'every now and then', so the write process bptm had to wait until the buffer was full of data relevant to the backup being duplicated.

    (15 x 1395403 )/ 1000 = 20931 sec = 348 minutes = 5.8 hours.

    So, the mpx of the backup, may be contributing up to 5.8 hours of delays, in this specific job.

  • That's not very fast, 20 GB/hr = 5.5 MB/s, and 30 GB/hr = 8.5 MB/s.

    Times four active duplications thats 22.8 MB/s to 34.1 MB/s which looks suspiciously like USB2 disk.  Is your Adv.Disk storage unit on USB2 disk?

    And, yes, previously multi-plexed tapes can be slower to read for single threaded duplication/restore simply because the tape can be more sparsely populated with the backup data you are seeking.  But, yes, I would expect better than 5.5 MB/s from an LTO4 tape drive... assuming that the data that you are reading is not extremely sparse.

    Did you baseline the performance of the disk being written to?  i.e. do you already know that the disk that you are writing to can actually sustain, over long periods of time, more than 20/30 GB per hour of mixed sequential/random disk IO ?

    Are all four duplication reads all writing to the same Adv. Disk storage unit? If so, then your actual disk write patterns will be effectively random.

    Is the disk being written to being used for or by anything else... anywhere along the IO path?

    Is the Adv.Disk storage unit on a share or UNC path?  Or is it actually real DAS or real SAN (iSCSI/FC) disk?

    You may be able to tweak NUMBER_DATA_BUFFERS_RESTORE for tape reading... but I'm not 100% certain whether duplication jobs pay any attention to that tuning file.  Maybe someone else can confirm.

    And maybe also tuning NUMBER_DATA_BUFFERS_DISK for the disk writing side.

    See tech note:

    Notes on number data buffers files

    https://www.veritas.com/support/en_US/article.000076412

     

    .

    How many backups, tapes, GB do you have to duplicate?

    Are you intending to ultimetly duplicate these backups back to newer tape?

    • raffl's avatar
      raffl
      Level 4

      Advanced disk is created over the unc path and it is DAS to a server and dedicated for duplication. All the duplication goes to this ADV disk at the same time.

      There would be lot of images and yes I might duplicate them to LTO7 at later stage

      • Marianne's avatar
        Marianne
        Level 6
        As per sdo - have you tested write speed to the disk outside of NBU? CIFS protocol has it's own overheads and then the other server's write speed to disk...

        bptm log will show you where the hold up is in the process - look for 'waited for full / empty buffers'.