Are unbounded grain keys a bad idea?

[petedishman]

Hi,

We use Orleans as part of a telephony application where each call in to the system is managed by one activation of a grain.
The call gets a GUID assigned to it and we use this GUID as part of the grain key.

So a single activation of a grain will handle numerous events for this call, but once the call ends we'll effectively never use that key/identity again.

Originally we were on Orleans 8 and had no issues with this, but have recently upgraded to Orleans 10.

We're now seeing much higher memory usage on our instances (they're only small instances with 1.5Gb of RAM each) which has been tracked down to the local grain directory cache in each silo which is filling up with our ever growing set of grain keys.

I believe we can reduce the maximum size of this cache which should help us, but have we made a fundamental mistake with our choice of grain key?

Or are we ok as long as tune accordingly, is there anything else we should be looking to change as well as the directory cache capacity?

[ReubenBond]

Hi @petedishman your scenario sounds fine to me. I'll look into introducing a TTL into the grain directory cache so you can have the old behavior / memory usage profile again. The old cache implementation was replaced due to a pretty severe scalability issue, but we lost the TTL functionality in the process.

[petedishman]

Thanks, that's good to know.

I've done some testing locally and reducing the cache size keeps our memory usage low. It's still plenty big enough for our expected load.