| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQSI_THREAD_STACK_SIZE and implications of increasing |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Tue Dec 23, 2014 3:36 am Post subject: MQSI_THREAD_STACK_SIZE and implications of increasing |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We have a issue, which has resulted in my being asked to increase the WMB broker stack size significantly (from 2 MB to 20 MB) on AIX, (WMB 7006).
Reading the IBM advice below – I am cautious about doing this. Could anyone please tell me the possible negative consequences if we did this? Can we increase the overall EG memory size to offset this increase in stack size?
Our execution groups on this broker do run a large number of flows. However the stack limit has been reached due to recursive looping in one of the flows. We know that this is not a good design (and it will be re-written).
---- IBM ADVICE ---
MQSI_THREAD_STACK_SIZE
However, it should be noted that this environment variable applies to all the message flow threads in all the execution groups, as it is set at the broker level. For example, if there are 30 message flows and this environment variable is set to 2MB then that would mean that 60MB would be reserved for just stack processing and thus taken away from the DataFlowEngine memory heap. This could have an adverse effect on the execution group rather than yielding any benefits. Typically, the default of 1 MB (2MB on AIX) is sufficient for most of the scenarios. Therefore we would advise that this environment variable NOT be set unless absolutely necessary.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Dec 23, 2014 5:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Honestly, your best bet is to just try it in a test environment.
As it says, each message flow thread will reserve the stack size amount. So if you have an EG with a single message flow, but 20 instances, then that EG will reserve 20 times the stack size. And then each EG will also reserve chunks for each message flow instance they are running.
The real problem, though, is that if the general issue is caused by a recursive looping problem... that there's no possible value or amount of memory that can actually eliminate the problem even temporarily.
If it's an infinite loop, it will use up an infinite amount of memory trying to recurse.
If you really need to adjust this temporarily for a single flow, then I'd create a new local broker with a single EG and deploy the flow to that EG and increase the stack size for that broker. Obviously any temporary MQ routing to get data in and out, or otherwise to redirect traffic to the new broker.
If you set this for your existing broker, you could swamp the entire memory on the box without meaning to. Much easier to figure out the impact of a single flow with a known number of instances. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 23, 2014 5:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks, it's a finite loop - but it can be enough times to blow the stack.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
