Unexpected high memory usage for shared objects

[marius-erbert]

Hello everyone,

Due to an internal discussion, I started some experiments with object instances. The aim was to find out where the technical limitation of nested objects is. This refers in particular to the required main memory for objects that are used by many other objects and of which there are thus several instances. In order to create any number of instances of an object, I have built a small object ("Instance Generator") with an action, which calls itself via an action (not via the page). This creates multiple instances of a sample object ("AppX"). As expected, the result was a linear increase in the required main memory with respect to the number of instances and the size of the sample object.
However, I created a copy and changed the sample object ("AppX (Shared)") to "shared". There is now only one instance of this object (this can be read here Business object information (blueprism.com) and for experiment I checked the correctness). Since there is only one instance, I expect a significant reduction in the required main memory which should be slightly above the memory consumption of the "Instance Generator". However, there was no significant difference between the shared and the non-shared version. The memory consumption here was on par with the version with the many instances. It looks to me as if the instances are still created in the background, although they are not used at all.

Is anything known about this? Are there other explanations for the behavior or did I understand s.th. wrong?

------------------------------
Marius Erbert
------------------------------

Edit: replaced confusing 'storage' terms

[ewilson]

Hello @MariusErbert,

Your graph states "Memory Usage" but you've mentioned "storage space" which implies on-disk or DB storage. Just to be clear, you're talking about the amount of memory consumed by creating multiple instances of VBOs, correct?

What is the run-mode setting of your test objects? By default, Blue Prism will set them to Exclusive. Have you changed that to Background? Do your shareable objects include an application model?

Cheers,
​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[marius-erbert]

Hello @ewilson

sorry for the confusion. You are right, I'm talking about the computer (main) memory.

The run-mode is Exclusive. I haven't tested any other mode, because this is usually not relevant for us (at least that's what we think) and, to be honest, I don't expect any difference.
I have tested objects with (App1, App3) and without application model (App2, App4).

Y-axis: memory consumption in B

X-axis: number of instances

Best Regards

------------------------------
Marius Erbert
------------------------------

[ewilson]

@MariusErbert,

Ok, so what you're basically investigating is a Singleton design pattern with the aim of determining what sort of memory consumption difference there may be. The assumption here is that a Singleton instance (i.e. Shareable) should cause the runtime resource and process to consume less memory overall. ​There was a similar discussion regarding a Singleton pattern earlier this year, but we didn't really touch on memory consumption.

I'll have to ask around with the product folks as I agree with your general assumption. I would expect to see a measurable difference (i.e. a decrease) in the overall memory consumption, but maybe there's some managed memory/garbage collection mumbo-jumbo going on here.

Cheers,

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[marius-erbert]

Hello @ewilson

Have you already been able to get some more information about this topic? If there is a memory leak here, this would have a relevant impact on the construction of nested (frequently used) objects.

Best Regards​

------------------------------
Marius Erbert
------------------------------

[david.l.morris]

I just wanted to pipe in a bit here. I'm no expert on efficient memory management, but the behavior seen here makes sense to me since each level of nesting creates new instances of the objects rather than keeping a reference to a single object instance. The only way it's possible to keep a reference to a single object instance is to call it from the same level. ProcessA can call ObjectA_Instance1 and ObjectB_Instance1, However, ObjectA_Instance1 cannot call ObjectB_Instance1; it creates its own instance of the object such as ObjectB_Instance2. At this point, ProcessA cannot directly call ObjectB_Instance2 as well. This generally didn't cause too many problems in the past, but when we switched from v6.5.1 to v6.10.1, we noticed a fairly dramatic increase in the amount of time it took for object instances to be created each time a new object is called so that the new object needs to be instantiated. In v6.5.1, a process would start in Control Room and move along pretty speedily, but in v6.10.1 with all other factors remaining the same, the process can take quite a bit of time to create each object instance as it hits those action stages for the first time during the run. These processes and objects I'm referring to all have this nested approach that is being discussed here, which is why I bring this up. I wonder if object instances handling was changed in some way between those versions and whether it can be addressed in future versions so it's more performant.

------------------------------
Dave Morris
3Ci at Southern Company
Atlanta, GA
------------------------------

[marius-erbert]

Hello @Dave Morris
​we had made a similar version jump to 6.10.1 and also noticed significantly longer loading times.
But back to your example:

If we talk about the non-shared Objects, your example is correct.

ProcessA:

* ObjectA_Instance1

* ObjectB_Instance1

ObjectA_Instance1:

* ObjectA_Instance2

* ObjectB_Instance2

...

ObjectA_InstanceN:
* ObjectA_Instance(N+1)

* ObjectB_Instance(N+1)

The expected memory consumption (rough estimation) in this case is:
  Memory(N, ObjectA, ObjectB) := C_default + N * Memory(ObjectA) + N * Memory(ObjectB)

But lets say, that Object A is non-shared (Thats the Instance-Generator in my example) and ObjectB is a shared Object. In this case there is only a single instance of ObjectB per Process.
The new instances are:

ProcessA:

* ObjectA_Instance1

* ObjectB_Instance1

ObjectA_Instance1:

* ObjectA_Instance2

* ObjectB_Instance1

...

ObjectA_InstanceN:
* ObjectA_Instance(N+1)

* ObjectB_Instance1

The expected memory consumption in this case is:
  Memory(N, ObjectA, ObjectB) := C_default + N * Memory(ObjectA) + Memory(ObjectB)
But the observation was still:

  Memory(N, ObjectA, ObjectB) := C_default + N * Memory(ObjectA) + N * Memory(ObjectB)

Because only one instance of ObjectB is used, (N-1) * Memory(ObjectB) is used too much.

------------------------------
Marius Erbert
------------------------------

[ewilson]

Hi @MariusErbert,

Apologies for delay. I've been asking around about this. So far I haven't received a concrete answer, but what I have heard is that some folks were under the impression that enabling​ the shared option only applies to the Application Model, assuming your VBO actually includes one. If that is the case, that means the VBO instances themselves would still be consuming memory. It's just that each instance of the shared VBO would point to the same Application Model definition if the VBO included one. 

Cheers,

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[John__Carter]

FYI the shared app model was originally introduced because some mainframe types (can't remember which) cannot be attached to. This meant you could not use the 'many small objects' best practice for solution design, and you had to go with the 'single mega object' approach. Shared app model was brought in primarily for that, and at the time it was thought it would become more widely used, but that hasn't proved to be the case.

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------