Hi,
We’re having IS 6.1 SP2 & Broker Server 6.1 installed on Sun Solaris 5.9.
Lately, we've observed using "top" command that the Broker process
"awbroker" memory usage keeps on increasing gradually.
We never had any Broker Server crash so far which is possibly due to Broker Server restart for other reasons once in a while.
After the restart, the "awbroker" process usage is around 20MB. However, it increases gradually by around 20 - 30 MB everyday. There has been no decrease in usage at all.
I'd like to know if this a normal behaviour or if its a memory leak.
and if there is any fix available if its a leak.
Any help would be greatly appreciated. Thank you very much.
The awbroker process itself is pretty small - it normally consumes less than 25 - 30 MB itself.
The other memory that the awbroker can allocate is used for the RAM-based storage cache, typically used for volatile documents and for temporary storage of guaranteed documents that have just been received into the broker. This memory area can grow up to 15% over the amount allocated for it.
By default, this memory area is 128 MB, I believe, but it can be explicitly set in the awbroker.cfg.
How big is the memory growing for the Broker process? Is it within the amount allocated for the RAM-based storage cache, or is it significantly higher?
Dear Phil,
Thanks a ton for your quick response !!!
We've explicitly set the "storage-max-cache-size" property in the
"awbroker.cfg" file to a value of 1024 MB.
And the last highest memory usage value we've seen for the awbroker process before restarting Broker Server was 640 MB.
So, it would mean that according to the "storage cache" property and our setting for it, the awbroker process can consume upto 1.2 GB of memory and not beyond this.
Therefore, it looks normal at the moment. :-)
Phil, I'd like to know what happens once the awbroker memory usage has reached its maximum specified limit + 15% of it.
Is the RAM storage cache no longer used or is it used based on temporary release of documents from the cache? Is there any effect on the performance?
Thank you once again Phil. Looking forward to your response.
When the Broker reaches its maximum specified limit, the RAM storage cache will still be in use, but the guaranteed documents maintained in that cache will have less time in place.
The idea behind the cache is first to store volatile documents, and second, to be a location for recently published guaranteed documents to be held in memory. The benefit of holding recently published guaranteed docs is that subscribers have more rapid access to the document (rather than the Broker having to retrieve it from disk). As the RAM cache hits max size, the “older” of the recently published guaranteed documents will drop out of cache.
So… no hit on Broker performance, but subscription performance for “older” guaranteed documents will be back to non-RAM cache levels.