Experiencing an extreme number PEGA0017 messages on one of our appservers
Hi all,
We are experiencing an extreme number PEGA0017 messages on one of our appservers.
Over 30.000 per day.
The other node has no issues and almost no PEGA0017 messages (just one once a week)
And, also weird, it give us these messages.
collections/mru/PropertyReference: Successfully reduced Concurrent MRU Map by 1 down to: 364807.
The setting however in this node is set to a value of 100.000
<env name="collections/mru/propertyreference/instancecountlimit" value="100000" />
In the SMA I can see these values within the cache reporting.
collections/mru/PropertyReference MRU Report Entry class: KeyedSoftReference
Current Target Limit Max Age(m) Drained #Drains Limited #Limits Maxed #Maxes Maint(s) HardToSoftCount SoftToHardCount SoftRefGCedCount
365324 80000 100000 120000 10 386824 4537 0 0 531425553 208545628 703291 531812383 527713262 3633731
The traffic among our 2 nodes is managed by a loadbalancer which is working round-robin.
Does anybody have any idea what is happening and why?
Hi all,
We are experiencing an extreme number PEGA0017 messages on one of our appservers.
Over 30.000 per day.
The other node has no issues and almost no PEGA0017 messages (just one once a week)
And, also weird, it give us these messages.
collections/mru/PropertyReference: Successfully reduced Concurrent MRU Map by 1 down to: 364807.
The setting however in this node is set to a value of 100.000
<env name="collections/mru/propertyreference/instancecountlimit" value="100000" />
In the SMA I can see these values within the cache reporting.
collections/mru/PropertyReference MRU Report Entry class: KeyedSoftReference
Current Target Limit Max Age(m) Drained #Drains Limited #Limits Maxed #Maxes Maint(s) HardToSoftCount SoftToHardCount SoftRefGCedCount
365324 80000 100000 120000 10 386824 4537 0 0 531425553 208545628 703291 531812383 527713262 3633731
The traffic among our 2 nodes is managed by a loadbalancer which is working round-robin.
Does anybody have any idea what is happening and why?
Of course I could change the settings to a higher level, but why are we experiencing this issue only on one node?
Thanks for your reactie in advance.
***Updated by Moderator: Marissa to add SR details***
Accepted Solution
Pegasystems Inc.
IN
Hello!
Upon reviewing the resolution note of the SR it was determined that changing the motinoring script to target a load balancer instead of a single,batch node helps resolve the issue.
Regards,
Lochan | Community Moderator | Pegasystems Inc.
Pegasystems Inc.
US
Interesting problem. I have a couple of thoughts:
1. Is your LB actually doing what is supposed to do? i.e., are the loads actually more or less evenly balanced over the period of time between the two nodes?
2. Are these two nodes configured absolutely identical in terms JVM arguments (heap size etc) and prconfig settings?
Achmea
NL
Hi Kevin,
I was also surprised so we had a look into the LB and it actually does balance the load correctly.
The two nodes prconfig files were checked and they look exactly the same. So, or one of our applications is liinking directly to the o so busy appserver or we do have an issue which we haven't addressed yet. I'm looking further into it.
Accepted Solution
Pegasystems Inc.
IN
Hello!
Upon reviewing the resolution note of the SR it was determined that changing the motinoring script to target a load balancer instead of a single,batch node helps resolve the issue.
Regards,
Lochan | Community Moderator | Pegasystems Inc.
IT
SK
Hello, Lochan, we are experiencing the same issue. Could you, please, provide some more details about the SR-A94489 - we are having the same issue on Dev and we do not have load balancer, Websphere node agent is used. We are considering raising an SR.
Kind regards,
Ivan
Pegasystems Inc.
IN
Hello Ivan,
I'm afraid the SR specific details cannot be shared by me. I will contact a few SMEs who could help you with your question.
Regards,
Lochan | Community Moderator | Pegasystems Inc.
Pegasystems Inc.
DE
Hi Ivan,
I worked on SR-A94489.
The main problem the issuer for that SR had, was that one node in their cluster showed that high number of PEGA0017 alerts, while the others do not have any significant number of those alerts. They searched for an explanation for that imbalance.
We found that they used a monitoring script that targeted directly that node, by avoiding the load balancer; due to the nature of that script, and the other load on that node, the PEGA0017 alerts were caused.
After they modified that monitoring script to use the load balancer so that the load was distributed evenly, they have not seen that imbalance any longer.
But it was not the script as such, but the load that it caused, together with the regular work load, that was the root cause for the PEGA0017 alerts.
In your case we recommend to have a closer look on the load on your system. So please issue a support request.