Data Protection Software

 View Only
Expand all | Collapse all

What is the tape drive performance during the directory-container dedup pool protection ?

  • 1.  What is the tape drive performance during the directory-container dedup pool protection ?

    Posted Thu August 26, 2021 08:44 AM
    Hi,

    In our environment, TSM is able to achieve 798 MB/s during a TSM DB backup with one IBM TS1160 tape drive ( native throughput 400 MB/s ).

    But during the protection of a dedup directory-container pool "protect stgpool stgpool1 type=local reclaim=no", the TS1160 tape drive average throughput can vary from 116 MB/s to 38 MB/s, apparently depending of the data deduplicated ( SAP HANA DB: 116 MB/s,  MS-SQL DB 71 MB/s, ORACLE/VMware 38 MB/s ).
    Be careful, the protection to a container-copy pool begins with a 'deleting phase', but with LocalProtCntrCons = 8, this first phase doesn't take too long.

    I'm very surprised to not achieve better performance, because the stgpools are written a little bit sequentially ( REUSE_DELAY ).
    Besides, as TSM works in batches, the tape write performance should be good.
    For me the only DB2 database updates could be the limiting factor, but with NMVE disks able to achieve more than 100.000 IO/s during the expiration + 1 TB RAM, this bottleneck should not appear during with only 1 directory-copy. 
    Even with only one process "protect stgpool type=local reclaim=no", it seems difficult to achieve half of the TS1160 drive throughput.

    I would like to know:
    - what is your tape drive throughput during the directory-copy protection in your environment ?

    Thanks.
    Emmanuel.

    ------------------------------
    emmanuel hivet
    ------------------------------


  • 2.  RE: What is the tape drive performance during the directory-container dedup pool protection ?

    Posted Fri August 27, 2021 09:05 AM
    Edited by paul elson Fri August 27, 2021 09:05 AM
    I have a couple of customers using the same setup except they have LTO7 and LTO8 drives. They are getting the about the same performance as you. It's pretty slow for what it could be. Must be they way it's coded.

    ------------------------------
    paul elson

    ------------------------------



  • 3.  RE: What is the tape drive performance during the directory-container dedup pool protection ?

    Posted Wed September 01, 2021 10:26 AM
    TSM/SP is beholden to the latency of the individual sequence of IOs.  While you can get 100,000 IOPS, that is in a highly parallel process.  An individual IO on NVMe is still going to have a latency somewhere in the 80us range, plus whatever I/O latency there is for reconstruction of the raw data.  For PROTECT STG, there is simply not enough parallelization in a single stream to drive the minimum streaming speed of an LTO tape drive. 

    To feed a modern, high speed tape drive, the server would need to run multiple reconstruction threads, and cache the data before feeding it to the tape write process.  Since PROTECT STG will run on a 32GB server, that buffer is not going to be in RAM (unless there is an undocumented/underdocumented setting for this).  There is no current way to set any sort of buffer on disk either (again, unless there is some hidden setting to use free space in NDF files temporarily).  As such, PROTECT to one tape is basically a MAXSESS of 1 with a single (or small number) of threads on the backend.

    You could get better performance going to a remote server with a high maxsessions setting.  That was the first option and what they planned for.  PROTECT to tape (and PROTECT of CLOUD to anywhere) did not get enough pressure to do anything more.  The RFE system can help some, but the number of votes matters relative to the work effort required.  Higher work effort for this kind of optimization probably would need hundreds of votes, or a sponsor to fund the development effort.

    This is just my interpretation.  I don't speak for IBM.

    ------------------------------
    Josh-Daniel Davis
    Highland Village TX
    6824293040
    ------------------------------