Well, in this situation, we discovered the dreaded "retrying 150GB file
backup" as the problem. Ignoring the fact that the 150GB file is names as
a "log" of some kind, once we added CHANGINGRETRIES 0, the backups have
dropped in both time and size, no longer causing the pinning problem.
I don't have the authority to tell the app owner to look into why their
"log" is 150GB! We just send them the bill ;---)
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
From:
"Loon, EJ van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
03/17/2010 09:29 AM
Subject:
Re: [ADSM-L] Long running backup pinning log
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Hi Zoltan!
We were experiencing a lot of logpinning about a month ago which all
seem related to a handful of clients. Investigation showed that nearly
all of them were running with a half-duplex connection instead of a full
duplex fixed rate. As soon as this was fixed by the client owner,
backups were performing as expected and logpinning was gone too.
Just an thought...
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: maandag 8 maart 2010 15:53
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Long running backup pinning log
Thanks for the heads-up.
Unfortunately, from reading the APAR, this box does not seem to have the
symptoms. There is no significant gap in backing up each component of
systemstate, unless this is hidden because of QUIET. We have changed
this
to VERBOSE to get more details on where it is slogging.
>From what I see in the dsmsched log, this is what the last backup that
finished (todays is still running), says:
01:43 - Backup started
01:47 - Systemstate backup finished
12:21 - d$ drive backup finished
12:25 - c$ drive backup finished
Total objects examined - 72,395
Total objects backed up - 1,725
Total data backed-up (to paraphase) - 93.82Gb
I did note the "Object compressed by" is 87%. Which brings me to the
question - Is the "total amount backed up" after compression?
My guess it lots of time spent in compression (IBM - how about some
compression algorithm controls (low - medium - high). Haven't ruled out
"retries" - will see when verbose is on.
I don't see journaling making that much of a difference. The server has
2GB RAM of which 900M was free when I checked it this morning, so it
doesn't seem to be constrained. The backup is currently running and the
dsm service was using 10-20% CPU.
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
From:
Andrew Raibeck <storman AT US.IBM DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
03/05/2010 04:32 PM
Subject:
Re: [ADSM-L] Long running backup pinning log
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Hi Zoltan,
Is the long-running backup working on system state? I haven't found a
direct cause --> effect relationship to client APAR IC63094, but take a
look at that APAR and see if, after applying the fix, the problem you
are
seeing goes away.
I should mention to all: IC63094 describes a problem with long-running
system state backups. This APAR may be of interest to you.
Best regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_
Storage_Manager
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 2010-03-05
16:26:01:
> [image removed]
>
> Long running backup pinning log
>
> Zoltan Forray/AC/VCU
>
> to:
>
> ADSM-L
>
> 2010-03-05 16:26
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> I recently started having issues with my log going over 80% (5.5.3).
Doing
> a "show logpinned" usually points to a long (18-hours) running backup
> session for one particular node.
>
> This is starting to happen more and more frequently.
>
> Once I kill the session, the log utilization drops to almost nothing
since
> there has been a DB backup run earlier in the day.
>
> Any suggestions on how to handle this besides killing the session?
The
> node is a standard 2K3 box using the 6.1.2.0 client. It is just a
very
> slow/busy box. The long backups (times vary from 11-19 hours) often
dump
> 120GB of data.
> Zoltan Forray
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations
will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://infosecurity.vcu.edu/phishing.html
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
|
