| Author |
Message
|
| jhidalgo |
 Posted: Fri Jun 12, 2009 2:12 pm Post subject: Changing the default values |
 |
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
Is it a problem if I use the following settings:
MaxChannels: 10240
SYSTEM.DEF.CLUSSDR, CLUSRCVR, SENDER: DISCINT(0), LONGTMR(60), SHORTRTY(512), SHORTTMR(15)
My question is if this settings may affect the performance of the server, which I don't think should happen. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jun 12, 2009 2:47 pm Post subject: Re: Changing the default values |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jhidalgo wrote: |
| ...MaxChannels: 10240... |
Do you really need this many? 
| jhidalgo wrote: |
| ...DISCINT(0)... |
Never a good idea in my opinion.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Fri Jun 12, 2009 3:03 pm Post subject: Re: Changing the default values |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
| exerk wrote: |
| jhidalgo wrote: |
| ...MaxChannels: 10240... |
Do you really need this many?
|
No, but I don't want to limit the # of channels just because, and have to interrupt the services some day if that can be avoided 
| exerk wrote: |
| jhidalgo wrote: |
| ...DISCINT(0)... |
Never a good idea in my opinion.
|
the reason for this is: having the channel always connected helps me detect any network outage or change, let's say you had a channel without any use for a week, the networking guys changed the configuration of the firewalls, you didn't know and then when you needed the channel will not work, its better to detect a problem with the new configuration at the time they are implementing it, not days later
what do you think !¡? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jun 13, 2009 2:14 am Post subject: Re: Changing the default values |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jhidalgo wrote: |
| exerk wrote: |
| jhidalgo wrote: |
| ...MaxChannels: 10240... |
Do you really need this many?
|
No, but I don't want to limit the # of channels just because, and have to interrupt the services some day if that can be avoided
|
Why not 10239? Or 10241? How did you come up with that number?
| jhidalgo wrote: |
| exerk wrote: |
| jhidalgo wrote: |
| ...DISCINT(0)... |
Never a good idea in my opinion.
|
the reason for this is: having the channel always connected helps me detect any network outage or change, let's say you had a channel without any use for a week, the networking guys changed the configuration of the firewalls, you didn't know and then when you needed the channel will not work, its better to detect a problem with the new configuration at the time they are implementing it, not days later
what do you think !¡? |
I think you have a very pessimistic view of your network team. What about all those problems that they fix in the middle of the night. With a proper DISCINT, you sleep and the channel will work fine next week. With DISCINT 0 you keep getting paged for a retrying channel that has nothing to do anyway.
I doubt the firewall would allow connection to stay open for a week with no traffic on it anyway. Especially when firewalls are involved you should use a small DISCINT and end your channel gracefully on your terms when work is done, not have it killed by the firewall.
Inactive channels can't get into needless trouble.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jun 13, 2009 6:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jhidalgo wrote: |
| the reason for this is: having the channel always connected helps me detect any network outage or change, let's say you had a channel without any use for a week, the networking guys changed the configuration of the firewalls, you didn't know and then when you needed the channel will not work, its better to detect a problem with the new configuration at the time they are implementing it, not days later |
I would certainly hope that your network engineers give you the courtesy of a warning before implementing any changes and that you would test after the changes have been made... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jun 13, 2009 9:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
This is where we use a ROT (a rule of thumb). A ROT is a calculation that contemplates what you know now (current channels), plus anticipated growth, plus some fudge-factor (has nothing to do with fudge) that can/will accomodate the unknown.
So, if you have 200 channels today, and expect to grow 10% a year, 300 channels seems like a fair guess-timate that would last 2 years or so. 500 would be ok, too. 10,000 would seem to be an overkill.
As to your question about performance: empty channel table entries use virtual storage, which impacts real (RAM); but doesn't (in moderation) abuse system resources. If you have 200 channels today, but size unnecessarily for 10,000, I'd call that resource abuse - for midrange servers. z/OS is always an exception.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jun 14, 2009 9:10 am Post subject: Re: Changing the default values |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jhidalgo wrote: |
| No, but I don't want to limit the # of channels just because, and have to interrupt the services some day if that can be avoided |
Be aware that a channel table of that size will use noticible amounts of memory, which could be an issue if another memory hungry application is running.
| jhidalgo wrote: |
the reason for this is: having the channel always connected helps me detect any network outage or change, let's say you had a channel without any use for a week, the networking guys changed the configuration of the firewalls, you didn't know and then when you needed the channel will not work, its better to detect a problem with the new configuration at the time they are implementing it, not days later
what do you think !¡? |
I think you must be on a really good overtime package, because you're going to be called everytime the network hiccups.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jun 14, 2009 4:04 pm Post subject: Re: Changing the default values |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Vitor wrote: |
| Be aware that a channel table of that size will use noticible amounts of memory, which could be an issue if another memory hungry application is running. |
I believe that MQ does not use any extra memory (real or virtual) based on the the MaxChannels setting. It only uses memory if channels instances are starting or running.
| jhidalgo wrote: |
the reason for this is: having the channel always connected helps me detect any network outage or change, let's say you had a channel without any use for a week, the networking guys changed the configuration of the firewalls, you didn't know and then when you needed the channel will not work, its better to detect a problem with the new configuration at the time they are implementing it, not days later
what do you think !¡? |
That's a false economy. Your idea is sort of like leaving a light bulb on all the time so that you can keep checking that it hasn't blown.
It's better to have channels not running when they are not needed. If there's a network problem when the channel is not running it won't cause problems for MQ! I advise that the best DISCINT setting is at about twice as long as the interval normally seen between messages flowing across the channel, and use a minimum of 300 seconds.
_________________
Glenn |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Mon Jun 15, 2009 6:34 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
| fjb_saper wrote: |
| I would certainly hope that your network engineers give you the courtesy of a warning before implementing any changes and that you would test after the changes have been made... |
Yep, any configuration changes on critical resources as routers have to be notified, but more than that what will happen if the channels are always trying to connect is that I will get a log of every interruption that occours in my email, the timming of the incidents and the inmediate identification of any misconfiguration, it's a cheap feature giving me a lot of information in my perspective |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 15, 2009 6:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
... but what value is knowing that the network was interrupted at a point in time that MQ didn't need to care?
That is, suppose you trigger your channels, and only adjust your alerts to function after they see the channel change out of inactive status...
Then, you will not see, for example, any network outages that occur when MQ is not sending any data across the channels. So you've "lost" this information.
But, again, what value is this information? The network was unavailable... but you weren't trying to use it...
If you want to otherwise monitor the network infrastructure... just use ICMP or other standard network monitoring protocols... don't use MQ as a network monitor, please. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 15, 2009 6:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jhidalgo wrote: |
| what will happen if the channels are always trying to connect is that I will get a log of every interruption that occours in my email, the timming of the incidents and the inmediate identification of any misconfiguration, it's a cheap feature giving me a lot of information in my perspective |
What information? That the network went down and came back? Which it might well do routinely? What will you do with this information? Report to the network team that one of the routers is cycling? I also question that you'll get "a lot" of information. You'll know that the channel lost comms; the log message might give you a specific TCP/IP code but is more likely to give you a generic one. What will you do with this? Apart from fill your inbox with notifications & annoy your network people with spurious error reports.
One of the reasons for using WMQ instead of normal TCP/IP sockets is the ability of the MCAs to handle unreliable networks and recover properly while maintaining once-and-once-only message delivery. I don't understand why people are so keen to switch this feature off like this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 15, 2009 6:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
At the very least, I'd suggest searching for disconnect interval and retry. I'd also suggest reading the WMQ Intercommunications manual to get a good grasp of how channels operate, and how they try to recover from problems.
There is an assumption that RUNNING state is goodness. RUNNING means that a channel is either currently sending messages or capable of sending messages. It's the 'or' part that presents challenges.
RUNNING doesn't guarantee that the channel will successfully send a message when next a message arrives in the transmission queue.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Mon Jun 15, 2009 7:24 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
| very good points !, thanks for the input |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 15, 2009 7:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, I've noticed that a channel can be started (manually) and be RUNNING even when the sequence numbers are out of step with the other end.
It's quite annoying to find that out only when the first message is sent and it would be useful to have a way of making the channel verify the sequence numbers on start up.
Ours get out of step when switching to DR queue managers with the same name (but on different physical boxes). Yes I know this is not recommended but I don't have a time machine to go back and tell those who set it up! |
|
| Back to top |
|
|
|
|
