Interactive Client: Slow environment and System.OutOfmemory

[M_R_]

I am writing to ask for help with an issue we are experiencing with automated process executions.

To put you in context I will first comment on the architecture:

                - An App Server, Windows Server 2016, CPU 4 Core 2.10 GHz Intel Xeon E7-8870, 8GB RAM, 64-bit operating system.

                - An Interactive Client, with the same configuration as the App Server.

                - A SQL Server database with automatic growth.

                - Blue Prism version 6.8.1.     

We have been experiencing the issue since the beginning of November, with no apparent prior change. Previously the same daily processes were running sequentially and for 8 months they did not report a similar error. The symptoms we observed are:

                - Slowdown in the execution of the processes.

                - Stop during the execution of the "Automate.exe" Windows process in the Interactive Client.

                - Exception of type "System.OutOfMemory" in actions such as "Work Queues / Set Data" or "MS Excel VBO / Write Collection".

                - These are the errors we have observed from Windows Events in the Interactive Client:

The actions we have taken to try to solve the error have been to reinstall the .NET framework and implement the GC.Collect() function after processing each item in the queue of processes. This has not had a favourable result.

We believe that the error may be database related, as the 'BPASessionLog_Unicode' table is too large for the small number of processes (15). Because of this we would like to know how to clean this table in a safe way.

Anyway, we would like to know your opinion of the case with your experience in similar cases.

We look forward to hearing from you and remain at your disposal for anything you may need.

Thank you,

------------------------------
M.R.L.
RPA Consultant

------------------------------

[andrew.beard · Accepted solution]

Hi MRL,

Your suspicions around the SessionLog table are correct and highly likely the cause of the general slowdown of the environment. It is a common problem new(er) customers encounter. In summary the BP database is a transactional database so should not be responsible for the long term hosting of reporting data (such as session logs). Typically customers set up the auto archiving function and the reporting data, can then be stored elsewhere. There is also the DataGateways function that can be implemented to manage the reporting data.

• I suggest viewing - this Platform Basic DB Management recording on University that should prove useful 
• Support Center has a great article on the topic - here
• The DataSheet Maintaining a Blue Prism DataBase server on the Portal will also be of use
• For more information on DataGateways check here

Once your database is down to a manageable size again, it's also worthwhile implementing policies to ensure that the database doesn't encounter any significant leaps in size. All it takes is a new automation with high logging levels and a tight loop and vast amounts of data can be written the DB.

The above certainly should be enough to get you started, but also feel free to do some "digging" on the Community pages. It's a great source of info.

Hope the above helps.

Seasons greetings.

Andrew Beard


------------------------------
Andrew Beard
Senior Consultant
Blue Prism
Australia/Melbourne
------------------------------

[M_R_]

Hi Andrew,

Sorry for the late reply. The technical service also indicated the same causes. The problem was the size of the database. By launching the cleanup script, it was solved.

Thank you very much.

------------------------------
M. R.
------------------------------