Reducing memory usage of marker tracking service?

We're running into a sporadic crash that seems to be occurring when the marker tracking service is activated. The logs seem to have a reference to 'lowmemorykiller' being active. The top two processes taking up memory are our own app (5.8GB), and then /system/bin/marker_tracking_service clocking in at 2.8GB!

Our hypothesis is that the system is getting memory pressure and then kills the heaviest app (ours). While we will obviously look for ways to reduce the memory footprint of our app, is there any way to make the marker tracking service less memory hungry? It is taking more than 50% as much memory as our rather complex Unity based app.

Thanks for any guidance you can provide!

ML OS 1.7.0 (but this issue happened on earlier versions also)
App built with Unity 2022.3.29f1

Hi @om-iman,

Are you using OpenXR or the MLSDK to develop your application? Does the memory usage fluctuate or does it tend to stay consistent?

Best,

El

MLSDK. Usage is relatively consistent. There aren’t any huge spikes.

Hi @om-iman,

You can try adjusting some of the values using a custom marker tracking profile. I would try reducing variables such as the fps hint and speed to reduce computational load. I would also check out the Unity Profiler to get a deeper look into the performance of your app.

Let me know if you have any further questions.

Best,

El

Best way to reduce memory footprint is running the ArUco tracker without edge refinement. For that you need to configure it with a custom profile where you turn edge refinement off.

1 Like

This is helpful information, will try this. Thank you!

Adding on to @om-iman. Every time I call StartScanningAsync and StopScanningAsync even if waiting until Stop finishes, the seems the marker_tracking_service does not free up the memory. When I start the scanning again, it will increase memory. It acts as if its keeping the scanned environment in memory but not emptying it out when done. Eventually the device needs a restart if its under extended usage for a day where we/clients need to scan markers multiple times throughout. The priority on the marker_tracking_service is likely higher so the OS will rather kill our app when memory pressure gets too great. I can do a scanning routine and repeat it over 5-10 minutes and it will be using 20-30% of the system ram. I've been trying to see if its our usage of the app causing an issue but I can't rule out it being something outside my control. The service will also go down the list on the 'top' command when not used because cpu usage is down. But when its started back up again, it resumes where it left off.

I tried to kill the service but I don't think those permissions are granted. If I was able to kill and restart this service, I think this issue can be worked around. We're also not yet migrated to OpenXR and a release is too soon to take on that risk. I do see some fluctuation in the chunk of memory a single scan does as if its working and collecting garbage for the current scanning session but once the scan is done it's locked in and builds on top of that next time.

We resolved our issue by adjusting the tracker settings as follows: CornerRefineMethod.None, ResolutionHint.Medium, FPSHint.Medium, CameraHint.World, disabled Edge Refinement, FullAnalysisIntervalHint.Medium. This resulted in a slower increase in memory usage. After 40 scans, the RAM usage went from an initial 250MB to around 550MB, a significant improvement from previous settings that caused up to 2-3GB of memory to be consumed. The previous settings also resulted in an automatic system restart when usage reached 50% after an extended scanning session with tracker and environment movements. Though, that isn't really a normal use case. Just adding this post for records, thanks!

The only setting that matters here is the edge refinement setting. Unfortunately you can only disable it using a custom profile configuration.

We have fixed/improved the high memory usage of the Marker Tracking feature in our next OS release.

1 Like

We were able to observe lower memory usage of the marker tracking after disabling edge refinement. Thanks for that valuable tip. We look forward to the next release with the additional fixes/improvements in this area.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.