Gretchen, Could you give us all some idea what your environment consists of and how your TSM Server is set up? How many sessions were you allowing at any one time? How many did you have to cut it down to?
Geoff Gill TSM Administrator NT Systems Support Engineer SAIC E-Mail: [EMAIL PROTECTED] Phone: (858) 826-4062 Pager: (877) 905-7154 > -----Original Message----- > From: Gretchen L. Thiele [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 10, 2003 6:03 AM > To: [EMAIL PROTECTED] > Subject: v5.1.6.1, so far > > > The two situations where I could force a core dump in > v5.1.6.0 have been resolved, but I think there is now a > different problem in v5.1.6.1. > > Granted, my servers run flat out all the time with sessions > constantly, but I rarely pin the 13 GB log with dirty pages > (at least not over 60 to 70%). It's happening all the time > now. I've had to cut back on my workload by two thirds in > order to get the log to settle down. Not good. It took out > two of my servers a couple of times over the weekend until I > severely limited the number of sessions and scheduled sessions. > > The log would creep up and I'd get the 'log is pinned by a > dirty page' from 'show logpin'. When the log started to cool > off, but not drop in utilization, this message would > alternate with the 'log not pinned, will be cleared at next > commit'. It took one server over 5 hours last night to 'calm > down' - I disabled sessions when it hit 40% and it climbed to > over 80% before it started to wane. > > Also, when it's a client that has the log throttled, it's > almost impossible to cancel the session before the log fills > and core dumps the server. A 'cancel session force=yes' would > be really nice about now. It's about a wash whether or not to > allow the log to fill and core dump or just halt the server > and let it come up again and 'figure' things out. > > It'd be nice to know if we can force a commit or if it's time > based, just when does it happen? > > Gretchen Thiele > Princeton University >
