What I wanted to know was is it is normal for idle session to scan which is doing nothing for 3hrs. And still I see data xfer on recv state session.
-----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 02, 2002 1:02 PM To: [EMAIL PROTECTED] Subject: Re: WHy Idle wait keeps incrementing?(reply) The idle wait applies to session 2763, while the bytes received applies to session 2764. These are two separate/independent sessions, so there is no direct relationship between what happens on one session and what happens on the other session. However, there is an *indirect* relationship. Based on the information you have provided, I would say that session 2763 was initiated by a client producer thread, and session 2764 was initiated by a client consumer thread. (The TSM client uses the producer-consumer multithreading model.) When the producer thread gets a file specification to be processed, it queries the TSM server for information about existing backups for that file spec. The server sends the query results back to the client, which is why you see a relatively large number of bytes sent for session 2763. The producer thread uses the query results to determine which files have changed since the last backup, then builds transactions (representing files to be backed up) to be processed by the consumer thread. The consumer thread then backs up the files in each transaction. Since it is the consumer thread that does the actual backup work (i.e. the transfer of the data to the server), you see its session (2764) with a large number of bytes received. In your case, the producer thread is not being given any more file specifications to process, so it isn't querying the TSM server, and thus its session is idle. Once the consumer thread is done with its work (and there are no more file specifications to process), then the consumer and producer threads will close out their server sessions. If the producer session is timed out via the server's IDLETIMEOUT setting, it will re-establish itself if necessary. The client's main thread is responsible for giving the producer thread file specs to process. The producer thread doesn't close out its session after processing each file spec for performance reasons; if the file specs are coming in fairly quickly, then the overhead of stopping/restarting sessions could impact performance. In theory, I suppose the producer could close its session after a certain period of inactivity, but for now, this is how it works. What you are seeing is normal. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "PINNI, BALANAND (SBCSI)" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 01/02/2002 10:33 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: WHy Idle wait keeps incrementing?(reply) Hi Happy new year to u all. Can u pl help me with this question. I have seen sometimes Idlewait time keeps incrementing in spite of client getting backed up. Thanks in advance. tsm: TSM>query session Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name Number Method State Time Sent Recvd Type ------ ------ ------ ------ ------- ------- ----- -------- -------------------- 2,763 Tcp/Ip IdleW 42.1 M 10.5 M 1.1 K Node WinNT Client1 2,764 Tcp/Ip RecvW 0 S 1.7 K 106.9 M Node WinNT Client1 Balanand
