RE: wmdist -l notification interval

I'd like to make a quick comment about this suggestion.

This may not be the best way to do this because each of these
report_threads will cause a method to be spawned on the TMR server to
service the message coming from the source host. This means RPC thread
usage for each method. Each message will use a session, and each session
that is being used to pass these messages across to the TMR server is also
using an RPC thread.

The implications of this on RPC thread usage is high, and the possibility
of exhausting RPC threads is a high. If you exhaust RPC threads, many bad
thing can result - epmgr hangs, oserv crash, gateway hangs, all much worse
than slow reporting.

I'd like to suggest a better approach that is less likely to put stress on
the environment -

Reduce the conn_retry_interval on the source host to 60 seconds. When the
report_thread limit is reached the source host will wait for
conn_retry_interval seconds before it tries to send a new set of messages
across to the TMR server. The default is 900 seconds, hence the performance
problems seen with reporting.

One word of caution - the source host should not have endpoints logged into
it if it is a gateway.


Gary R. Hamilton
Team Leader
Senior Software Engineer
IBM Software Group - Tivoli Software (UK)
Global Response Team - Europe/Middle East/Africa
+44(0)1753-780-988
mobile: +44(0)780-820-3714
e-mail:hamilgar-ygUJEDcBm8rQT0dZR+AlfA@xxxxxxxxxxxxxxxx
____________________________________________
AskTivoli -  http://www-3.ibm.com/software/sysmgmt/products/support/
Web PMR submission - http://www-3.ibm.com/software/support/probsub.html


                                                                           
             "Cyr,Kevin J"                                                 
             <KCYR@stpaultrave                                             
             lers.com>                                                  To 
             Sent by:                  
tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx              
             owner-tme10@lists                                          cc 
             .us.ibm.com                                                   
                                                                   Subject 
                                       RE: [tme10] wmdist -l notification  
             28/01/2005 16:10          interval                            
                                                                           
                                                                           
             Please respond to                                             
                   tme10                                                   
                                                                           
                                                                           




This isn't exactly you're your question but it is related.
In order to get timely status back from MDIST2, you need to set the SWD
report_threads_limit on your TMR to 1 higher than the total of your
MDIST2 high + Med + low sessions.
To get the mdist2 high, med, low sessions run:
wmdist -s tmrname  (where tmrname is your tmr name i.e. wtmrname)

To set the report_threads_limit run:
wswdcfg -s report_threads_limit=

To display the report_thread_limit run:
wswdcfg -s



-----Original Message-----
From: Brian Graham [mailto:brian_graham-9LkaxTQlAnxWk0Htik3J/w@xxxxxxxxxxxxxxxx]
Sent: Wednesday, January 26, 2005 8:01 PM
To: tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
Subject: RE: [tme10] wmdist -l notification interval


The messages should come back one level higher than what you launched
the distribution as. If you launched the distribution as high, I believe
the messages still only come back as high. This notify_interval
parameter is one of the mdist2 parameters that you can override on a per
distribution basis. I would suggest setting the mdist2 defaults to
something more reasonable, like 10 or 15 minutes, then from time to time
you might take advantage of overriding mdist2 settings with a 1 minute
or so notify_interval, for example, if you have a distribution to a
smaller number of targets.

Brian Graham
Gulf Breeze Software
www.gulfsoft.com

-----Original Message-----
From: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx 
[mailto:owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx]
On Behalf Of Bernard J. Duffy
Sent: Wednesday, January 26, 2005 5:54 PM
To: tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
Subject: Re: [tme10] wmdist -l notification interval

Raluca -

I'd advise you to use caution when adjusting these settings on a
production system, particularly with large distributions. If you
"spam" your repeaters with result distributions, the result
distributions (which are usually "high" priority) can drown out other
software distribution, inventory or monitoring distributions.

Good luck,

Brian Duffy
brian.duffy-zVgB07JTx4c4Xc9VQZkPiQ@xxxxxxxxxxxxxxxx

On Wed, 26 Jan 2005 15:07:12 +0200, Raluca Baciu
<raluca.baciu-6LgcLTd9A25hl2p70BpVqQ@xxxxxxxxxxxxxxxx> wrote:
>
> thanks attila, now is clear.
>
> Raluca Baciu
>
> Business Information Systems S.R.L. (BIS)
> 746741 Bucharest, Lucretiu Patrascanu Street, Bl. MY3, 5th Floor,
Sector 3
> P.O. BOX: 37-166
> Tel/Fax:  +40 21 255 45 77, +40 21 255 45 78
> Mobile: +40 0722 302 270
> Web: http://www.bisnet.ro
>
>
> This message is strictly confidential, between the emitter's and the
> addressee's companies.
> It's mandatory to have the approval of the initiator, to send it
entirely or
> partially, to a third company.
>
> Acest mesaj este strict confidential, pentru companiile emitentului si
> receptorului.
> Pentru a putea fi transmis, intreg sau partial, unei terte companii,
este
> obligatoriu a avea aprobarea initiatorului
>
> ----- Original Message -----
> From: Peter, Attila
> To: 'tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx'
> Sent: Wednesday, January 26, 2005 2:40 PM
> Subject: RE: [tme10] wmdist -l notification interval
>
>
> The default notification interval is not 1 minute but much higher (I
guess
> 30).
> During a distribution the results of the dist are first stored on the
> closest repeaters
> of the targets and pushed higher in the repeater hierarchy when:
>
> 1. all targets are completed
>      - or -
> 2. the notification interval expires
>
> In other words if you distribute to 100 eps and those are complete
within 10
> minutes
> you get the results in a bunch after ~10 minutes. If, however, only 60
are
> completed within
> 30 minutes (default notification int) you will get only those
reported.
>
> Attila
>
>
>  ________________________________
>  From: owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
[mailto:owner-tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx] On
> Behalf Of Raluca Baciu
> Sent: Mittwoch, 26. Januar 2005 13:26
> To: tme10-XtjxT7Vmt5b1ENwx4SLHqw@xxxxxxxxxxxxxxxx
> Subject: [tme10] wmdist -l notification interval
>
>
>
> Hi list,
>
> can someone please tell me why if i distribute to let's say 100 eps an
inv
> or sd profile, wmdist -e dist_id shows waiting  for all subscribers
until it
> completes on all nodes and then at a certain moment returns the status
for
> all subscribers? i cannot find where form i can set the time this
> information is refreshed, i understand that default notification
interval is
> 1 minute, but I wait let's say 10 minutes and then the status for all
> targets is updated.
>
>
> thanks,
> Raluca Baciu
>
> Business Information Systems S.R.L. (BIS)
> 746741 Bucharest, Lucretiu Patrascanu Street, Bl. MY3, 5th Floor,
Sector 3
> P.O. BOX: 37-166
> Tel/Fax:  +40 21 255 45 77, +40 21 255 45 78
> Mobile: +40 0722 302 270
> Web: http://www.bisnet.ro
>
>




==============================================================================

This communication, together with any attachments hereto or links contained
herein, is for the sole use of the intended recipient(s) and may contain
information that is confidential or legally protected. If you are not the
intended recipient, you are hereby notified that any review, disclosure,
copying, dissemination, distribution or use of this communication is
STRICTLY PROHIBITED.  If you have received this communication in error,
please notify the sender immediately by return e-mail message and delete
the original and all copies of the communication, along with any
attachments hereto or links herein, from your system.

==============================================================================

The St. Paul Travelers e-mail system made this annotation on 01/28/2005,
11:10:26 AM.