Hi,
I have had a similar problem with a production QPID system, running
Cento 6.8 for the past 14 months.
I tried the good advice that Ted gave, using the malloc tuning
environment variables, but unfortunately
this made no difference to our environment. We would get about 5 days
out of the system until the broker
used up all 64G of memory and got killed by the kernels OOM process.
I even tried using the gperftools tcmalloc library, but again this has
made no difference to the memory consumption.
Even moving up from version 0.34-1.36 didn't seem to make any
difference. Then about 8 weeks ago, out of the blue, the
problem just went away. The QPID broker is now staying solid at 5%
memory usage. We have not changed our usage pattern
in any way, still the same number of consumers and producers, but our
message flow rate has increased.
I have tried everything to replicate this issue, but to no avail.
Interestingly the problem only affects our production
system, all or other environments are fine. This leads me to believe it
is somehow flow related, which I know sounds
a bit stupid, but we had been running in production for about a year
before the memory problem arose (at a point in time when the
flow rates increased).
Then again 8 weeks ago the system encountered another increased step
change in message rates and the memory problem has now gone away (for
the time being!)
I don't know how flow rate would affect the memory in this way,
hopefully someone else might have some ideas.
The other area I looked at was message size (we have a wide range of
message sizes in our system (1k-10M), but I could never replicate the issue.
Sorry I cannot to be of more help, but if you do uncover the problem I
would be very interested to hear about it.
Clive
On 27/02/2018 20:36, jbelch wrote:
Thanks. I will try it and let you know if it works.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
