Threads=number

    Specifies the number of reader threads to be used by the backup
    process.

    RMU creates so called internal 'threads' of execution to read
    data from one specific storage area. Threads run quasi-parallel
    within the process executing the RMU image. Each thread generates
    its own I/O load and consumes resources like virtual address
    space and process quotas (e.g. FILLM, BYTLM). The more threads,
    the more I/Os can be generated at one point in time and the more
    resources are needed to accomplish the same task.

    Performance increases with more threads due to parallel
    activities which keeps disk drives busier. However, at a certain
    number of threads, performance suffers because the disk I/O
    subsystem is saturated and I/O queues build up for the disk
    drives. Also the extra CPU time for additional thread scheduling
    overhead reduces the overall performance. Typically 2-5 threads
    per input disk drive are sufficient to drive the disk I/O
    susbsystem at its optimum. However, some controllers may be
    able to handle the I/O load of more threads, for example disk
    controllers with RAID sets and extra cache memory.

    In a backup operation, one writer thread is created per output
    stream. An output stream can be either a tape drive, a disk file
    or, a media library manager stream. In addition, RMU creates
    a number of reader threads and their number can be specified.
    RMU assigns a subset of reader threads to writer threads. RMU
    calculates the assignment so that roughly the same amount of
    data is assigned to each output stream. By default, five reader
    threads are created for each writer thread. If the user has
    specified the number of threads, then this number is used to
    create the reader thread pool. RMU always limits the number of
    reader threads to the number of storage areas. A threads number
    of 0 causes RMU to create one thread per storage area which start
    to run all in parallel immediately. Even though this may sound
    like a good idea to improve performance, this approach suffers
    performance for databases with a larger number (>10) of storage
    areas. For a very large number of storage areas (>800), this
    fails due to hard limitations in system resources like virtual
    address space.

    For a backup operation, the smallest threads number you can
    specify is the number of output streams. This guarantees that
    each writer thread has at least one reader thread assigned to it
    and does not produce an empty save set. Using a threads number
    equal to the number of output streams generates the smallest
    system load in terms of working set usage and disk I/O load.
    Disk I/O subsystems most likely can handle higher I/O loads.
    Using a slightly larger value than the number of output streams
    (for example, assigning more reader threads to a writer thread)
    typically results in faster execution time.