.
First, consider not running in ROLLFORWARD mode. The log size limitation
of 13gb makes it difficult to run in ROLLFORWARD mode even in the best
of circumstances, once you reach a certain size.
Second, look for a client node who is doing this to you. Build a script
to capture the output of SHOW LOGPIN periodically and look for trends -
you may see one particular client node doing this to you over and over.
With our very large TSM system, the log filling up almost always means
that some one client is having a network slowdown problem. When that
client backs up a large file, the log becomes "pinned" and fills up.
Have your networking people look for "duplex mismatches" between the
various hops in the network between the client and the TSM server. (They
will know what that means.) A duplex mismatch may not affect typial use
of a network connection very much, such as web browsing or telnet/ssh,
but it can seriously slow down a streaming application like TSM Backup.
Consider using the throughput monitoring feature of the TSM server,
which will cancel sessions that cannot achieve a certain minimum
throughput.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
==== When Plain Text is outlawed, only outlaws will use Plain Text =====
On Mon, 29 Oct 2007, Daad Ali wrote:
>
> How can I reduce the "Max. Pct Util" below 80%
>
> I am running DB backups twice a day.
>
> TSM version is 5.4.1
>
> tsm: TSMSERV>q log f=d
> Available Space (MB): 12,000
> Assigned Capacity (MB): 10,020
> Maximum Extension (MB): 1,980
> Maximum Reduction (MB): 10,012
> Page Size (bytes): 4,096
> Total Usable Pages: 2,564,608
> Used Pages: 430
> Pct Util: 0.0
> Max. Pct Util: 85.5
> Physical Volumes: 6
> Log Pool Pages: 128
> Log Pool Pct. Util: 5.59
> Log Pool Pct. Wait: 0.01
>Cumulative Consumption (MB): 5,876,139.16
>Consumption Reset Date/Time: 12/07/05 14:37:35
>
>
>---------------------------------
>Ask a question on any topic and get answers from real people. Go to Yahoo!
>Answers.
>
|
