Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > Authors Russell Waliszewski

Currently we document some minimum database server resource requirements which can be found here: https://community.rsa.com/docs/DOC-86132

 

These are minimum requirements and do not mean that your system will always perform optimally as there are several factors that can contribute to the performance of your system. These factors range from the amount of Applications you are going to monitor, to the Change Requests you create & process, and the number of Certification cycles you go through. These are just an example of some of the factors that determine the resource requirements of the system. We can give you a more accurate sizing guideline with a detailed analysis of the data you will maintain/collect and the features used in the system. For more information contact your local Professional Services group to go through a sizing exercise or Edwin Mullie.


We do not recommend running the database on a virtual machine. If you plan to run the application on a virtual machine make sure you understand the basics of virtualization. Virtual machines share the resources with all the other virtual machines running on the same host server. Depending on your virtual infrastructure a virtual machine may not actually be able to allocate all the resources that it was created with. This overcommitting of resources such as memory will cause severe performance problems with the virtual machine and all the applications that are running on it. The allocation of resources and monitoring of a virtual server requires in depth knowledge so that all virtual machines on that server can service the applications they are hosting efficiently. The requirements for a VM running our application server can be found here: https://community.rsa.com/docs/DOC-86133

Have you had a collection job fail with a status of "Aborted (Circuit Breaker)" and all you did was kick of the collection again with "Ignore Circuit Breaker"?


The Circuit Breaker is there to protect you. In the past customers have had issues with their source data being incorrect and then that incorrect data being pulled into the system. For example, some collections are collected from CSV files that the customer builds with some manual or automatic process from various systems within their organization. If this aggregation process fails, or does not properly create the CSV files, then our collectors will gather the incorrect data and attempt to process it, typically resulting in cases where we think a significant number of objects or relationships have been deleted, which in turn can trigger all kinds of actions. The Circuit Breaker can prevent that. It raises a red flag that a particular collection has too much change, and gives the administrator a chance to review the raw data before we take it on board.


The Circuit Breaker is designed to stop a collection process that exceeds a percentage of change. That change could be something New, Missing or Changed, and it pertains to objects and direct entitlements. Our OOTB percentage change is 5%, but that can be adjusted. We allow the percentage to be changed system wide or it can be changed on a per collector basis as well as on the type of change that occurs. So if you know that your Ldap server does not have a lot of activity you can keep the OOTB percentage. If you have self-service HR system where the users are constantly making modifications to their information you may want to increase the percentage for that collector.

 

In the Collector's Guide there is a section on "Configuring a Data Processing Interruption Threshold" which will give you more information on how to adjust the setting.