| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| when mq write message on Disc |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Wed Jul 01, 2009 1:49 pm Post subject: |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
I guess I'm confused by the answers to my long list of questions, and what conclusions it led me to - likely incorrectly.
If your messages are persistent, they will be logged multiple times. At the very least when the msg is put to the destination queue and when the msg is mqget from the destination queue.
These message ( which we are now working to debug the slowness problem) are request/reply and to the best of my knowledge, they are not persistent.
You didn't say if the destination queue is local to the qmgr where the requesting app mqconnects, only that the queue is clustered. Does an instance of the clustered queue exist on the qmgr where the app mqconnects?
No. The frontend queue managers only hold local queue for reply not for request.
It appears that your app is using a modified request-reply model. Modified in the sense that the requesting app does not create a dynamic queue for the replying app to send the reply msg. I gather that some pre-defined queue is used for the reply msg. Yes?
Yes, the reply to queues are predefined.
If no local instance of the request clustered queue exists on the front end qmgr, then the msg ends up in the cluster xmit queue, then it is logged at mqput by the app, and mqget by the mca. The msg will be logged again at the destination qmgr at mqput to the destination queue, and again when mqget by the replying app.
The return trip will entail the same logging - disk writes.
Client apps have additional network flows as the qmgr sends CC/RC for each and every MQ call. Client apps are not the stellar performers that a server-bindings app (app and qmgr on the same o/s instance). |
To add why I am going such as details for disk i/o is that, some of the frontend queue managers are on VMware. And we observed that vm boxes are causing problem. We are still in investigating but one observation from the Windows folks is that the the slow response in PAN (proactive Net) corelates with high disk I/o in these vitual box. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jul 01, 2009 2:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| frontend queue managers are on VMware |
VMWare will have a noticable impact (paging i/o) when the hardware platform does not have sufficient RAM.
On the VMWare guest, click VMWare Player, click Troubleshoot, click Change Memory Allocation. Observe the max, min and recommended, virtual machine size. Does your hardware have this much RAM allocated to the VMWare image? How many other vmware images are there on the box? How much total RAM?
If it is set to maximum (3g on my test image), try reducing it to reduce paging. I reduce mine to minimum; but mine is just a test image.
So, I guess I should now ask are there new vmware images on the box? Was more RAM installed to compensate for the new demand?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jeevan |
| Posted: Wed Jul 01, 2009 2:15 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| frontend queue managers are on VMware |
VMWare will have a noticable impact (paging i/o) when the hardware platform does not have sufficient RAM.
On the VMWare guest, click VMWare Player, click Troubleshoot, click Change Memory Allocation. Observe the max, min and recommended, virtual machine size. Does your hardware have this much RAM allocated to the VMWare image? How many other vmware images are there on the box? How much total RAM?
If it is set to maximum (3g on my test image), try reducing it to reduce paging. I reduce mine to minimum; but mine is just a test image.
So, I guess I should now ask are there new vmware images on the box? Was more RAM installed to compensate for the new demand? |
Windows folks have answers to these questions. What I know is, each of the vm box where our mq qmgr reside, are on different physical server. However, there are other vm on that physical server.
Thank you very much for all your questions which led me to think more critically. We are narrowing down the problem to vmware. The windows folks are still working to pinpoint the exact cause for that.
thanks once again, |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
