| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Restarting QM - Temporarily Solves Performance Issues? |
« View previous topic :: View next topic » |
| Author |
Message
|
| FPOV |
 Posted: Fri Oct 19, 2007 1:58 am Post subject: Restarting QM - Temporarily Solves Performance Issues? |
 |
|
Newbie
Joined: 19 Oct 2007
Posts: 5
|
We have an MQ client v. 5.3 connecting to a server v. 5.3 on Windows and furthermore to MQ on z/OS.
Occassionally the application using the client is getting data from the mainframe so slow, that the entire business process is broken.
We have done some invetsigations on the network, and as usual ... there's no problems with the network 
---
On the serverside, we get the classical AMQ9208 error.
---
Configuration:
XMIT CONFIGURATION:
AMQ8414: Display Channel details.
CHANNEL(SERVER_MAINFR) CHLTYPE(SDR)
TRPTYPE(TCP) DESCR(XMITCH)
XMITQ(XXXX) MCANAME( )
MODENAME( ) TPNAME( )
BATCHSZ(50) DISCINT(600)
SHORTRTY(40) SHORTTMR(15)
LONGRTY(999999999) LONGTMR(30)
SCYEXIT( ) SEQWRAP(999999999)
MAXMSGL(104857600) CONVERT(YES)
SCYDATA( ) USERID( )
PASSWORD( ) MCATYPE(PROCESS)
CONNAME(host.name.space(1414)) HBINT(300)
BATCHINT(0) NPMSPEED(FAST)
SSLCIPH( ) BATCHHB(0)
LOCLADDR( ) KAINT(AUTO)
MCAUSER( ) ALTDATE(2004-05-15)
ALTTIME(16.13.02) SSLPEER()
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )
AMQ8409: Display Queue details.
DESCR(XMITQ) PROCESS( )
BOQNAME( ) INITQ(SYSTEM.CHANNEL.INITQ)
TRIGDATA(SERVER_MAINFR) CLUSTER( )
CLUSNL( ) QUEUE(XXXX)
CRDATE(2001-04-30) CRTIME(11.11.05)
ALTDATE(2007-10-19) ALTTIME(06.52.3
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(10000) MAXMSGL(104857600)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(FIFO) RETINTVL(999999999)
USAGE(XMITQ) TRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(1)
OPPROCS(7675) CURDEPTH(0)
RCVR Configuration:
AMQ8414: Display Channel details.
CHANNEL(MAINFR_SERVER) CHLTYPE(RCVR)
TRPTYPE(TCP) DESCR(RCVRCH)
BATCHSZ(50) SCYEXIT( )
SEQWRAP(999999999) MAXMSGL(104857600)
PUTAUT(DEF) SCYDATA( )
MREXIT( ) MRDATA( )
MRRTY(10) MRTMR(1000)
HBINT(300) NPMSPEED(FAST)
SSLCIPH( ) SSLCAUTH(REQUIRED)
KAINT(AUTO) MCAUSER( )
ALTDATE(2003-03-26) ALTTIME(11.32.37)
SSLPEER()
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )
AMQ8409: Display Queue details.
DESCR(Data) PROCESS( )
BOQNAME( ) INITQ( )
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(REPLY)
CRDATE(2001-04-30) CRTIME(11.11.0
ALTDATE(2005-12-07) ALTTIME(17.49.46)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(50000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(FIFO) RETINTVL(999999999)
USAGE(NORMAL) NOTRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(1287)
OPPROCS(1) CURDEPTH(6029)
The problem is that restarting QM solves the problem if the CURDEPTH is hig or low on the reply queue. I'm also having concerns about the open procedures on the transmission queue, where every client has 6 connections per thread.
I don't think this is an MQ problem ... however, since a QM restart solves it temporarily, everyone is pointing at me.
Any feedback is appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Oct 19, 2007 3:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Check max active channels and channels in use "dis chs(*)"
You could be hitting the max # of channels and waiting for a channel to be freed before being able to use another one.
Make sure the connecting applications are closing their channel when they are done.
If the svrconn channels max out your # of channels the sender/receiver to /from the mainframe may not be able to start...
If you issued a stop channel mode(force|terminate) wait for the offending channel to stop and issue a start channel does it have the same effect as recycling the qmgr?
The default number of channels is certainly not adequate for a "concentrator" where the svrconn channels will push you to the limit fast...
Changing the max channels/ max active channels you will have to restart the qmgr for it to take effect.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| FPOV |
| Posted: Fri Oct 19, 2007 3:43 am Post subject: |
|
|
Newbie
Joined: 19 Oct 2007
Posts: 5
|
Thank you for your reply.
We checked the channels, and the problem occurs with low and high impact on the system.
Currently we're running 1300 active channels, and no problems.
Last week we had 10 times less traffic and restart helped for 15 minutes before the problem came back.
---
It seems that the client waits 15 seconds before it gives up.
I suspect the disconnection to be broken, hence the error messages.
What's worrying me is that a restart seems to help, but I may be tricked
---
We didn't try to recycle, only stop and start in a controlled manner because this was known as the temporary solution. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 19, 2007 3:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Examine your log file space on both qmgrs.
Also confirm that the application is or is not using transactions, and that they are committing them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 19, 2007 12:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Flex your finger and point back at them and say when you restart the QM it causes the client code to go down a different path that might include code that fixes the issue on their side.
It might be a problem on your side, can't tell from here, but the logic of "If you restart the QM and it fixes it means its a QM problem" may be flawed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| FPOV |
| Posted: Thu Nov 01, 2007 10:56 pm Post subject: |
|
|
Newbie
Joined: 19 Oct 2007
Posts: 5
|
For your information, the problem is now pinpointed to a webservice.
The webservice receives an XML with a request for MQ. The time from the webservice receives the XM to the MQPUT is sent, is sometimes above 15 seconds, hence the client receives a message that MQ did not respond, and the connection is broken.
We do not have any transactions here although you may call them UOWs.
The COM+ components used as a backend for the WS, does an MQ commit, but only to measure the time.
We have used several tools to measure the MQ protocol, Vantage, WireShark and native tools. The responstime is very good and sometimes 10/1000 of a second.
Thank you for all your input.
Live long and prosper.
With Regards
Filip Poverud |
|
| 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
|
|
|
|
