| Author |
Message
|
| pratuluv |
 Posted: Tue Jul 01, 2014 7:16 pm Post subject: RAM usage more than 100% |
 |
|
Acolyte
Joined: 25 May 2011
Posts: 53
|
Hi All,
My Production Server details are:
AIX platform
16GB RAM / 32 GB paging
MQ / WMB v 8.0.2 installed
The RAM used by my flows are around 19 -20GB on this server which is a concern.
CPU utilization is just 6-7%
We are using Shared variables to store large data from database and I suspect that is the reason for taking up so much memory. Can someone tell me how to recycle or reset this shared variable or optimize the flows.
Also, please enlighten me if it is normal to have more than 100% RAM usage. |
|
| Back to top |
|
 |
| Esa |
| Posted: Wed Jul 02, 2014 1:56 am Post subject: Re: RAM usage more than 100% |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| pratuluv wrote: |
We are using Shared variables to store large data from database and I suspect that is the reason for taking up so much memory. Can someone tell me how to recycle or reset this shared variable or optimize the flows.
|
If you are using ESQL shared variables, you should be able to reset them with DELETE statement. That should release the memory to the execution groups memory pool, but not to the operating system. In other words, it won't help you.
Use mqsireload to find out which execution group is causing the problem (or the worst problem): reload the eq and check if memory usage dropped. Then let a message trough and check how much memory was allocated (assuming the first messages causes the shared variable to be loaded from the database). Then send more messages and check if memory allocation grows or stays the same.
Growing memory allocation may be caused if the flows SET shared variables to NULL or -- this is more likely -- replace shared variable values with SET statement without first releasing the memory with DELETE statement. I suppose. |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Jul 02, 2014 2:21 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Esa wrote: |
| Growing memory allocation may be caused if the flows SET shared variables to NULL or -- this is more likely -- replace shared variable values with SET statement without first releasing the memory with DELETE statement. I suppose. |
Can you expand a bit on this Esa? Is setting a SHARED variable to NULL not sufficient to release it's memory usage (I thought this would be akin to setting an objet to null in Java)? And are you implying that using SET to override the value also doesnt? This seems very counter intuitive. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jul 02, 2014 2:44 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
If you SET a normal variable to null, the value is detached and the memory allocated for it is released when the flow instance terminates.
If you DELETE a normal variable the memory is released immediately.
I have seen an RFE that suggests that memory should be released immediately even if you use SET. Or was it an APAR? Anyhow, it's possible that this will change in some future fixpack.
If the same rules apply to SHARED variable, the memory that is detached with SET is not released unles the EG is restarted.
But, to be honest, I'm not sure if the same rules apply to SHARED variables. |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Jul 02, 2014 3:26 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Hrm - this has some quite serious implications. I wonder if someone from Development would be able to confirm/deny this?
I always just did SET MySharedVariable = NULL; when I wanted to 'clear' it. if this isn't sufficient then I have some re-coding to do... |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jul 02, 2014 6:56 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Fortunately it seems that I was wrong.
I created a little flow that does nothing else than SETs a 840 B string to a field under a SHARED ROW variable each time it runs and puts the input message back to the input queue.
I let the test run for a good while. The expected increase of memory allocation didn't take place. |
|
| Back to top |
|
|
|
|
