| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Aging messages on a transmission queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| bcostacurta |
 Posted: Fri Jan 22, 2010 3:12 am Post subject: Aging messages on a transmission queue |
 |
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
Hello,
I received regular aging message from a transmission xmitq on a working sender channel.
Number of message are +- 100.000 for 24hours (activity is 24/24h) and are equally distributed.
The depth of xmitq is 5.000 (and far to be reached as far I can see).
Sometimes xmitq is decreasing very slowly with only few messages per seconds.
In which direction I should investigate ?
Network performance issue ?
Application values (e.g. size of messages) ?
Receiver setups ?
Some interesting logs to be monitored ?
MQ Sender is Solaris and receiver is z/OS
Thanks for your help
Hereafter, the sender channel and wmitq params are :
CHANNEL(SPFR.TO.QCE1) CHLTYPE(SDR)
TRPTYPE(TCP) DESCR( )
XMITQ(HXSPFR.SPFRQCE1.XMT0) MCANAME( )
MODENAME( ) TPNAME( )
BATCHSZ(50) DISCINT(3600)
SHORTRTY(120) SHORTTMR(60)
LONGRTY(240) LONGTMR(360)
SCYEXIT( ) SEQWRAP(999999999)
MAXMSGL(4194304) CONVERT(YES)
SCYDATA( ) USERID( )
PASSWORD( ) MCATYPE(PROCESS)
CONNAME(xxxx(1414)) HBINT(300)
BATCHINT(0) NPMSPEED(FAST)
SSLCIPH( ) BATCHHB(0)
LOCLADDR( ) KAINT(AUTO)
MCAUSER( ) ALTDATE(2009-09-02)
ALTTIME(14.53.21) SSLPEER()
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )
The xmitq params are :
DESCR(Transmission queue vers QCE1) PROCESS( )
BOQNAME( ) INITQ(SYSTEM.CHANNEL.INITQ)
TRIGDATA(SPFR.TO.QCE1) CLUSTER( )
CLUSNL( ) QUEUE(HXSPFR.SPFRQCE1.XMT0)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(YES)
MAXDEPTH(5000) MAXMSGL(10485760)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(XMITQ) TRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(ENABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) NPMCLASS(NORMAL)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(1) OPPROCS(1)
CURDEPTH(0)
Thanks for your attention and help.
Bruno |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jan 22, 2010 3:46 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
CPU could be an issue too, or combinations of some of the issues you mentioned.
of course a look into the mq logs at both ends should be done to check if there is anything related to overall mq performance or to your specific channel. if everything is fine in the logs i would check cpu and network (check both ends).
also good to know if the application message size is constant or varying.
good luck!
_________________
Regards, Butcher |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 22, 2010 4:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
It could also be the applications fault. If on Solaris they put a message under syncpoint destined for z/OS and then don't commit that messages for 1 second for whatever reason, it will sit on the XMITQ until released.
To confirm this theory when I suspect it I put 100 persistent test messages thru my test queues over that channel. If they zoom thru but the XMITQ depth is still going up and down slowly, that proves the channel is fine and it is the app that is holding them back.
Another thing to check is the Message Retry Count and Message Retry Interval of the the RCVR channel. Read about them in the MQ Info Center, and then check out the values on your RCVR channel. Maybe you have some full queues occasionally on the z/OS side?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
