GooglePhotorealistic3DTileset possibly leaking memory

Hi,

After some intensive testing with GooglePhotorealistic3DTileset, I could observe Chrome CPU memory (JS stack) growing without being fully cleared by garbage collection.

Using the Dev Tools garbage collection button does (virtually) not reclaim this memory.

GPU memory appears to be stable.

I am using Chrome’s Task Manager to keep track of these figures.

I tried (as seen in the Cesium for Unity forum) to set “cacheBytes” to 0 in order to ensure the memory footprint is not generated by cached tiles.

The leak can be observed in this copy of the original Google Photorealistic 3d Tiles sandcastle with cacheBytes set to 0.

Hi,

Sorry to bump this post but I really would like to get confirmation this issue is real and if so, is acknowledged.

Shall I create a bug report on Github instead?

Many thanks.

Hi,

Just bumping this to see if anyone has any suggestion.

Thanks,

Xavier

Hi @Xavier_Tassin,

Sorry for missing your messages, and thank you for pointing this out! I think GitHub will be the best place to track this.

In CesiumJS, cacheBytes controls GPU memory cache. It won’t limit the cache on the CPU.

I would be curious how you are testing. If you could provide the exact steps to reproduce, such as how you navigate the scene, that would be a big help.

Thanks,
Gabby

Could it be related to external tilesets not getting cleared?

We have the same problem in the native runtimes as well.

2 Likes

Hi Gaby, Thank you for your reaction.

I am simply using the Sandcastle example from my initial post and navigating the scene at random, pausing every now and then to let the 3DTiles to fully load. I monitor memory from Chrome dev tools “Memory” tab and watching the JS heap size grow.

Within a few minutes, heap size can grow up to 2 or 3 GB and will never be reclaimed by garbage collection.

Do I understand correctly that this pull request will normally fix this issue? Clear external tileset skeletons from tile tree to save memory usage by azrogers · Pull Request #1107 · CesiumGS/cesium-native · GitHub

Hi @Xavier_Tassin, that pull request resolved the issue in cesium-native. The issue still exists in CesiumJS. We are currently tracking it here:

I will add your report to that issue. Please feel free to add any additional information.