OOM Exception in v5 - InMemoryBackingStore #2309
Replies: 3 comments 1 reply
-
@torbenpedersen Any chance you can confirm the v5 version you are using? |
Beta Was this translation helpful? Give feedback.
-
I'm using V5 as well.
A customer has >70K users. AzureDirectoryUser doesn't hold a reference to user. The memory usage is around 3Gb and OOM. 7f73ea702588 152 617,952 Microsoft.Graph.Models.User[] Since I don't really need it can i somehow replace it with a simpler version? No ConcurrentDictionaries etc? I create client like this:
I don't need change tracking anywhere as I'm only reading. Can I disable the backing store completely? |
Beta Was this translation helpful? Give feedback.
-
Hey @torbenpedersen, @sherlock1982, We've had a number of improvements in this area that will hopefully resolve this for you. In case this is still an issue, please raise a fresh issue at https://github.com/microsoft/kiota-dotnet Improvements include |
Beta Was this translation helpful? Give feedback.
-
After conversion from v4 to v5, I'm observing OOM exceptions tied to the InMemoryBackingStore. Are there any options for reducing the in-memory size or replacing with a disk-based store?
UPDATE: the memory growth is occurring when pulling in chunks of messages from a specific folder -
...MailFolders.WithUrl(messages.OdataNextLink).GetAsync()
The request configuration is filtered to select a few attributes, such as ID and extended properties. In profiling the differences between v4 and v5 of the SDK but otherwise same logic, v4 reached 1.2 GB Private Bytes and v5 reached 5.1 GB. I will need to refactor the logic but if anyone has an idea on how to reduce the 4X memory increase, that would be appreciated!
Beta Was this translation helpful? Give feedback.
All reactions