Might want to check resourceutil settings as that limits the number of sessions clients try to setup. It should match maxnummp or be lower.
Op 31 aug. 2016 22:21 schreef "Zoltan Forray" <zfor...@vcu.edu>: > AHA - so I am not loosing my mind (at least in this situation). I too have > been seeing clients getting >3-sessions eventhough the NODE maxnumpoints is > 1! I was always under the impression that maxnumpoints trumps > resourceutilization. > > On Wed, Aug 31, 2016 at 3:40 PM, Thomas Denier < > thomas.den...@jefferson.edu> > wrote: > > > We are occasionally seeing some odd behavior in our TSM environment. > > > > We write incoming client files to sequential disk storage pools. Almost > > all of our client nodes use the default maxnummp value of 1. > > > > When the odd behavior occurs, a number of clients will go through the > > following sequence of events: > > 1.The TSM server will send a request to start a backup. > > 2.The client will almost immediately open a TCP connection to be used as > a > > producer session (a session used to obtain information from the TSM > > database). > > 3.Somewhere between tens of seconds and a few minutes later the client > > will open a TCP connection to be used as a consumer session (a session > used > > to send copies of new and changed files). > > 4.Sometime later the client will open a third TCP connection and start > > using it as a consumer session. > > 5.The TSM server will report large numbers of transaction failures > because > > it considers the original consumer session to be tying up the one mount > > point allowed for the node and hence has no way of storing files arriving > > on the new consumer session. > > > > In most cases, all of the affected clients will hit step four within an > > interval of a couple of minutes. > > > > My current theory is that step four occurs when the client system detects > > a condition that is viewed as a fatal error in the original consumer > > session, triggering the opening of a replacement consumer session. In > most > > cases the TSM server never detects a problem with the original consumer > > session, and eventually terminates the session after five hours of > > inactivity (we have database backups that can legitimately go through > long > > periods with no data transfer). More rarely the TSM server eventually > > reports that the original consumer session was severed. > > > > We occasionally see cases where the replacement consumer session is in > > turn replaced by another new session, and even cases where the latter > > session is replaced by yet another session. > > > > Our client population is a bit over half Windows, but almost all > instances > > of the odd behavior involve only Windows client systems. > > > > The affected systems are frequently split between two data centers, each > > with its own TSM server. > > > > We have usually not found any correlation between the odd TSM behavior > and > > issues with other applications. The most recent case was an exception. > > There were some e-mail delivery failures at about the same time as step > > four of the odd TSM behavior. The failures occurred when e-mail servers > > were unable to perform LDAP queries. > > > > When we have asked our Network Operations group to check on previous > > occurrences of the odd behavior they have consistently reported that they > > found no evidence of a network problem. > > > > Each of our TSM servers runs under zSeries Linux on a z10 BC. Each server > > has a VIPA address with two associated network interfaces on different > > subnets. > > > > I would welcome any suggestions for finding the underlying cause of the > > odd behavior. > > > > Thomas Denier, > > Thomas Jefferson University > > The information contained in this transmission contains privileged and > > confidential information. It is intended only for the use of the person > > named above. If you are not the intended recipient, you are hereby > notified > > that any review, dissemination, distribution or duplication of this > > communication is strictly prohibited. If you are not the intended > > recipient, please contact the sender by reply email and destroy all > copies > > of the original message. > > > > CAUTION: Intended recipients should NOT use email communication for > > emergent or urgent health care matters. > > > > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > Xymon Monitor Administrator > VMware Administrator (in training) > Virginia Commonwealth University > UCC/Office of Technology Services > www.ucc.vcu.edu > zfor...@vcu.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 >