Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
I thought that it was done in 5.2, but as they say: "The second thing that goes as you get older is your memory. I can't remember what the first thing was!" I guess that's one for the Hursley folks to comment on. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Dave, my tests were run on 5.2.1 CSD05. I don't believe that feature was implemented at that level, was it? -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 4:29 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Peter, >The one thing I still do not understand is why a 75K NP message >going thru FAST channels only does not require disk. If the default buffer >is 64K, does not the 75K message being placed into the XMIT queue leaving >the HUB require disk? I think I can answer that. If the message is being MQPUT by the receiving channel to an onward XMIT queue *and* the sending channel that is reading that XMIT queue has an MQGET outstanding that the message satisfies, then the message will be passed directly to the application buffer of the sending channel. Voila, no disk I/O. At least that's how I think it works in the current releases of MQ. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Peter, >The one thing I still do not understand is why a 75K NP message >going thru FAST channels only does not require disk. If the default buffer >is 64K, does not the 75K message being placed into the XMIT queue leaving >the HUB require disk? I think I can answer that. If the message is being MQPUT by the receiving channel to an onward XMIT queue *and* the sending channel that is reading that XMIT queue has an MQGET outstanding that the message satisfies, then the message will be passed directly to the application buffer of the sending channel. Voila, no disk I/O. At least that's how I think it works in the current releases of MQ. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
NP messages sent over NORMAL channels cause messages to be written to the channel sync queues. As a result, NP application messages in this case indirectly rely on disk. If the main reason you are using NP is because there is no I/O, make sure your channels are FAST and accept the fact that the message may be lost between point A and point B, and realize there will still be disk I/O at channel start/stop. As far as using NP versus P messages, here is my response that I cut and paste from another branch of this thread that you may not have seen. that branch also summarizes all my test results. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> > About the messages being non persistent / persistent and the channel speed: > > Even though the messages are non persistent, I still care about them. I have > always been of the mind set that whether a message is persistent or not has > more to do with how difficult it is for the apps to reproduce the message if > it got lost. If it is a big deal, then make it persistent. It will survive > anything and eventually be processed. Messages that tend to sit in queues > for a long time are susceptible to QMs going down, and thus should be made > persistent if they need to survive. > > The messages in this app are inquiry style. They are invalid 5 seconds after > the fact. Even if they were persistent and survived a QM restart, they would > still be invalid, so why incur the performance penalties of persistence? > Now, that's not to say we don't care if they get lost or not. I always shake > my head when I hear people say "I made it non persistent because I don't > care if it gets lost or not". If you don't care, why did you bother to send > it in the first place?!?!? What if MQ was losing 50% of the nonpersistent > messages? I couldn't tell the app "Hey just resend them, they are only > inquiry messages anyway!" Nor could I say, "Every message in this company is > going to be persistent. We don't want to bother with lost messages ever". > Its my job to config MQ to be as reliable as possible. > > An application that sends non persistent inquiry messages that will be > invalid in 5 seconds has a reasonable assumption that MQ will do everything > it can to deliver them. Just because they don't need to survive a QM restart > doesn't mean they are less important. > > I feel the happy medium between "Make all message persistent" and "Don't > expect all your messages to always make it to the other side" is to set the > message channel speed to normal, as long as conditions warrant it. If you > got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly > back up, and the occasional non persistent message is being held back until > the batch commits, then no way, the speed should be fast, and live with the > fact that it may get lost. > > But I bet that is not how many of anybody's channels run. I bet most of us> > have XMIT queues that are normally empty, and the BATCHINT is still set to > the default of 0. In this case, setting the speed to normal will have very > little effect on overall performance, but will insure that no messages ever > get lost. > > I wonder why IBM choose to have the default setting of the channel speed set > to fast? Seems to me it would be better to make the default normal. This > would perform just fine for most people and would help MQ's rep of never > losing messages. You have no idea what a pain it was discovering that MQ was > losing messages over a particular fast channel. Days of blaming the apps > with losing the messages, hunting in DLQs all over the place, XMIT queues, > application queues, etc. The real kick in the pants is that when a message > is lost like this, there is ZERO record of the fact. You are left scratching > you head. The man hours wasted on hunting for a message lost like this is > just not worth it. I'll gladly take a tiny performance hit in a tiny > percentage of the messages I send over an already very fast product. > > Any people looking to pump up the performance of a channel above and beyond > this could then tweak the channel to fast, only after realizing messages > could get lost. Maybe when it was time to decide what value to use as a > default, the logic was "We have a choice of making our product faster out of > the box or making our message delivery more assured out of the box". And the > choice was to make it
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Stephan, I agree that it would be foolish to have a set up where a 100MEG P message shared a channel with small NP messages. The reason I chose it was to give an example of where under normal conditions (no disk outage) an MCA might be busy and what would happen if a higher priority NP message showed up. If that MCA is busy, as it would for quite some time while dealing with a 100 MEG lunker, priority will not help. Rereading your message, I think we were considering an MCA as busy in 2 different ways. I meant it as the MCA is busy processing a single message. I think your suggestion was geared to a busy MCA as in the MCA is busy working all day long processing thousands of messages. Certainly in that case, where XMIT queues might be backing up, Priority would help in getting the NP guys across sooner by letting them cut in line to get a front seat on the MQ-Roller-Coaster to the next QM. But if a channel set up for huge messages only was processing a 100MEG persistent message, and a higher priority 100MEG non persistent message landed on the queue, priority would make no difference. Forget about the logic of making a 100MEG message non persistent. I am using these exaggerated numbers to make the point. NP messages (regardless of the channel speed) do count towards the BATCH counts on a channel, but are not held back by them (i.e. they are available to the other side without waiting for the BATCH to complete). From Chapter 6 of the Intercommunication guide under BATCHINT: Even though nonpersistent messages on a fast channel do not wait for a syncpoint, they do contribute to the batch-size count. Thanks for clarifying why the QMAliases do not use disk I/O regardless of message size or persistence attribute. That makes sense. My testing has shown that NP messages will only rely on the disk on the HUB if the channel speeds are NORMAL. If the channel speed is FAST, I was able to pull all the cables to the SAN for the server, and even thought the QM had ZERO access to disk, the NP message passed thru no problem. When I changed the speed to normal, the QM wanted to write persistent messages to the channel sync queues to keep track of the NP application messages, and thus all of the sudden became reliant on disk to process NP application messages. Pulling the disk now caused a blockage at the XMIT queue of the spoke QM. The one thing I still do not understand is why a 75K NP message going thru FAST channels only does not require disk. If the default buffer is 64K, does not the 75K message being placed into the XMIT queue leaving the HUB require disk? My testing says no. Makes no sense. I am at 5.2.1 for this test. I have opened a ticket with IBM on this point. I don't know if I can say I completely removed NP I/O (the start up and shutdown of the channel still needed I/O), but when I set the channel to FAST, and only sent NP messages over this dedicated NP channel, I was able to yank disk access for a full 5 minutes with no effect at all on message throughput for this channel. At the same time, other channels were backed up, either because they were set to normal, and/or there were persistent message going thru those channels. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages In regards to sending a "100 MB lunker" I certainly wouldn't want to be sending messages of this size on a production channel with a regular volume of messages to transmit - especially one that handled interactive applications and/or required predictable response times. Instead, a second channel needs to be created to handle messages of this size. Therefore the question about "a higher priority message will somehow jump over the big one" is a moot point. It will never happen because you would never design a system this way. To answer your question directly, once a message is being transmitted, it can't be interrupted by a higher-priority message. In regards to "if the MCA is busy, priority will not help", I beg to differ. It may not help in all cases, but it definitely improves the situation from the spoke's perspective. The only time where priority does not work is if a higher-priority message comes in after a message is actively being transmitted. Once that message is transmitted, the same sequence of events applies again; highest priority messages get transmitted first in a FIFO order. Since the MCA takes messages out of the highest-priority queue down to the lowest priority queue (10 queues in all; 0-9), if the NP messages are tagged with a higher-priority then your persistent messages, the NP messages get transmitted first. This is a better solution then having NP and persistent messages intertwined on the same priority queue - since th
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Some ideas...
o The letter from Stephen provides good rules of thumb. Especially about
separating channels for differing messages and types.
o I have seen where non-persistent messages over "FAST" channels can get
lost. Add the MQ Internet Pass-Thru support pac, MS81, between 2 QMgrs and
one can reproduce lost messages quickly. I had an open call with the
Hursley developer and the problem was answered as an MQ feature.
o What about "pipelining" the MCA. This feature was provided with v5.2.
o This thread has kind-of lost scope. Can someone summarize where things
are? What questions have been answered?
o Lastly... Remember there is a reason why non-persistent messages exist.
They can be lost. Therefore, if you can't afford messages to be lost then
don't make it non-persistent.
-B
Brian Bumpass
Wachovia Bank
Enterprise Infrastructure
[EMAIL PROTECTED]
Phone - (704) 590-5620
Pager - (800) 425-2613
-Original Message-
From: Stephan C. Moen [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: How a MQSeries Hub does its thing with persistent /
non-persi stent messages
In regards to sending a "100 MB lunker" I certainly wouldn't want to be
sending messages of this size on a production channel with a regular volume
of messages to transmit - especially one that handled interactive
applications and/or required predictable response times. Instead, a second
channel needs to be created to handle messages of this size. Therefore the
question about "a higher priority message will somehow jump over the big
one" is a moot point. It will never happen because you would never design a
system this way. To answer your question directly, once a message is being
transmitted, it can't be interrupted by a higher-priority message.
In regards to "if the MCA is busy, priority will not help", I beg to differ.
It may not help in all cases, but it definitely improves the situation from
the spoke's perspective. The only time where priority does not work is if a
higher-priority message comes in after a message is actively being
transmitted. Once that message is transmitted, the same sequence of events
applies again; highest priority messages get transmitted first in a FIFO
order. Since the MCA takes messages out of the highest-priority queue down
to the lowest priority queue (10 queues in all; 0-9), if the NP messages are
tagged with a higher-priority then your persistent messages, the NP messages
get transmitted first. This is a better solution then having NP and
persistent messages intertwined on the same priority queue - since they get
transmitted on a FIFO basis.
Though I have never looked into the specific case of NP messages being sent
with persistent messages within a channel batch job, I always assumed
(according to the MQ documentation) that NP messages sent on a FAST channel
fall outside the channel batch mechanism (BATCHINT, BATCHSZ), and don't have
to wait for the end of the batch (and associated MQCMIT) before the
application sees the messages; they are sent immediately without waiting for
completion of the current batch (sent out of syncpoint). That is why NP
messages aren't counted against batch values (BATCHSZ, BATCHINT), since they
don't use sequence numbers (sequence number is not advanced when a NP
messages is sent) and are immediately visible on the receiver side. The
side effect for this performance trade-off is that this may cause NP
messages to be processed out-of-order or lost due to transmission failures.
If this is not true, somebody please correct my erroneous assertion.
In regards to Question 1 ("is there any data/messages being written to disk
by QMHUB as the messages fly thru"), since the ORIGINAL question referenced
ALIAS queues on QMHUB and since an alias queue is not a real queue (and
therefore has no filename or disk allocated to it), I can only assume that
if an NP message on MQHUB encounters disk I/O, it must be related to PAGING
I/O (not enough memory on this box to handle the workload currently
configured). Remember the original question refers to disk I/O on QMHUB -
not
the spokes. If this is the case (someone please prove me wrong), then
whatever you do to the MQSeries configuration, won't make any difference.
The only solution is to add more memory to that box OR configure your memory
(if the OS will allow you to; use the 'vmtune' command on AIX) so that more
memory is allocated to computational memory (e.g., process working set)
versus persistent memory (e.g., files that have a hard disk location). With
the exception of the XMIT queues on QMHUB, 'qalias' definitions don't have
an associated 'DefaultQBufferSize' attribute have some have stated, and
therefore don't apply as a solution to this issue.
For the case referenced earlier in this thread where the local queue fil
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
channels) is suspended waiting for disk I/O to complete AND the daemon process has not yet consumed it's entire CPU timeslot, then the CPU is granted to another thread within that process. Therefore, work is still performed and minimal idle time is spent by NP messages that are waiting for disk I/O to complete generated by persistent messages. If your using the 'inetd' daemon to spawn off new channels (e.g., amqcrsta), once that process has to write to disk, that process is suspended and put back on the CPU run queue. From my perspective, using 'runmqlsr' eliminates the need to have BOTH 'fast' and 'normal' channels. No matter what solution you pick, you are not going to completely eliminate NP disk I/O. These 'suggestions' has minimal impact from a configuration and administration perspective and that is why they were volunteered. -----Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, June 06, 2003 1:16 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Didn't see your response before I sent mine. An MCA issues an I/O request to the OS. I do not believe that THAT MCA is brave enough to do other work asynchronously while the I/O is pending. All work with respect to that MCA stops, the CPU is thus freed to serve other MCA's that may not require disk. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > An application is sending NP messages, priority 9. Another app sends P > messages, priority 1. Odds are both apps are sending messages somewhat > regularly. When things are fine, the NP messages jump to the head of the > line and zoom across. But sooner or later, those persistent messages are > going get their turn in line and be shipped. And if the other side is having > disk problems, what happens then? Are NP messages produced after this point > stuck waiting, because the MCA is busy with the persistent message, waiting > for a response? Or are you saying that they will pass the stuck persistent > message? > > Same question when everything is OK. If a 100MEG lunker is taking its time > to be shipped, are you saying that a higher priority message will somehow > jump over the big one? > > I gotta think that if the MCA is busy (either moving a big message or stuck > waiting for I/O), Priority will not help. > > -Original Message- > From: Stephan C. Moen [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling hol
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Didn't see your response before I sent mine. An MCA issues an I/O request to the OS. I do not believe that THAT MCA is brave enough to do other work asynchronously while the I/O is pending. All work with respect to that MCA stops, the CPU is thus freed to serve other MCA's that may not require disk. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > An application is sending NP messages, priority 9. Another app sends P > messages, priority 1. Odds are both apps are sending messages somewhat > regularly. When things are fine, the NP messages jump to the head of the > line and zoom across. But sooner or later, those persistent messages are > going get their turn in line and be shipped. And if the other side is having > disk problems, what happens then? Are NP messages produced after this point > stuck waiting, because the MCA is busy with the persistent message, waiting > for a response? Or are you saying that they will pass the stuck persistent > message? > > Same question when everything is OK. If a 100MEG lunker is taking its time > to be shipped, are you saying that a higher priority message will somehow > jump over the big one? > > I gotta think that if the MCA is busy (either moving a big message or stuck > waiting for I/O), Priority will not help. > > -Original Message- > From: Stephan C. Moen [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling holes in your broomstick. > > I am not necessarily an advocate for separate channels, but I do think it > could improve the odds that non-persistent messages will flow when the SAN > is unavailable. Generally, while one qmgr process waits for I/O, the others> > may be dispatched to make good use of the available time, including their > own disk I/O and, hopefully, network I/O for non-persistent messages that do > not require disk. Tasks waiting on I/O do not consume--they are overlapped > with those needing CPU, lest a staggering percentage of the CPU resource > would go to waste. The notion of being a CPU being "busy waiting" is > silly--faster machines don't wait at twice the speed! > > > Point #1. If a server is dealing with persistent and non persistent > messages, the persistent ones have to negatively effect the non > persistent > ones, at a hardware level (disk and CPU). It does not matter whether > you > have separate QMs on that server split between persistent and non > persistent. Both
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
I agree with most of that, but as far as the original issues is concerned it only works up to a point. As soon as the channel hangs waiting for i/o on any persistent message, then it is blocked from moving NP messages that may appear the next instant. So unless the channel is so busy processing NP messages that it never has time for the persistent ones... > -Original Message- > From: Stephan C. Moen [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 6:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling holes in your broomstick. > > I am not necessarily an advocate for separate channels, but I do think it > could improve the odds that non-persistent messages will flow when the SAN > is unavailable. Generally, while one qmgr process waits for I/O, the others > may be dispatched to make good use of the available time, including their > own disk I/O and, hopefully, network I/O for non-persistent messages that do > not require disk. Tasks waiting on I/O do not consume--they are overlapped > with those needing CPU, lest a staggering percentage of the CPU resource > would go to waste. The notion of being a CPU being "busy waiting" is > silly--faster machines don't wait at twice the speed! > > > Point #1. If a server is dealing with persistent and non persistent > messages, the persistent ones have to negatively effect the non > persistent > ones, at a hardware level (disk and CPU). It does not matter whether > you > have separate QMs on that server split between persistent and non > persistent. Both QMs share the CPU and disk. It does not matter > whether you > have separate channels or not. All MCAs share the same CPU and disk. > > Only true if there is contention for one of the resources: CPU, memory, or > I/O. If you can dedicate a task (either by separate Qmgrs or separate > channels) to non-persistent messages that are not dependent on disk I/O,> > then you do not have competion for that resource and there would not be an > adverse affect with respect to it. > > > Point #2. If the disk is temporarily unavailable, then persistent > messages > are effected, and due to point #1, non persistent ones are effected as well. > > I agree (in a contrary way): > > If tasks handling non-persistent messages are dependent on disk, then they > may be adversely affected by the unavailable disk. > > If tasks handling non-persistent messages are not dependent on disk, then > they may be favorably affected by the unavailable disk! This occurs because > other tasks waiting on disk are not competing for CPU. > > > > -Original Message- > > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROT
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
An application is sending NP messages, priority 9. Another app sends P messages, priority 1. Odds are both apps are sending messages somewhat regularly. When things are fine, the NP messages jump to the head of the line and zoom across. But sooner or later, those persistent messages are going get their turn in line and be shipped. And if the other side is having disk problems, what happens then? Are NP messages produced after this point stuck waiting, because the MCA is busy with the persistent message, waiting for a response? Or are you saying that they will pass the stuck persistent message? Same question when everything is OK. If a 100MEG lunker is taking its time to be shipped, are you saying that a higher priority message will somehow jump over the big one? I gotta think that if the MCA is busy (either moving a big message or stuck waiting for I/O), Priority will not help. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:23 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Mess
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 1:01 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > Hi Dennis. > > I agree that non-persistent and persistent messages in a batch will be > available at the same time. But my batches are of 1 or 2 messages. Since my > BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I > am incurring any performance hit. 1 or 2 messages are sent across, mybe > message #1 is a nonpersistent that is held back until the batch completes, > but the batch completes almost immediately, since no more message have yet > arrived and the BATCHINT expires. At this point I am still not convinced, in > my scenario, that this setting has an effect for the above reason.> > > It has also been mentioned more than once to make a separate channel for > persistent vs. non-persistent messages. I don't see how that makes a > difference. So I make 2
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
s #1: As expected, constant disk writes on the server that houses HubQM1. Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #2: As expected, no disk activity at all on the server that houses HubQM1. Actually, there was disk activity when the channel started/ended, but for the whole duration while the channel was running, no I/O. Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #3: No disk activity at all on the server that houses HubQM1. ??? These messages are larger than the 64K queue buffer, so why are the messages flying thru the hub with no I/O? I am happy with these results, just that it is unexpected. Could it be that the Sending MCA to SpokeQM2 has the XMIT queue open ready for messages, with an outstanding GET? But I thought this was a feature new to 5.3 only. Test #4: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Every 45 seconds or so, I send over a Persistent 5000 byte message on the same channel. Results #4: As expected, no disk activity at all on the server that houses HubQM1, except every 45 seconds when the P message comes over. Test #5: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #5: No effect at all. Even though the server had no hard disk, these messages still kept flying thru the server as if nothing at all was wrong. Test #6: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over the same channel. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #6: Everything backs up. Both NP and P messages are backed up in the XMITQ on SPOKEQM1. As soon as the cables are plugged back in, the messages start flowing again. Test #7: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over A DIFFERENT CHANNEL between SpokeQM1 and HubQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #7: Everything backs up on the channel that was dealing with P messages. The channel that had only NP messages was not effected at all. As soon as the cables are plugged back in, the messages start flowing again on the secondary channel. The primary channel that had NP messages never blinked. So now I am kinda stuck. Back in the production environment, what to do? I can set the channel between SpokeQM1 and the HUB to fast, as it is a dedicated channel for this application anyway. I'll just let them know of the possibility (very remote) that the channel may lose their message. SAN blips are a lot more frequent than MQ losing NP messages over a FAST channel. But what do I do with the CLUSRCVR channels? They are a shared resource for the whole company. Do I let this one application dictate that these channels get switched to FAST, at the risk of other apps having NP message lost. Granted, we have a pretty reliable network here, but man, what a waste of time trying to hunt for messages that get lost over the fast channel. (For anyone just jumping into the thread now, please don't suggest that I just make the messages persistent. That is not the answer. Read the thread from the beginning to see why). What do most people out there have their Cluster channel speeds at? Dennis, you also mentioned moving the logs off of the SAN, but then that kinda defeats the purpose of having these servers HA. -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 6:59 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages In order to get the behaviour you want, the task processing NP messages must not use or be dependent on SAN I/O whatsoever. Now you don't have absolute control of the I/O that MQ uses. For example, NP messages can spill to disk if they are large or many, and sometimes MQ will use disk scratchpads for various reasons. The good news is that IBM has put a lot of effort into optimizing the throughput of NP messages, so avoids disk I/O unless absolutely necessary. I still think you are probably experiencing log I/O because the channels are doing your NP messages und
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Hi Peter,
thanks for the update and the information about your test results.
We handle this issue by running multiple overlapping clusters, and having
separate channels for each cluster.
Eg:
QM1 and QM2 are in clusters CL1 and CL2.
Rather than-
DEFINE NAMELIST(ClusList) names('CL1,CL2') and
DEFINE chl(TO.QM1) chltype(CLUSRCVR) ... clusnl(ClusList)
we would-
DEFINE CHL(TO.QM1.CL1) chltype(CLUSRCVR)... cluster(CL1) and
DEFINE CHL(TO.QM1.CL2) chltype(CLUSRCVR)... cluster(CL2).
ie a separate channel is used in each cluster.
This lets us put different NPMSPEED, SSL and other parameters on channels
for different uses (clusters), even when they go to the same queue manager.
Our naming standards limit the length of a queue manager name to 8
characters, and also limit cluster names to 8 characters, which means that
our channels names are no more than 20 characters.
In your environment, you could build an new cluster for this application
(you can still use the same queue managers as repositories - just use
namelists to list the clusters you want to host). The high performance
queues live in the new cluster with NPMSPEED(FAST). Everything else goes in
the normal cluster(s).
As always in computing, there are trade-offs to be made. In this case, you
lose some of the perceived benefits of clustering (simplicity) because you
have to build and manage multiple clusters. This makes things like stopping
a queue manager more complicated, because you have to suspend from all
clusters, not just one. You also have to make correct decisions about which
cluster(s) to connect a queue into, which makes administration more complex
(but perhaps more interesting as well).
Regards,
Neil Casey.
|-+-->
| | "Potkay, Peter M |
| | (PLC, IT)" |
| | <[EMAIL PROTECTED]|
| | RTFORD.COM>|
| | Sent by: MQSeries |
| | List |
| | <[EMAIL PROTECTED]|
| | AC.AT> |
| | |
| | |
| | 04/06/2003 01:33 |
| | Please respond to |
| | MQSeries List |
| | |
|-+-->
>--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi
stent messages|
>--|
Well, I think I have proved what everyone was saying. A channel speed of
Normal is what is getting me here. Neil Casey and Brian McCarty provided
the
exact explanation as to why: non persistent messages sent over a normal
speed channel cause persistent message to be written to the channel sync
queue, which requires disk. I set up some tests in my lab environment. Here
are the results.
*
Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03
RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue
HubQM1
Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05
QMAlias called SpokeQM2, which sends messages to transmit queue
SpokeQM2.XMITQ
Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05
Local queue called FinalQ
***
Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K
Non-Persistent(NP) messages every 250 milliseconds to the remote queue def
on SpokeQM1.
Results #1: As expected, constant disk writes on the server that houses
HubQM1.
Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP
messages every 250 milliseconds to the remote queue def on SpokeQM1.
Results #2: As expected, no disk activity at all on the server that houses
HubQM1. Actually, there was disk activity when the channel started/ended,
but for the whole duration while the channel was running, no I/O.
Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000
byte NP messages every 250 milliseconds to the remote queue def on
SpokeQM1.
Results #3: No disk activity at all on the server that houses HubQM1. ???
These messages are larger than the 64K queue buffer, so why are the
messages
flying thru the hub with no I/O?
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
e new to 5.3 only. Test #4: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Every 45 seconds or so, I send over a Persistent 5000 byte message on the same channel. Results #4: As expected, no disk activity at all on the server that houses HubQM1, except every 45 seconds when the P message comes over. Test #5: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #5: No effect at all. Even though the server had no hard disk, these messages still kept flying thru the server as if nothing at all was wrong. Test #6: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over the same channel. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #6: Everything backs up. Both NP and P messages are backed up in the XMITQ on SPOKEQM1. As soon as the cables are plugged back in, the messages start flowing again. Test #7: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over A DIFFERENT CHANNEL between SpokeQM1 and HubQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #7: Everything backs up on the channel that was dealing with P messages. The channel that had only NP messages was not effected at all. As soon as the cables are plugged back in, the messages start flowing again on the secondary channel. The primary channel that had NP messages never blinked. So now I am kinda stuck. Back in the production environment, what to do? I can set the channel between SpokeQM1 and the HUB to fast, as it is a dedicated channel for this application anyway. I'll just let them know of the possibility (very remote) that the channel may lose their message. SAN blips are a lot more frequent than MQ losing NP messages over a FAST channel. But what do I do with the CLUSRCVR channels? They are a shared resource for the whole company. Do I let this one application dictate that these channels get switched to FAST, at the risk of other apps having NP message lost. Granted, we have a pretty reliable network here, but man, what a waste of time trying to hunt for messages that get lost over the fast channel. (For anyone just jumping into the thread now, please don't suggest that I just make the messages persistent. That is not the answer. Read the thread from the beginning to see why). What do most people out there have their Cluster channel speeds at? Dennis, you also mentioned moving the logs off of the SAN, but then that kinda defeats the purpose of having these servers HA. -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 6:59 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages In order to get the behaviour you want, the task processing NP messages must not use or be dependent on SAN I/O whatsoever. Now you don't have absolute control of the I/O that MQ uses. For example, NP messages can spill to disk if they are large or many, and sometimes MQ will use disk scratchpads for various reasons. The good news is that IBM has put a lot of effort into optimizing the throughput of NP messages, so avoids disk I/O unless absolutely necessary. I still think you are probably experiencing log I/O because the channels are doing your NP messages under syncpoint. Change your Ha-Ha channels to NPMSPEED=fast and see if it makes a difference. Ultimately, I think you need to move your logs off the SAN. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. > The only messages going over this channel are non persistent. Thousands of > messages are zooming across this channel every hour. The XMIT queue never > got deeper than 2. The speed is normal. A bin change hits our SAN, which the > HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since > then there have been no changes to the SAN, and the XMIT queue again has not > gotten over 2. This to me reinforces that
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
is not the answer. Read the thread from the beginning to see why). What do most people out there have their Cluster channel speeds at? Dennis, you also mentioned moving the logs off of the SAN, but then that kinda defeats the purpose of having these servers HA. -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 6:59 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages In order to get the behaviour you want, the task processing NP messages must not use or be dependent on SAN I/O whatsoever. Now you don't have absolute control of the I/O that MQ uses. For example, NP messages can spill to disk if they are large or many, and sometimes MQ will use disk scratchpads for various reasons. The good news is that IBM has put a lot of effort into optimizing the throughput of NP messages, so avoids disk I/O unless absolutely necessary. I still think you are probably experiencing log I/O because the channels are doing your NP messages under syncpoint. Change your Ha-Ha channels to NPMSPEED=fast and see if it makes a difference. Ultimately, I think you need to move your logs off the SAN. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. > The only messages going over this channel are non persistent. Thousands of > messages are zooming across this channel every hour. The XMIT queue never > got deeper than 2. The speed is normal. A bin change hits our SAN, which the > HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since > then there have been no changes to the SAN, and the XMIT queue again has not > gotten over 2. This to me reinforces that fact that a disk outage on the HUB > is effecting non persistent messages somehow. And I am beginning to think > there is no way around it. :( > > > > > > About the messages being non persistent / persistent and the channel speed: > > Even though the messages are non persistent, I still care about them. I have > always been of the mind set that whether a message is persistent or not has > more to do with how difficult it is for the apps to reproduce the message if > it got lost. If it is a big deal, then make it persistent. It will survive > anything and eventually be processed. Messages that tend to sit in queues > for a long time are susceptible to QMs going down, and thus should be made > persistent if they need to survive. > > The messages in this app are inquiry style. They are invalid 5 seconds after > the fact. Even if they were persistent and survived a QM restart, they would > still be invalid, so why incur the performance penalties of persistence? > Now, that's not to say we don't care if they get lost or not. I always shake > my head when I hear people say "I made it non persistent because I don't > care if it gets lost or not". If you don't care, why did you bother to send > it in the first place?!?!? What if MQ was losing 50% of the nonpersistent > messages? I couldn't tell the app "Hey just resend them, they are only > inquiry messages anyway!" Nor could I say, "Every message in this company is > going to be persistent. We don't want to bother with lost messages ever". > Its my job to config MQ to be as reliable as possible. > > An application that sends non persistent inquiry messages that will be > invalid in 5 seconds has a reasonable assumption that MQ will do everything > it can to deliver them. Just because they don't need to survive a QM restart > doesn't mean they are less important. > > I feel the happy medium between "Make all message persistent" and "Don't > expect all your messages to always make it to the other side" is to set the > message channel speed to normal, as long as conditions warrant it. If you > got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly > back up, and the occasional non persistent message is being held back until > the batch commits, then no way, the speed should be fast, and live with the > fact that it may get lost. > > But I bet that is not how many of anybody's channels run. I bet most of us> > have XMIT queues that are normally empty, and the BATCHINT is still set to > the default of 0. In this case, setting the speed to normal will have very > little effect on overall performance, but will insure that no messages ever > get lost. > > I wonder why IBM choose to have the default settin
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
So lets say that Non-Persistent messages do not take I/O and obviously Persistent messages do. The central pont of processing in MQ is the LOGs. Say MQ is chugging along doing whatever it has to and even though we thing it is doing one thing at a time because the machine can only execute one instruction at a time, in the background it is multi-tasking or lest say multi-messaging. Now you take away access to the LOGs. Persistent or Non-Persistent MQ takes a halt because a higher level function indicates it central resource is unavaliable. So everything underneath, LOG dependent or not, halts till the resource becomes available. AS Den said, put the LOGs somewhere where they will always be available. In the Admin and Setup guides don't they recomend the LOG be on seperate storage. I believe, and don't quote me, this is indicated in the OS390 performance support pack and I would think it applies to all the platforms. bobbee From: "Miller, Dennis" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Date: Fri, 30 May 2003 15:41:16 -0700 Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 1:01 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > Hi Dennis. > > I agree that non-persistent and persistent messages in a batch will be > available at the same time. But my batches are of 1 or 2 messages. Since my > BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I > am incurring any performance hit. 1 or 2 messages are sent across, mybe > message #1 is a nonpersistent that is held back until the batch completes, > but the batch completes almost immediately, since no mo
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Wasn't your origional question pertainng to what happens when you do some upgrade to the SAN and the disk is unavailable for your messaging software. Wouldn't this have the same effect on anything in your system. Why single out MQ. You could have this discussion about any piece of record processing software. If you pull the storage system away and the system backs up you will have the same adverse effect. Hopefuly you are not doing upgrades to your SAN every 1/2 hour or do it at an hour where there will be minimal impact to your messaging (and other) software on your system. MQ does have stated limitations. They additionally state that there is a certain amount of system resources required to hit this level of messaging. I would guess that as long as you provide these resources MQ will operate as prescribed. bobbee From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Date: Fri, 30 May 2003 16:01:55 -0400 I would say that all 8 WILL work at the same time, but each can only do one thing at a time. If the QM is in fact multi-threaded/processed under the covers, then at least you could have 8 "things" going on at the same time. BUT, if all 8 CPUs need to share a resource, like the disk, then are we back to square one? And even 8 CPUs in my scenario is still no big deal, since under heavy volume I am sure you can have more than 8 messages in flight INSIDE the HUB queue manager at any one time. Or if the HUB has 50 spokes, then you can 50 receiving MCAs all competing for the same 8 CPUs. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Peter, Got a question. On my arcitectural diagrams I have specifications for 8-WAY servers. I agree with you that a CPU can only do one thing at a time. While that CPU is waiting what are the other 7 doing? If the are also waiting on #1 what is the use of haveing a multi CPU machine except for IBM to charge us capasity units for MQ/MQSI/Websphere. bee-oh-dubble-bee-dubble-egh >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages >Date: Fri, 30 May 2003 08:50:12 -0400 > >Gary, > About a queue manager, or any process that runs on any computer, I >have always assumed, maybe incorrectly, that a CPU on a box can only do one >thing at a time. It may be incredibly fast, giving the illusion of many >things happening at once, but when you get right down to it, everything has >to wait its turn for the CPU to do its thing. > >And if the CPU is waiting to interact with the disk to write a persistent >(or bigger than 64k non-persistent) message (I guess even if that message >is >going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go >on >to handle non persistent messages. > >??? > > >-Original Message- >From: Gary Ward [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 29, 2003 7:47 PM >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / >non-persistent messages > > >Peter, > >I'll gladly defer to any IBM MQ Developers lurking on the list since this >is >getting really 'down and dirty', but in the meantime I'll give you another >$.02... > >Right about my answer to Q2... I guess I missed your point. Having read >your follow-up, I would offer this theory. I think the queue manager MUST >be able to do more than a single task at once. That's why it's made up of >many individual processes which have dedicated tasks. I would think at any >one moment there's a bunch of messages floating around in various states. >If the messages are non-persistent, they're not logged and hence can be >available immediately (if they're not IN SYNCPOINT with persistent >messages). Non-persistent messages only get written to disk when there's >not enough memory available to hold them on an individual queue. I'm not >sure about persistent messages always going right to the queue file system, >but my gut feeling is that they do. > >If your non-persistent messages are 100K and you have your queues set at >the >64KB default, I'm pretty sure they go right to disk. That's why you should >tune that non-persistent message buffer. Hopefully something is already &
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Now that we have 8 CPU's doing our work for us and granted they are contenting somewhere for the same thing. Are the eight CPUs operating at the same speed at which my kids deliver response to my request to extend themselves to facilitate removing the bag of overflowing garbage in my kitchen to a more appropriate spot or at the speed that electric atoms fly down a wire to a waiting chip? If it is the first and not the later I would suspect a long cold wait for service. bobbee From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Date: Fri, 30 May 2003 16:01:55 -0400 I would say that all 8 WILL work at the same time, but each can only do one thing at a time. If the QM is in fact multi-threaded/processed under the covers, then at least you could have 8 "things" going on at the same time. BUT, if all 8 CPUs need to share a resource, like the disk, then are we back to square one? And even 8 CPUs in my scenario is still no big deal, since under heavy volume I am sure you can have more than 8 messages in flight INSIDE the HUB queue manager at any one time. Or if the HUB has 50 spokes, then you can 50 receiving MCAs all competing for the same 8 CPUs. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Peter, Got a question. On my arcitectural diagrams I have specifications for 8-WAY servers. I agree with you that a CPU can only do one thing at a time. While that CPU is waiting what are the other 7 doing? If the are also waiting on #1 what is the use of haveing a multi CPU machine except for IBM to charge us capasity units for MQ/MQSI/Websphere. bee-oh-dubble-bee-dubble-egh >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages >Date: Fri, 30 May 2003 08:50:12 -0400 > >Gary, > About a queue manager, or any process that runs on any computer, I >have always assumed, maybe incorrectly, that a CPU on a box can only do one >thing at a time. It may be incredibly fast, giving the illusion of many >things happening at once, but when you get right down to it, everything has >to wait its turn for the CPU to do its thing. > >And if the CPU is waiting to interact with the disk to write a persistent >(or bigger than 64k non-persistent) message (I guess even if that message >is >going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go >on >to handle non persistent messages. > >??? > > >-Original Message- >From: Gary Ward [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 29, 2003 7:47 PM >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / >non-persistent messages > > >Peter, > >I'll gladly defer to any IBM MQ Developers lurking on the list since this >is >getting really 'down and dirty', but in the meantime I'll give you another >$.02... > >Right about my answer to Q2... I guess I missed your point. Having read >your follow-up, I would offer this theory. I think the queue manager MUST >be able to do more than a single task at once. That's why it's made up of >many individual processes which have dedicated tasks. I would think at any >one moment there's a bunch of messages floating around in various states. >If the messages are non-persistent, they're not logged and hence can be >available immediately (if they're not IN SYNCPOINT with persistent >messages). Non-persistent messages only get written to disk when there's >not enough memory available to hold them on an individual queue. I'm not >sure about persistent messages always going right to the queue file system, >but my gut feeling is that they do. > >If your non-persistent messages are 100K and you have your queues set at >the >64KB default, I'm pretty sure they go right to disk. That's why you should >tune that non-persistent message buffer. Hopefully something is already >waiting for these non-persistent messages so they get handed off directly >in >the manner that T. Rob and I mentioned earlier in this thread. Then >there's >no I/O at all. > >Hope this helps... any IBMer's want to comment > > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, >Peter M
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Hi Peter, I removed most of your message but I want to address one paragraph: -- From Peter Potkay: These are non persistent messages that are under 64K, so why does a change that makes the disk unavailable cause these messages to slow down? My guess is that the persistent messages the HUB is processing at the same time (or the >64K Nonpersistent ones) must somehow be effecting the performance of the non persistent ones. And I also assume that channel speed has nothing to do with this. Your problem is that you make an assumtion that channel sped has nothing to do with this. This assumption is not correct. In fact, NPMSPEED(NORMAL) channels perform synchronous I/O to the logs, even when processing non-persistent messages. This is because ALL messages on NPMSPEED(NORMAL) channels are put under syncpoint control, and the channel sequence numbers (which are stored in persistent messages on the SYSTEM.CHANNEL.SYNCQ) are also updated for every batch. The only way to transfer messages from one queue manager to another while avoiding synchronous log I/O is to use NPMSPEED(FAST). Of course, if you get any sort of glitch with NPMSPEED(FAST) you will lose messages, as you have noted, which leaves you stuck between the proverbial rock and hard place. Regards, Neil Casey. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
With NPMSPEED=fast, you should not lose persistent messages and you should not lose non-persistent messages except when there is somekind of channel abend. Did you experience otherwise? Do you lose more messages with NPMSPEED=fast or from SAN-related timeouts? > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. > The only messages going over this channel are non persistent. Thousands of > messages are zooming across this channel every hour. The XMIT queue never > got deeper than 2. The speed is normal. A bin change hits our SAN, which the > HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since > then there have been no changes to the SAN, and the XMIT queue again has not > gotten over 2. This to me reinforces that fact that a disk outage on the HUB > is effecting non persistent messages somehow. And I am beginning to think > there is no way around it. :( > > > > > > About the messages being non persistent / persistent and the channel speed: > > Even though the messages are non persistent, I still care about them. I have > always been of the mind set that whether a message is persistent or not has > more to do with how difficult it is for the apps to reproduce the message if > it got lost. If it is a big deal, then make it persistent. It will survive > anything and eventually be processed. Messages that tend to sit in queues > for a long time are susceptible to QMs going down, and thus should be made > persistent if they need to survive. > > The messages in this app are inquiry style. They are invalid 5 seconds after > the fact. Even if they were persistent and survived a QM restart, they would > still be invalid, so why incur the performance penalties of persistence? > Now, that's not to say we don't care if they get lost or not. I always shake > my head when I hear people say "I made it non persistent because I don't > care if it gets lost or not". If you don't care, why did you bother to send > it in the first place?!?!? What if MQ was losing 50% of the nonpersistent > messages? I couldn't tell the app "Hey just resend them, they are only > inquiry messages anyway!" Nor could I say, "Every message in this company is > going to be persistent. We don't want to bother with lost messages ever". > Its my job to config MQ to be as reliable as possible. > > An application that sends non persistent inquiry messages that will be > invalid in 5 seconds has a reasonable assumption that MQ will do everything > it can to deliver them. Just because they don't need to survive a QM restart > doesn't mean they are less important. > > I feel the happy medium between "Make all message persistent" and "Don't > expect all your messages to always make it to the other side" is to set the > message channel speed to normal, as long as conditions warrant it. If you > got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly > back up, and the occasional non persistent message is being held back until > the batch commits, then no way, the speed should be fast, and live with the > fact that it may get lost. > > But I bet that is not how many of anybody's channels run. I bet most of us > have XMIT queues that are normally empty, and the BATCHINT is still set to > the default of 0. In this case, setting the speed to normal will have very > little effect on overall performance, but will insure that no messages ever > get lost. > > I wonder why IBM choose to have the default setting of the channel speed set > to fast? Seems to me it would be better to make the default normal. This > would perform just fine for most people and would help MQ's rep of never> > losing messages. You have no idea what a pain it was discovering that MQ was > losing messages over a particular fast channel. Days of blaming the apps > with losing the messages, hunting in DLQs all over the place, XMIT queues, > application queues, etc. The real kick in the pants is that when a message > is lost like this, there is ZERO record of the fact. You are left scratching > you head. The man hours wasted on hunting for a message lost like this is > just not worth it. I'll gladly take a tiny performance hit in a tiny > percentage of the messages I send over an already very fast product. > > Any people looking to pump up the performance of a channel above and beyond > this could then tweak t
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
In order to get the behaviour you want, the task processing NP messages must not use or be dependent on SAN I/O whatsoever. Now you don't have absolute control of the I/O that MQ uses. For example, NP messages can spill to disk if they are large or many, and sometimes MQ will use disk scratchpads for various reasons. The good news is that IBM has put a lot of effort into optimizing the throughput of NP messages, so avoids disk I/O unless absolutely necessary. I still think you are probably experiencing log I/O because the channels are doing your NP messages under syncpoint. Change your Ha-Ha channels to NPMSPEED=fast and see if it makes a difference. Ultimately, I think you need to move your logs off the SAN. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. > The only messages going over this channel are non persistent. Thousands of > messages are zooming across this channel every hour. The XMIT queue never > got deeper than 2. The speed is normal. A bin change hits our SAN, which the > HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since > then there have been no changes to the SAN, and the XMIT queue again has not > gotten over 2. This to me reinforces that fact that a disk outage on the HUB > is effecting non persistent messages somehow. And I am beginning to think > there is no way around it. :( > > > > > > About the messages being non persistent / persistent and the channel speed: > > Even though the messages are non persistent, I still care about them. I have > always been of the mind set that whether a message is persistent or not has > more to do with how difficult it is for the apps to reproduce the message if > it got lost. If it is a big deal, then make it persistent. It will survive > anything and eventually be processed. Messages that tend to sit in queues > for a long time are susceptible to QMs going down, and thus should be made > persistent if they need to survive. > > The messages in this app are inquiry style. They are invalid 5 seconds after > the fact. Even if they were persistent and survived a QM restart, they would > still be invalid, so why incur the performance penalties of persistence? > Now, that's not to say we don't care if they get lost or not. I always shake > my head when I hear people say "I made it non persistent because I don't > care if it gets lost or not". If you don't care, why did you bother to send > it in the first place?!?!? What if MQ was losing 50% of the nonpersistent > messages? I couldn't tell the app "Hey just resend them, they are only > inquiry messages anyway!" Nor could I say, "Every message in this company is > going to be persistent. We don't want to bother with lost messages ever". > Its my job to config MQ to be as reliable as possible. > > An application that sends non persistent inquiry messages that will be > invalid in 5 seconds has a reasonable assumption that MQ will do everything > it can to deliver them. Just because they don't need to survive a QM restart > doesn't mean they are less important. > > I feel the happy medium between "Make all message persistent" and "Don't > expect all your messages to always make it to the other side" is to set the > message channel speed to normal, as long as conditions warrant it. If you > got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly > back up, and the occasional non persistent message is being held back until > the batch commits, then no way, the speed should be fast, and live with the > fact that it may get lost. > > But I bet that is not how many of anybody's channels run. I bet most of us> > have XMIT queues that are normally empty, and the BATCHINT is still set to > the default of 0. In this case, setting the speed to normal will have very > little effect on overall performance, but will insure that no messages ever > get lost. > > I wonder why IBM choose to have the default setting of the channel speed set > to fast? Seems to me it would be better to make the default normal. This > would perform just fine for most people and would help MQ's rep of never > losing messages. You have no idea what a pain it was discovering that MQ was > losing messages over a particular fast channel. Days of blaming the apps > with losing the messages, hunting in DLQs all over the place, XMIT queues, > application queues, etc.
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 1:01 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Hi Dennis. > > I agree that non-persistent and persistent messages in a batch will be > available at the same time. But my batches are of 1 or 2 messages. Since my > BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I > am incurring any performance hit. 1 or 2 messages are sent across, mybe > message #1 is a nonpersistent that is held back until the batch completes, > but the batch completes almost immediately, since no more message have yet > arrived and the BATCHINT expires. At this point I am still not convinced, in > my scenario, that this setting has an effect for the above reason.> > > It has also been mentioned more than once to make a separate channel for > persistent vs. non-persistent messages. I don't see how that makes a > difference. So I make 2 separate channels from SPOKEQM1 to HUBQM. As far as > the hub and its receiving MCAs are concerned, big deal. The HUB already had > 50 other receiving MCAs and channels for all the other spokes. If the HUB QM > is slowing down because its SAN is temporarily unavailable, does it really > matter if you have 1,2 or 20 channels between a particular spoke and the > HUB? The HUB still has to deal with the other 50 spokes, and if they are > sending persistent messages, then the HUBQM has to service them as well, and > it makes no diff that you bothered to separate the channels from any one > particular spoke. All these Receiving MCAs have to compete for 1 or 2 CPUs, > and if any of those CPUs are busy waiting because the SAN is N/A, then a > whole bunch of MCAs are effect
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Someone please correct me if I am wrong, but what I have seen is that the log files are still written to with non-persistent messages because of the queue manager to queue manager commit/syncpoint activity for messages traveling over the channel. I know this because there is a bug in Windows MQ 5.3 CSD01 that is fixed in CSD03 where a roll-back fails causing our log-files to fill up. Since we are only sending non-persistent messages over these channels, why else would the log files be written to? Maybe this is the same symptom that Peter is seeing. If he had a disk problem would the queue manager wait to write some sync records to the logs? Like I said, I'm not sure if this is true, it's just what I noticed when we had the channel commit bug. Brian -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. The only messages going over this channel are non persistent. Thousands of messages are zooming across this channel every hour. The XMIT queue never got deeper than 2. The speed is normal. A bin change hits our SAN, which the HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since then there have been no changes to the SAN, and the XMIT queue again has not gotten over 2. This to me reinforces that fact that a disk outage on the HUB is effecting non persistent messages somehow. And I am beginning to think there is no way around it. :( About the messages being non persistent / persistent and the channel speed: Even though the messages are non persistent, I still care about them. I have always been of the mind set that whether a message is persistent or not has more to do with how difficult it is for the apps to reproduce the message if it got lost. If it is a big deal, then make it persistent. It will survive anything and eventually be processed. Messages that tend to sit in queues for a long time are susceptible to QMs going down, and thus should be made persistent if they need to survive. The messages in this app are inquiry style. They are invalid 5 seconds after the fact. Even if they were persistent and survived a QM restart, they would still be invalid, so why incur the performance penalties of persistence? Now, that's not to say we don't care if they get lost or not. I always shake my head when I hear people say "I made it non persistent because I don't care if it gets lost or not". If you don't care, why did you bother to send it in the first place?!?!? What if MQ was losing 50% of the nonpersistent messages? I couldn't tell the app "Hey just resend them, they are only inquiry messages anyway!" Nor could I say, "Every message in this company is going to be persistent. We don't want to bother with lost messages ever". Its my job to config MQ to be as reliable as possible. An application that sends non persistent inquiry messages that will be invalid in 5 seconds has a reasonable assumption that MQ will do everything it can to deliver them. Just because they don't need to survive a QM restart doesn't mean they are less important. I feel the happy medium between "Make all message persistent" and "Don't expect all your messages to always make it to the other side" is to set the message channel speed to normal, as long as conditions warrant it. If you got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly back up, and the occasional non persistent message is being held back until the batch commits, then no way, the speed should be fast, and live with the fact that it may get lost. But I bet that is not how many of anybody's channels run. I bet most of us have XMIT queues that are normally empty, and the BATCHINT is still set to the default of 0. In this case, setting the speed to normal will have very little effect on overall performance, but will insure that no messages ever get lost. I wonder why IBM choose to have the default setting of the channel speed set to fast? Seems to me it would be better to make the default normal. This would perform just fine for most people and would help MQ's rep of never losing messages. You have no idea what a pain it was discovering that MQ was losing messages over a particular fast channel. Days of blaming the apps with losing the messages, hunting in DLQs all over the place, XMIT queues, application queues, etc. The real kick in the pants is that when a message is lost like this, there is ZERO record of the fact. You are left scratching you head. The man hours wasted on hunting for a message lost like this is just not worth it. I'll gladly take a tiny performance hit in a tiny percentage of the messages I send over an already very fast
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
For Ha-Has, I made a dedicated channel for this app from SPOKE1 to HUBQM. The only messages going over this channel are non persistent. Thousands of messages are zooming across this channel every hour. The XMIT queue never got deeper than 2. The speed is normal. A bin change hits our SAN, which the HUB needs, and the XMIT queue backed up to 22 for a couple of seconds! Since then there have been no changes to the SAN, and the XMIT queue again has not gotten over 2. This to me reinforces that fact that a disk outage on the HUB is effecting non persistent messages somehow. And I am beginning to think there is no way around it. :( About the messages being non persistent / persistent and the channel speed: Even though the messages are non persistent, I still care about them. I have always been of the mind set that whether a message is persistent or not has more to do with how difficult it is for the apps to reproduce the message if it got lost. If it is a big deal, then make it persistent. It will survive anything and eventually be processed. Messages that tend to sit in queues for a long time are susceptible to QMs going down, and thus should be made persistent if they need to survive. The messages in this app are inquiry style. They are invalid 5 seconds after the fact. Even if they were persistent and survived a QM restart, they would still be invalid, so why incur the performance penalties of persistence? Now, that's not to say we don't care if they get lost or not. I always shake my head when I hear people say "I made it non persistent because I don't care if it gets lost or not". If you don't care, why did you bother to send it in the first place?!?!? What if MQ was losing 50% of the nonpersistent messages? I couldn't tell the app "Hey just resend them, they are only inquiry messages anyway!" Nor could I say, "Every message in this company is going to be persistent. We don't want to bother with lost messages ever". Its my job to config MQ to be as reliable as possible. An application that sends non persistent inquiry messages that will be invalid in 5 seconds has a reasonable assumption that MQ will do everything it can to deliver them. Just because they don't need to survive a QM restart doesn't mean they are less important. I feel the happy medium between "Make all message persistent" and "Don't expect all your messages to always make it to the other side" is to set the message channel speed to normal, as long as conditions warrant it. If you got a BATCHINT of 100 and a BATCHSIZE of 200 and your XMIT queues regularly back up, and the occasional non persistent message is being held back until the batch commits, then no way, the speed should be fast, and live with the fact that it may get lost. But I bet that is not how many of anybody's channels run. I bet most of us have XMIT queues that are normally empty, and the BATCHINT is still set to the default of 0. In this case, setting the speed to normal will have very little effect on overall performance, but will insure that no messages ever get lost. I wonder why IBM choose to have the default setting of the channel speed set to fast? Seems to me it would be better to make the default normal. This would perform just fine for most people and would help MQ's rep of never losing messages. You have no idea what a pain it was discovering that MQ was losing messages over a particular fast channel. Days of blaming the apps with losing the messages, hunting in DLQs all over the place, XMIT queues, application queues, etc. The real kick in the pants is that when a message is lost like this, there is ZERO record of the fact. You are left scratching you head. The man hours wasted on hunting for a message lost like this is just not worth it. I'll gladly take a tiny performance hit in a tiny percentage of the messages I send over an already very fast product. Any people looking to pump up the performance of a channel above and beyond this could then tweak the channel to fast, only after realizing messages could get lost. Maybe when it was time to decide what value to use as a default, the logic was "We have a choice of making our product faster out of the box or making our message delivery more assured out of the box". And the choice was to make it fast, in case customers are running performance comparisons against other messaging systems like SONINMQ or MSMQ. Who knows, this is only a guess. -Original Message----- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages I think I joined the thread part way through. Now I'm playing catchup. I've read you original message which I'll add my 2p (English money) in revers(ish) order: Q3. I then defined a local queue on QMHUB and used
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
I would say that all 8 WILL work at the same time, but each can only do one thing at a time. If the QM is in fact multi-threaded/processed under the covers, then at least you could have 8 "things" going on at the same time. BUT, if all 8 CPUs need to share a resource, like the disk, then are we back to square one? And even 8 CPUs in my scenario is still no big deal, since under heavy volume I am sure you can have more than 8 messages in flight INSIDE the HUB queue manager at any one time. Or if the HUB has 50 spokes, then you can 50 receiving MCAs all competing for the same 8 CPUs. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Peter, Got a question. On my arcitectural diagrams I have specifications for 8-WAY servers. I agree with you that a CPU can only do one thing at a time. While that CPU is waiting what are the other 7 doing? If the are also waiting on #1 what is the use of haveing a multi CPU machine except for IBM to charge us capasity units for MQ/MQSI/Websphere. bee-oh-dubble-bee-dubble-egh >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages >Date: Fri, 30 May 2003 08:50:12 -0400 > >Gary, > About a queue manager, or any process that runs on any computer, I >have always assumed, maybe incorrectly, that a CPU on a box can only do one >thing at a time. It may be incredibly fast, giving the illusion of many >things happening at once, but when you get right down to it, everything has >to wait its turn for the CPU to do its thing. > >And if the CPU is waiting to interact with the disk to write a persistent >(or bigger than 64k non-persistent) message (I guess even if that message >is >going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go >on >to handle non persistent messages. > >??? > > >-Original Message- >From: Gary Ward [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 29, 2003 7:47 PM >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / >non-persistent messages > > >Peter, > >I'll gladly defer to any IBM MQ Developers lurking on the list since this >is >getting really 'down and dirty', but in the meantime I'll give you another >$.02... > >Right about my answer to Q2... I guess I missed your point. Having read >your follow-up, I would offer this theory. I think the queue manager MUST >be able to do more than a single task at once. That's why it's made up of >many individual processes which have dedicated tasks. I would think at any >one moment there's a bunch of messages floating around in various states. >If the messages are non-persistent, they're not logged and hence can be >available immediately (if they're not IN SYNCPOINT with persistent >messages). Non-persistent messages only get written to disk when there's >not enough memory available to hold them on an individual queue. I'm not >sure about persistent messages always going right to the queue file system, >but my gut feeling is that they do. > >If your non-persistent messages are 100K and you have your queues set at >the >64KB default, I'm pretty sure they go right to disk. That's why you should >tune that non-persistent message buffer. Hopefully something is already >waiting for these non-persistent messages so they get handed off directly >in >the manner that T. Rob and I mentioned earlier in this thread. Then >there's >no I/O at all. > >Hope this helps... any IBMer's want to comment > > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, >Peter M (PLC, IT) >Sent: Thursday, May 29, 2003 6:11 PM >To: [EMAIL PROTECTED] >Subject: Re: How a MQSeries Hub does its thing with persistent / >non-persi st m essages > > >Gary, > I think you answer to Q2 pertains more to when a message is about >to >leave a server to go onto the next one. That setting tells the receiving >side how soon it can have the Nonpersistent message in relation to the >batch >of messages coming across the channel. > >I am curious about once the messages have already been accepted on the HUB. >Whether they were persistent or not, regardless of the channel speed >setting, at any given moment on our busy HUB, the QM finds itself with lots >and lots of messages that it now has complete control o
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Hi Dennis. I agree that non-persistent and persistent messages in a batch will be available at the same time. But my batches are of 1 or 2 messages. Since my BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I am incurring any performance hit. 1 or 2 messages are sent across, mybe message #1 is a nonpersistent that is held back until the batch completes, but the batch completes almost immediately, since no more message have yet arrived and the BATCHINT expires. At this point I am still not convinced, in my scenario, that this setting has an effect for the above reason. It has also been mentioned more than once to make a separate channel for persistent vs. non-persistent messages. I don't see how that makes a difference. So I make 2 separate channels from SPOKEQM1 to HUBQM. As far as the hub and its receiving MCAs are concerned, big deal. The HUB already had 50 other receiving MCAs and channels for all the other spokes. If the HUB QM is slowing down because its SAN is temporarily unavailable, does it really matter if you have 1,2 or 20 channels between a particular spoke and the HUB? The HUB still has to deal with the other 50 spokes, and if they are sending persistent messages, then the HUBQM has to service them as well, and it makes no diff that you bothered to separate the channels from any one particular spoke. All these Receiving MCAs have to compete for 1 or 2 CPUs, and if any of those CPUs are busy waiting because the SAN is N/A, then a whole bunch of MCAs are effected. I wonder what everyone thinks of the following: Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, If you use NPMSPEED=normal, non-persistent and persistent messages in the same batch all become available at the same time. You can infer from that, that performance of non-persistent messages is dependent on I/O for persistent messages, though I believe it is more likely to be the (synchronous) log I/O rather than (asynchronous) queue I/O. Segregating persistent and non-persistent messages on different channels relieves the above dependency. If one channel is waiting for the log, another should be able to continue transmitting messages until such time as it also needs the log or until the qmgr decides a checkpoint is in order. Bottom line: If your logs are on the SAN, there is a distinct probability that your spoke channels will take a break when that "device" is not available. my .02 sense (pun intentional). > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 7:21 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > So here is my real question, which is what makes me wonder exactly how a QM > handles messages. > > Our HUB server is using Veritas. The disk that is being written to (whenever > that may be) is actually on the Storage Area Network (SAN). > > The HUB is also clustered with 2 queue managers dedicated to MQSI. The HUB > acts simply as a gateway queue manager for this MQSI cluster. THE MQSI boxes > are in 2 separate locations, with Veritas, and both again also write to the > SAN. > > > Whenever we make bin changes to the SAN, that change ripples across the > fabric, making the SAN unavailable for a tiny bit of time. > > Now, we have an app that is counting milliseconds in its roundtrip of the > message. This message starts on one of the spokes, comes to the HUB, is > round robined to one of the MQSI boxes, the processed message comes back to > the HUB, which then sends it down to the receiving spoke. It processes the > message, sends it back to the hub, round robined into MQSI for processing > the reply, the processed reply goes back to the hub, which then sends the > reply back to the originating spoke. For 99.99% of the time, this roundtrip > takes under 500 milliseconds. The app waits up to 2000 milliseconds for the > reply. The messages are non persistent and about 25K in size. > > Whenever the bin changes to the SAN take place, we start getting messages > that
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
I think I joined the thread part way through. Now I'm playing catchup. I've read you original message which I'll add my 2p (English money) in revers(ish) order: Q3. I then defined a local queue on QMHUB and used one of the spoke QMs to send non-persistent message to it. 1 GIG worth actually. Now these are not written to disk, cause they are not persistent, so where are they, in memory? I see the queue file grew by over a GIG, so doesn't that mean they are on disk, even though they are non persistent? A3: I would expect these to remain in memory until you exceed the amount of memory allocated to hold these messages, after which MQ must store them on disk, surely? Q1. On day 1, is there any data being written to disk by QMHUB as the messages fly thru? I assume no, since they are not persistent (but see Q3 below [ above - J]). A1: See question 1. Messages may get logged to disk if MQ runs out of allocated cache memory. Q2. On day 2, even though we have 2 CPUs, we still have only 1 QM, so I assume all the non persistent messages throughput must be affected by the persistent messages. My reasoning is, as the persistent messages go in and out of the QMAliases, and in and out of the XMIT queues, it has to "stop" and log, right? And if it has to stop and log, then it can't be handling the non persistent ones at the same time right? They have to wait? A3: Elsewhere you mentioned changing the channels to normal rather thanfast. To me this means non-psist messages get sent in sequence and are acknowledged by the channels. Now your messages sit in transmission queues and get read in turn and sent (again waiting for acks from the receiving end). You want this to stop losing messages (though exactly why I'm not sure since they're not psistent and will die if the QM is restarted - another discussion). Since you now have non & psistent messages mixed in a XMITQ, I would expect the psistent onces to "get in the way" of non-persisten ones since they'll be read in batches and sent and acknowledged by the receiving end. However, these are only mixed by XMITQ. Thus if you have all persistent going to SPOKEQM1 and all non-persistent going to SPOKEQM2, I would not expect SPOKEQM2's messages to be delayed by SPOKEQM1's persistent messages. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 15:18 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages The HUB has dozens of channels to and from each spoke. My question is if one pair of spokes is exchanging Nonpersistent messages and another pair starts sending persistent, will they hurt each other. I don't think dedicating channels to be persistent or not between a spoke QM and the HUB will make a difference, since either way, the HUB QM has to deal with dozens of channels either way. It may make a difference on how fast a message gets from a particular spoke to the HUB, but not what happens once it is already there. ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
That because Gary is very old! (tee hee hee)
From: Gary Ward <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi
stent messages
Date: Fri, 30 May 2003 09:11:49 -0400
Peter,
As far as I know, if a process is performing I/O, it should not be
locking up the CPU. The process will "swap out" (call it what you
will on your favorite OS) while performing I/O and other processes
that want to use the CPU are scheduled. I believe this is computing
101... but I took that course a LONG time ago! ;)
Regards,
Gary
--
Gary J. Ward
Senior Consulting Engineer
Information Design, Inc.
A Premier IBM Business Partner
Original Message
==> From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
==> Date: Fri, 30 May 2003 08:50:12 -0400
Gary, About a queue manager, or any process that runs on any
computer, I have always assumed, maybe incorrectly, that a CPU on a
box can only do one thing at a time. It may be incredibly fast,
giving the illusion of many things happening at once, but when you
get right down to it, everything has to wait its turn for the CPU to
do its thing.
And if the CPU is waiting to interact with the disk to write a
persistent (or bigger than 64k non-persistent) message (I guess even
if that message is going to blink in and out of a QM Alias or
XMITQ???) then the CPU cant go on to handle non persistent messages.
???
-Original Message- From: Gary Ward
[mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM
To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its
thing with persistent / non-persistent messages
Peter,
I'll gladly defer to any IBM MQ Developers lurking on the list since
this is getting really 'down and dirty', but in the meantime I'll
give you another $.02...
Right about my answer to Q2... I guess I missed your point. Having
read your follow-up, I would offer this theory. I think the queue
manager MUST be able to do more than a single task at once. That's
why it's made up of many individual processes which have dedicated
tasks. I would think at any one moment there's a bunch of messages
floating around in various states. If the messages are non-
persistent, they're not logged and hence can be available immediately
(if they're not IN SYNCPOINT with persistent messages). Non-
persistent messages only get written to disk when there's not enough
memory available to hold them on an individual queue. I'm not sure
about persistent messages always going right to the queue file
system, but my gut feeling is that they do.
If your non-persistent messages are 100K and you have your queues set
at the 64KB default, I'm pretty sure they go right to disk. That's
why you should tune that non-persistent message buffer. Hopefully
something is already waiting for these non-persistent messages so
they get handed off directly in the manner that T. Rob and I
mentioned earlier in this thread. Then there's no I/O at all.
Hope this helps... any IBMer's want to comment
-Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]
Wien.AC.AT]On Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, May
29, 2003 6:11 PM To: [EMAIL PROTECTED] Subject: Re: How a
MQSeries Hub does its thing with persistent / non-persi st m essages
Gary, I think you answer to Q2 pertains more to when a message is
about to leave a server to go onto the next one. That setting tells
the receiving side how soon it can have the Nonpersistent message in
relation to the batch of messages coming across the channel.
I am curious about once the messages have already been accepted on
the HUB. Whether they were persistent or not, regardless of the
channel speed setting, at any given moment on our busy HUB, the QM
finds itself with lots and lots of messages that it now has complete
control over. As it routes them thru the QMAliases and the XMITQs, it
has to "stop" and log the persistent messages. I feel that this
activity must somehow also effect the non persistent ones as well,
since the QM can only do one thing at a time, regardless how fast it
does it. If it is busy logging a persistent message, it can't route a
non persistent one at that exact moment, correct?
Regarding the queue buffer setting, if my messages are less than
64K, and because due to high activity all my channels in a particular
SPOKE-HUB-SPOKE route are running, then a non persistent message
would go in and out of each XMIT queue, in and out of each QM Alias
queue and in and out of each application queue (assuming the app has
an outstanding GET with wait) with no I/O to the disk?
What if the messages are 100K non persistent ones and the buffer
setting is still at default? Are you saying that a non persistent
message is still written to d
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Peter, Got a question. On my arcitectural diagrams I have specifications for 8-WAY servers. I agree with you that a CPU can only do one thing at a time. While that CPU is waiting what are the other 7 doing? If the are also waiting on #1 what is the use of haveing a multi CPU machine except for IBM to charge us capasity units for MQ/MQSI/Websphere. bee-oh-dubble-bee-dubble-egh From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Date: Fri, 30 May 2003 08:50:12 -0400 Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non-persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non-persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queue file system, but my gut feeling is that they do. If your non-persistent messages are 100K and you have your queues set at the 64KB default, I'm pretty sure they go right to disk. That's why you should tune that non-persistent message buffer. Hopefully something is already waiting for these non-persistent messages so they get handed off directly in the manner that T. Rob and I mentioned earlier in this thread. Then there's no I/O at all. Hope this helps... any IBMer's want to comment -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, May 29, 2003 6:11 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi st m essages Gary, I think you answer to Q2 pertains more to when a message is about to leave a server to go onto the next one. That setting tells the receiving side how soon it can have the Nonpersistent message in relation to the batch of messages coming across the channel. I am curious about once the messages have already been accepted on the HUB. Whether they were persistent or not, regardless of the channel speed setting, at any given moment on our busy HUB, the QM finds itself with lots and lots of messages that it now has complete control over. As it routes them thru the QMAliases and the XMITQs, it has to "stop" and log the persistent messages. I feel that this activity must somehow also effect the non persistent ones as well, since the QM can only do one thing at a time, regardless how fast it does it. If it is busy logging a persistent message, it can't route a non persistent one at that exact moment, correct? Regarding the queue buffer setting, if my messages are less than 64K, and because due to high activity all my channels in a particular SPOKE-HUB-SPOKE route are running, then a non persistent message would go in and out of each XMIT queue, in and out of each QM Alias queue and in and out of each application queue (assuming the app has an outstanding GET with wait) with no I/O to the disk? What if the messages are 100K non persistent ones and the buffer setting is still at default? Are you saying that a non persistent message is still written to disk? If yes, to me that sounds like there is no reason to not use persistence always on any message larger than 64K. Surely that can't be the case! Or is it like T.Rob suggested: Nonpersistent gets written to disk, persistent gets wri
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
The HUB has dozens of channels to and from each spoke. My question is if one pair of spokes is exchanging Nonpersistent messages and another pair starts sending persistent, will they hurt each other. I don't think dedicating channels to be persistent or not between a spoke QM and the HUB will make a difference, since either way, the HUB QM has to deal with dozens of channels either way. It may make a difference on how fast a message gets from a particular spoke to the HUB, but not what happens once it is already there. -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 12:00 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Can you send high priority messages down their own channels and the persistent ones down their own. These would run as separate processes and (possibly) not block each other. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 14:21 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages So here is my real question, which is what makes me wonder exactly how a QM handles messages. Our HUB server is using Veritas. The disk that is being written to (whenever that may be) is actually on the Storage Area Network (SAN). The HUB is also clustered with 2 queue managers dedicated to MQSI. The HUB acts simply as a gateway queue manager for this MQSI cluster. THE MQSI boxes are in 2 separate locations, with Veritas, and both again also write to the SAN. Whenever we make bin changes to the SAN, that change ripples across the fabric, making the SAN unavailable for a tiny bit of time. Now, we have an app that is counting milliseconds in its roundtrip of the message. This message starts on one of the spokes, comes to the HUB, is round robined to one of the MQSI boxes, the processed message comes back to the HUB, which then sends it down to the receiving spoke. It processes the message, sends it back to the hub, round robined into MQSI for processing the reply, the processed reply goes back to the hub, which then sends the reply back to the originating spoke. For 99.99% of the time, this roundtrip takes under 500 milliseconds. The app waits up to 2000 milliseconds for the reply. The messages are non persistent and about 25K in size. Whenever the bin changes to the SAN take place, we start getting messages that take longer than 2000 milliseconds, and now we have orphaned replies. These are non persistent messages that are under 64K, so why does a change that makes the disk unavailable cause these messages to slow down? My guess is that the persistent messages the HUB is processing at the same time (or the >64K Nonpersistent ones) must somehow be effecting the performance of the non persistent ones. And I also assume that channel speed has nothing to do with this. So the angle I am after here is how can I increase the performance of my messages for this app so that changes to the SAN don't effect it. -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages This would be true for the smallest unit of execution (normally a thread, not a process). Thus if a thread of execution was committing data to disk, that thread would not continue until the commit was completed. However, another thread within the same process would get CPU if it was able to execute some code. It all depends on whether the MQ processes are multi-threaded or not. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 12:50 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right a
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Can you send high priority messages down their own channels and the persistent ones down their own. These would run as separate processes and (possibly) not block each other. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 14:21 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages So here is my real question, which is what makes me wonder exactly how a QM handles messages. Our HUB server is using Veritas. The disk that is being written to (whenever that may be) is actually on the Storage Area Network (SAN). The HUB is also clustered with 2 queue managers dedicated to MQSI. The HUB acts simply as a gateway queue manager for this MQSI cluster. THE MQSI boxes are in 2 separate locations, with Veritas, and both again also write to the SAN. Whenever we make bin changes to the SAN, that change ripples across the fabric, making the SAN unavailable for a tiny bit of time. Now, we have an app that is counting milliseconds in its roundtrip of the message. This message starts on one of the spokes, comes to the HUB, is round robined to one of the MQSI boxes, the processed message comes back to the HUB, which then sends it down to the receiving spoke. It processes the message, sends it back to the hub, round robined into MQSI for processing the reply, the processed reply goes back to the hub, which then sends the reply back to the originating spoke. For 99.99% of the time, this roundtrip takes under 500 milliseconds. The app waits up to 2000 milliseconds for the reply. The messages are non persistent and about 25K in size. Whenever the bin changes to the SAN take place, we start getting messages that take longer than 2000 milliseconds, and now we have orphaned replies. These are non persistent messages that are under 64K, so why does a change that makes the disk unavailable cause these messages to slow down? My guess is that the persistent messages the HUB is processing at the same time (or the >64K Nonpersistent ones) must somehow be effecting the performance of the non persistent ones. And I also assume that channel speed has nothing to do with this. So the angle I am after here is how can I increase the performance of my messages for this app so that changes to the SAN don't effect it. -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages This would be true for the smallest unit of execution (normally a thread, not a process). Thus if a thread of execution was committing data to disk, that thread would not continue until the commit was completed. However, another thread within the same process would get CPU if it was able to execute some code. It all depends on whether the MQ processes are multi-threaded or not. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 12:50 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non-persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non-persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queu
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
So here is my real question, which is what makes me wonder exactly how a QM handles messages. Our HUB server is using Veritas. The disk that is being written to (whenever that may be) is actually on the Storage Area Network (SAN). The HUB is also clustered with 2 queue managers dedicated to MQSI. The HUB acts simply as a gateway queue manager for this MQSI cluster. THE MQSI boxes are in 2 separate locations, with Veritas, and both again also write to the SAN. Whenever we make bin changes to the SAN, that change ripples across the fabric, making the SAN unavailable for a tiny bit of time. Now, we have an app that is counting milliseconds in its roundtrip of the message. This message starts on one of the spokes, comes to the HUB, is round robined to one of the MQSI boxes, the processed message comes back to the HUB, which then sends it down to the receiving spoke. It processes the message, sends it back to the hub, round robined into MQSI for processing the reply, the processed reply goes back to the hub, which then sends the reply back to the originating spoke. For 99.99% of the time, this roundtrip takes under 500 milliseconds. The app waits up to 2000 milliseconds for the reply. The messages are non persistent and about 25K in size. Whenever the bin changes to the SAN take place, we start getting messages that take longer than 2000 milliseconds, and now we have orphaned replies. These are non persistent messages that are under 64K, so why does a change that makes the disk unavailable cause these messages to slow down? My guess is that the persistent messages the HUB is processing at the same time (or the >64K Nonpersistent ones) must somehow be effecting the performance of the non persistent ones. And I also assume that channel speed has nothing to do with this. So the angle I am after here is how can I increase the performance of my messages for this app so that changes to the SAN don't effect it. -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages This would be true for the smallest unit of execution (normally a thread, not a process). Thus if a thread of execution was committing data to disk, that thread would not continue until the commit was completed. However, another thread within the same process would get CPU if it was able to execute some code. It all depends on whether the MQ processes are multi-threaded or not. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 12:50 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non-persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non-persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queue file system, but my gut feeling is that they do. If your non-persistent messages are 100K and you have your queues set at the 64KB default, I'm pretty sure they go right to disk. That's why you should tune that non-persistent message buffer. Hopefully something is already waiting for these non-persistent messages so they get handed off directly in the manner that T. Rob and I mentioned earlier in this
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Neil, I am specifically thinking of the scenario where the message is already on the destination QM. Regardless of whether the messages were in syncpoint or not as they traveled across the channel, I am only concerned about how messages are handled in a HUB queue manager once they are committed to the HUB queue manager. On a busy HUB, at any given moment, I will have thousands of messages being made available every minute to the QM. At the risk of hijacking this thread into a discussion on channel speed: I chose a speed of normal on my channels because for the longest time, we had a batch interval of zero and a batch size of 50 for all our channels. Then one of our channels started losing non-persistent messages occasionally, and we solved the problem by tweaking the speed to normal. That was a learning experience! For a week, we kept swearing MQ doesn't lose messages, it must be the app, and lo and behold, we came across a situation where MQ could lose a message. So then I started thinking, "Why not make all our channels normal speed?". I don't want to ever go thru that again (MQ losing messages in transit). But how would that effect our channel performance? I started to look at queue statistics to see what the max depth of our XMIT queues was getting to. None of our XMIT queues (other than Batch specific ones) showed that they ever got deeper than like 7 or 8. To me this said that the batch interval was coming into play. The XMIT queue was draining to zero, the batch size of 50 was not reached, so wait BATCHINT before committing. Since our BATCHINT is 0, commit immediately. The channels are so fast that our transmit queues stay empty almost always. Setting the speed to normal would mean that very rarely maybe a non persistent message would have to wait a tiny bit as a batch of 7 or 8 went across. Then the XMIT queue hit zero, and everything got committed. We just don't have the insane volume here where BATCHSIZE ever come into play. My feeling is that in setting the speed to normal, 99.% of my message throughput remained the same, but I insured I would never lose a message on a channel. (Channels dedicated to Batch applications are tuned completely differently). So I think that even though my channels are normal speed, all messages are made available on the Receiving QM almost immediately. The real question is how are they handled at that point. -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 9:57 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Hi... not an IBMer, but want to comment. The following are my thoughts based on behaviour I have seen on my queue managers, not based on the code. Q1. You will see log I/O in your environment, because you are running NPMSpeed normal. This causes the channel sequence numbers to be hardened, which causes queue file (on the SYSTEM.CHANNEL.SYNCQ) and log I/O. It also causes non-persistent messages to be written inside syncpoint control by the channel agents, so you can't get the performance advantages of direct message copying between the agents. I have recently come to understand that MQ also uses scratchpad files to track channel info, and there is I/O to these files as well. If you were to change to NPMSPEED(fast), then you should reduce both log and queue file I/O in case 1. However, when you have persistent and non-persistent messages sharing an NPMSpeed(Fast) channel, each persistent message will start a batch, and non-persistent messages can get sent in the batch, and so the non-persistent messages get caught up in the synpoints (but their data is not logged). This delays their availability on the target queue. Queue file I/O should generally asynchronous (look on it like paging to virtual memory) whereas logging writes are (at least sometimes) synchronous. (Data Logging is probably async, but syncpoint logging has to be synchronous I/O). Think of it just like a database logger. This means that not all I/O is equally bad. I would suggest that to get maximum performance, you need to separate your persistent and non-persistent traffic, and run NPMSpeed(Fast). This is difficult, as you need to double your infrastructure, and you won't be able to use default transmission queues (I have always thought they were a bad idea, but that is just me). You define 2 channels from each leaf to the hub, and from the hub to each leaf, one for persistent and one for non-persistent. You need to have QMgrAliases everywhere, with different names for accesses to a queue manager with persistent vs non-persistent messages. You need to have additional ReplyToQ remote queue definitions so that replies come back via the correct aliases, as otherwise all of the replies will be routed via the same channel. You also need to define QRemotes for all of the queues at every queue manager, rather than just on the hub, as default transmission queues won't sep
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
This would be true for the smallest unit of execution (normally a thread, not a process). Thus if a thread of execution was committing data to disk, that thread would not continue until the commit was completed. However, another thread within the same process would get CPU if it was able to execute some code. It all depends on whether the MQ processes are multi-threaded or not. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 12:50 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non-persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non-persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queue file system, but my gut feeling is that they do. If your non-persistent messages are 100K and you have your queues set at the 64KB default, I'm pretty sure they go right to disk. That's why you should tune that non-persistent message buffer. Hopefully something is already waiting for these non-persistent messages so they get handed off directly in the manner that T. Rob and I mentioned earlier in this thread. Then there's no I/O at all. Hope this helps... any IBMer's want to comment -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, May 29, 2003 6:11 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi st m essages Gary, I think you answer to Q2 pertains more to when a message is about to leave a server to go onto the next one. That setting tells the receiving side how soon it can have the Nonpersistent message in relation to the batch of messages coming across the channel. I am curious about once the messages have already been accepted on the HUB. Whether they were persistent or not, regardless of the channel speed setting, at any given moment on our busy HUB, the QM finds itself with lots and lots of messages that it now has complete control over. As it routes them thru the QMAliases and the XMITQs, it has to "stop" and log the persistent messages. I feel that this activity must somehow also effect the non persistent ones as well, since the QM can only do one thing at a time, regardless how fast it does it. If it is busy logging a persistent message, it can't route a non persistent one at that exact moment, correct? Regarding the queue buffer setting, if my messages are less than 64K, and because due to high activity all my channels in a particular SPOKE-HUB-SPOKE route are running, then a non persistent message would go in and out of each XMIT queue, in and out of each QM Alias queue and in and out of each application queue (assuming the app has an outstanding GET with wait) with no I/O to the disk? What if the messages are 100K non persistent ones and the buffer setting is still at default? Are you saying that a non persistent message is still written to disk? If yes, to me that sounds like there is no reason to not use persistence always on any message larger than 64K. Surely that can't be the case! Or is it like T.Rob suggested: Nonpersistent gets written to disk, persistent gets written to disk AND log, for a double I/O??? -Original Message
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Peter, As far as I know, if a process is performing I/O, it should not be locking up the CPU. The process will "swap out" (call it what you will on your favorite OS) while performing I/O and other processes that want to use the CPU are scheduled. I believe this is computing 101... but I took that course a LONG time ago! ;) Regards, Gary -- Gary J. Ward Senior Consulting Engineer Information Design, Inc. A Premier IBM Business Partner Original Message ==> From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> ==> Date: Fri, 30 May 2003 08:50:12 -0400 Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non- persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non- persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queue file system, but my gut feeling is that they do. If your non-persistent messages are 100K and you have your queues set at the 64KB default, I'm pretty sure they go right to disk. That's why you should tune that non-persistent message buffer. Hopefully something is already waiting for these non-persistent messages so they get handed off directly in the manner that T. Rob and I mentioned earlier in this thread. Then there's no I/O at all. Hope this helps... any IBMer's want to comment -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Wien.AC.AT]On Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, May 29, 2003 6:11 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi st m essages Gary, I think you answer to Q2 pertains more to when a message is about to leave a server to go onto the next one. That setting tells the receiving side how soon it can have the Nonpersistent message in relation to the batch of messages coming across the channel. I am curious about once the messages have already been accepted on the HUB. Whether they were persistent or not, regardless of the channel speed setting, at any given moment on our busy HUB, the QM finds itself with lots and lots of messages that it now has complete control over. As it routes them thru the QMAliases and the XMITQs, it has to "stop" and log the persistent messages. I feel that this activity must somehow also effect the non persistent ones as well, since the QM can only do one thing at a time, regardless how fast it does it. If it is busy logging a persistent message, it can't route a non persistent one at that exact moment, correct? Regarding the queue buffer setting, if my messages are less than 64K, and because due to high activity all my channels in a particular SPOKE-HUB-SPOKE route are running, then a non persistent message would go in and out of each XMIT queue, in and out of each QM Alias queue and in and out of each application queue (assuming the app has an outstanding GET with wait) with no I/O to the disk? What if the messages are 100K non persistent ones and the buffer setting is still at default? Are you saying that a non persistent message is still written to disk? If yes, to me that sounds like there is no reason to not use persistence always on any message larger than 64K. Surely that can't be the case! Or is it like T.Rob suggested: Nonpersistent gets written to disk, persistent gets written to disk AND log, for a double I/O??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Gary, About a queue manager, or any process that runs on any computer, I have always assumed, maybe incorrectly, that a CPU on a box can only do one thing at a time. It may be incredibly fast, giving the illusion of many things happening at once, but when you get right down to it, everything has to wait its turn for the CPU to do its thing. And if the CPU is waiting to interact with the disk to write a persistent (or bigger than 64k non-persistent) message (I guess even if that message is going to blink in and out of a QM Alias or XMITQ???) then the CPU cant go on to handle non persistent messages. ??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:47 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persistent messages Peter, I'll gladly defer to any IBM MQ Developers lurking on the list since this is getting really 'down and dirty', but in the meantime I'll give you another $.02... Right about my answer to Q2... I guess I missed your point. Having read your follow-up, I would offer this theory. I think the queue manager MUST be able to do more than a single task at once. That's why it's made up of many individual processes which have dedicated tasks. I would think at any one moment there's a bunch of messages floating around in various states. If the messages are non-persistent, they're not logged and hence can be available immediately (if they're not IN SYNCPOINT with persistent messages). Non-persistent messages only get written to disk when there's not enough memory available to hold them on an individual queue. I'm not sure about persistent messages always going right to the queue file system, but my gut feeling is that they do. If your non-persistent messages are 100K and you have your queues set at the 64KB default, I'm pretty sure they go right to disk. That's why you should tune that non-persistent message buffer. Hopefully something is already waiting for these non-persistent messages so they get handed off directly in the manner that T. Rob and I mentioned earlier in this thread. Then there's no I/O at all. Hope this helps... any IBMer's want to comment -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, May 29, 2003 6:11 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi st m essages Gary, I think you answer to Q2 pertains more to when a message is about to leave a server to go onto the next one. That setting tells the receiving side how soon it can have the Nonpersistent message in relation to the batch of messages coming across the channel. I am curious about once the messages have already been accepted on the HUB. Whether they were persistent or not, regardless of the channel speed setting, at any given moment on our busy HUB, the QM finds itself with lots and lots of messages that it now has complete control over. As it routes them thru the QMAliases and the XMITQs, it has to "stop" and log the persistent messages. I feel that this activity must somehow also effect the non persistent ones as well, since the QM can only do one thing at a time, regardless how fast it does it. If it is busy logging a persistent message, it can't route a non persistent one at that exact moment, correct? Regarding the queue buffer setting, if my messages are less than 64K, and because due to high activity all my channels in a particular SPOKE-HUB-SPOKE route are running, then a non persistent message would go in and out of each XMIT queue, in and out of each QM Alias queue and in and out of each application queue (assuming the app has an outstanding GET with wait) with no I/O to the disk? What if the messages are 100K non persistent ones and the buffer setting is still at default? Are you saying that a non persistent message is still written to disk? If yes, to me that sounds like there is no reason to not use persistence always on any message larger than 64K. Surely that can't be the case! Or is it like T.Rob suggested: Nonpersistent gets written to disk, persistent gets written to disk AND log, for a double I/O??? -Original Message- From: Gary Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 1:19 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi st m essages Let me throw in my $.02 - which is actually less in Euros lately ;) Q1. There "could" be I/O to the queue filesystem... see more below Q2. The non-persistent messages will not be "affected" by the persistent ones as long as you are using NPMSPEED(FAST) on your channels. They do not wait for a syncpoint. Paul Clarke could further discuss this with you I'm sure! Consider using channel pipelining as well. Q3. Related to Q1, yes you will eventually see I/O under certain circumstances... The certain circumstances h
