Robot Apps out of memory

Small update on this topic. i have tested in different environments and machines. seems that on some machines the robot executor memory is stable.
performing some final tests to see what is the final output. Will come back with an update

Topic Update.
Issue is KIND OF solved…
We tested on 8 machines and on some of them it did not chug memory, running with no issues.
We did not manage to identify what is causing this.
We decided to change the machine on which the robot os running. I am 100 % sure it is not the bot development that is causing such issues.

Would be nice to identify what is causing this.( software, hardware ?)??

Best Victor

I seem to have a similar problem. Process reads emails, gets their attachment and then deletes the e-mails. After a number of transactions (number not consistent) the process fails. Outlook says: out of memory. Cannot open outlook on the robot manually either. After reboot everything works fine … for a few transactions. Error occurs always for the 1st time in in the delete mail, next transactions in the get mail.

@ivandeca please let me know if you manage to solve this issue. We though this was a infrastructure issue but it turns out we did not manage to solve it this way.
This topic is still open from my perspective.

Hi @Victor_Carmocanu

Ok, I will let you know as soon as we’re able to pinpoint the root cause.

@loginerror @ovi
Hi Guys,
Is there somthing you guys can offer here from a perspective we aren’t aware of. Because this is something that I have seen across various devices, and happens completely at random in my opinion.

Memory, Infrastructure, hardware were the first guesses but nothing seems concrete.

Would love to hear what you guys have to say for this?

–Abdullah

Hi @Victor_Carmocanu

I couldn’t quite solve the issue. So I switched to Get Exchange Mail Messages. Works for me, don’t know if this could be a solution for you too.

Kind regards

Hi All,

I wanted to run my experience and analysis because I’m one of the victims of these inteminently failing processes due to memory issues :slight_smile:

Uipath robot runs under the process with name uirobot so, I’ll be calling the process with this name onwards.

  1. uirobot process is 32 bit process and unfortunately it cannot exceed a total limit of 2GB memory so if you have many data tables, reading plenty of e-mails, having loaded steps within your process uipath easily reaches that limit. As a result of that uirobot process will hang up and probably will stay hanged up even in orchestrator until you physically remote to robot machine and dismiss the uipath robot error popup. Unfortunately I couldn’t find any other solution. For memory limitation of single 32 bit process please refer: 2 GB limit - Wikipedia
  2. The other thing, all the 32 bit apps can consume totally 4GB of memory at all. This means if you open 32 bit outlook + 32 bit excel + uirobot + any other 32 bit apps total memory consumption of these apps cannot exceed 4 GB of memory. Please refer: 32bit 64bit - how much memory can be accessed by a 32 bit machine? - Stack Overflow

Any of the conditions above reached the limits then any of your 32 bit apps will stop responding and again probably you’ll have misleading log messages from any other of your 32 bit apps, including uirobot process.
e.g. if uirobot process makes fill total memory limit for 32 bit processes which is 4 GB, you may have exception from any other 32 bit process like Excel or Outlook or any other 32 bit app even uirobot process itself because filling the total memory limit by uirobot will affect any of the other 32 bit applications to mulfunction due to lack of memory.

There are some modifications by changing memory management behaviour of Windows but I would literally not advise doing these things if you’re not sure what you’re doing and always make these changes in alpha test environment and with help of any WINDOWS EXPERT so, I’ll not mention about these things and keep them out of scope.

Unfortunately there is no solution for this 32 bit apps memory usage. Adding more memory or running the process under 64 bit OS will not help either. As far as I know UiPath has made some changes on uirobot process to use memory effectively but there are also some best practices for not to fill memory limit.

Such as:

  • Keep your processes simpler, do not include more than one sub process into one solution
  • Divide your big process into smaller and isolated but intercommunicating projects/processes
  • Please try different UiPath.Excel, UiPath.Mail or other related packages. There are also some minor bugs with that packages that may lead filling the memory limit
  • If you still need to keep processes within a single solution then consider following options
  • Divide your sub processes into different xaml files then call these xaml files with Isolation Mode = True so UiPath will start independent processes for these sub workflows but this technique also has penalties and the most important one is you cannot pass your variables from the main process to these isolated sub processes, such as in_Config e.t.c. objects cannot be passed as variable to isolated sub workflows
  • As a pre-last option: Dispose your variables after you don’t need them anymore (please refer: IDisposable.Dispose Method (System) | Microsoft Learn)
  • As a last option: Enforce using GarbageCollector effectively, I write effectively because it also requires best practices. Usually Microsoft .NET operates GarbageCollector in optimum state but sometimes you need to force garbage collection manually, please consider this article (please refer: .NET garbage collection | Microsoft Learn)

Cheers… :slight_smile:

5 Likes

Hi everyone,

Just adding my cents as well, since I have experienced this.

How I experienced it in my organisation was:

  • Sending and e-mail for each handled case (Send Outlook Mail activity)
  • If Outlook was not open it would utilize the service, which for some reason would not send until Outlook really opens (and it never would)
  • After x amount of cases the system would pop up with Outlook memory exception

We fixed it by switching to using Exchange activities rather than Outlook activities. This also reduces the steps that can fail, by interacting directly with Exchange, rather than through Outlook.

I realise this causes some changes due to passwords and usernames needed for the exchange activities, and for some it also means you cannot filter messages (this should however be available in the new O365 activities).

We did however never find the root cause of the problem as such.

Sonny

Hello Robot Masters and all,

I am probably the latest victim in this “Out-of-Memory” issue. Let me explain in 3 blocks where I stand.
Block1 -The Issue:
The robot process is a single process which opens many excels in a loop, reads data and creates another excel report. This excel report is already heavy with many macros and pivot tables. Whenever the robot completes the reading of the largest file and tries to merge the data together before pasting to excel report, excel shouts “out of memory” and since it is not handled the robot hangs.

Block2 - The Circus:

  1. To figure out where the process exactly fails, I used the logs well and finally was able to pinpoint.
  2. I have deleted all the unused variables, removed any unwanted in/out arguments, closed the previously opened workbooks (to be sure)
  3. Moved all the excel application scope activities together instead of opening multiple times inside a sub-process
  4. Divided and ensured smaller sub processes
  5. Ran the process is debug mode in production to replicate the issue (hopefully) and it runs smooth as butter. No errors what so ever. Only errors out while automatically triggered at the scheduled time

Block3 - The Pursuit for Solution

  1. Having done all these, I could say the issue is occuring at the exact same step everytime. Reading excels in loop and merging data to main excel report while triggered automatically.
  2. The deployment is in a VM and I am thinking this has to do something and the RAM and CPU sizing is probably lesser than my laptop :stuck_out_tongue: But I am not sure what is machine parameters at the moment the process errors. Planning to incorporate a capture machine parameters at this point.

I would love to hear if any of you have been able to find the exact reason for this and if really the hardware is to blame or how software and hardware interact.!

Regards,
Santosh Sundar

Hi, I would recommend the following best practices for memory consumption:

  1. After every append excel or write range activity within the Excel Application Scope use a kill process directly after it and ensure its outside of the Excel Application Scope then set the process to kill to “Excel” and the continue on error to “True” that way it will not break the process and ensure excel is killed every time after its being worked with.

  2. Any Excel Application Scope should be invoked as a separate workflow and then check the “isolated” feature within the properties pane on this invoked workflow. It ensures that UiPath runs this as separate memory allowing it to be more robust and not break.

  3. After working with your datatables within your process / after your transaction clear the datatables. UiPath is smart enough to store historic data and keep hold of the memory within the datatable so clearing it ensures a smooth restart for the next transaction!

Hope this helps buddy.

2 Likes