Extremely large memory usage

[terryreeves]

We have an unmanaged app calling a managed COM Interop dll that uses Microsoft.Graph client library version 4.40 to manage calendar items in O365. In some cases, we have observed extreme memory usage by the application. The memory usage counters grow by as much as 1GB/minute. I have tried various code changes to encourage the garbage collector to reduce the memory usage. The latest attempt involved not caching any GraphServiceClient or ICalendarRequestBuilder objects outside of the function call that uses them in hopes that the garbage collecter would collect them. The memory that is allocated appears to eventually get returned to the system.

Does anyone have any ideas what I should be looking at to figure this out?

[andrueastman]

Some APIs may return really large response values that could be optimized by using select query parameters, to omit properties that may grow unproportionally that you may not use/need.
The other alternative is probably in the downloading of content such as attachments that could be optimized by passing parameters to avoid buffering the response and reduce memory overhead.

Any chance you are able to correlate this with an specific API/endpoint being called on the graph to help understand this better?

[terryreeves]

Thank you for your reply. We get a GraphServiceClient with something like

        var scopes = new[] { "https://graph.microsoft.com/.default" };
        return new GraphServiceClient(clientSecretCredential, scopes);

We get calendar objects with

            calendar = gc.Users[Mailbox].Calendar;

To delete, we use

                            var evt = calendar.Events[item.ItemID];
                            var task = evt.Request().DeleteAsync();
                            task.Wait();

To add items, we use something like

                var scheduleItemToAdd = new Event();
               // Set item properties
               var task = calendar.Events.Request().AddAsync(scheduleItemToAdd);
               task.Wait();

To update items, we do something like

                        var evt = calendar.Events[item.ItemID];
                        var task = evt.Request().GetAsync();
                        task.Wait();
                        scheduleItemToUpdate = task.Result;

                        if (RequiresUpdate(scheduleItemToUpdate, item, out updatedScheduleItem)) // checks if update is needed and set properties as needed
                        {
                            var evt = calendar.Events[item.ItemID];
                            var task = evt.Request().UpdateAsync(updatedScheduleItem);
                            task.Wait();
                        }

I have simplified our code greatly to emphasize what we are calling. I have not found any correlation thus far.

The other interesting question is whether or not something outside the library is causing the problem. So far, we only have a couple of customers with this problem. We have other customers where we have not yet seen this problem. (That may be due to the level of use of the feature, but still it seems odd that we are not seeing the issue more generally.)

[terryreeves]

We found the problem. It was in the unmanaged code. We no longer have a problem. Thanks for the response.