Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008158opensim[REGION] OpenSim Corepublic2017-04-28 11:162017-05-07 18:07
Assigned Todjphil 
PlatformPCOperating SystemWindowsOperating System VersionSeven
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0008158: [MEMORY] memory leak or normal behavior
DescriptionI noticed something with memory use
(Obtained with osGetSimulatorMemory)
I tested on 2 different pc and i have 2 different results.
PC 1 = Desktop Win 7 32bits with 3 Gigas Ram and Dual CORE CPU
PC 2 = Laptop Win 10 64Bits with 32 Gigas Ram and CPU i7 4 Core 8 Threath
The content of the region is identical
Approximately 500 scripts
Many scripts using dynamic texture
Very little physical prim (10 max)
UbODE is used and there are mesh on the region
Some NPCs too (10 max)
On PC 1 there are 1 simulator with 9 regions (attached to OSGrid)
On PC 2 it is 1 simulator with 3 regions (in Local Standalone mode)
Tested too with PC 2 and 1 simulator with 1 regions attached to OSGrid
On PC 1 i see +/- 300Mb of memory used.
Screenshot: [^]
On PC 2 i see +/- 1024Mb of memory used.
Screenshot: [^]

On PC 2 (with 1 regions attached to OSGrid)
i see +/- 900Mb of memory used.
Screenshot: [^]
I would like to know if this is normal or this is a memory leak ?

Thank you in advance.
TagsNo tags attached.
Git Revision or version number
Run Mode Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineubODE
Script Engine
Environment.NET / Windows32, .NET / Windows64
Mono VersionNone
Attached Files

- Relationships

-  Notes
djphil (reporter)
2017-04-28 11:48
edited on: 2017-04-28 11:50

PC1 and PC2 now use the same simulator version

Now memory usage on PC 2 (attached to OSGrid) is +/- 600Mb [^]
It's already a little better ...
It is approximately double memory usage on a 64Bits system.

BillBlight (developer)
2017-04-29 13:58

64 bit applications normally use a considerable larger amount of memory than there 32 bit counterparts. It just seems to be the nature of the beast.
djphil (reporter)
2017-05-03 06:34

According to the research I did on the internet, a Pc 64bits does not use double memory.
However, some applications may consume more memory.
Personally i think the double is a lot ... but i'm not "expert".

What is it exactly for OpenSimulator ?
Can the double of memory be considered normal for OpenSimulator ?

Another thing, is it normal that OpenSimulator uses more and more memory if you do not restart it regularly ?

Still, the more scripts you compile, the more memory you use.
Even if the total amount of scripts on your region remains the same.
For example, you work on your script and compile it several times.
In this case you will notice your amount of memory used increase gradually each time.
Is that normal too ?

Would not there some memory leaks somewhere (For example with dynamic textures) ?

A lot of questions ...
Ferd Frederix (reporter)
2017-05-03 11:17
edited on: 2017-05-03 11:18

It is normal that OpenSimulator uses more and more memory if you do not restart it regularly. Memory is never reclaimed. Adding visitors will need to use more RAM, which will not be reclaimed. Dynamic textures also increase memory use. It is best to update them as slowly as possible, if ever.

djphil (reporter)
2017-05-07 10:20
edited on: 2017-05-07 10:25

The question may seem silly to you but why the memory is not claimed?
This is technically impossible or simply it is not implemented in opensim?

* Personally, i do not find it "normal" to have to restart a program so that it continues to function properly ...

UbitUmarov (administrator)
2017-05-07 10:44

there are several reasons for that
on top is programmer errors, i.e. true leaks im sure we have plenty :(

Another is memory fragmentation, a problem similar to disk fragmentation.
A major feature of so called managed languages is working around that.
we can say they do run defrag on the memory..
Now like on disk, that is a heavy operation, so it as speedups and rules..
it runs faster on small recent things.. less and less on older large ones.
additionally there are things it can't move around, like memory shared with the operating system or external native libraries.
So all this makes the "defrag" fail, some unused memory is never reused... new larger objects don't fit on the free holes and need more memory from the OS, etc..
hmm things aren't exactly like this.. just giving a idea...
UbitUmarov (administrator)
2017-05-07 10:49

another thing about c# with Just in Time compile is that memory is also used by code that is compiled into native code at run time, and some of that can't be moved...
And dominant language experts idea seems to be that memory is cheap.. have problems? buy more or another machine...
BillBlight (developer)
2017-05-07 10:56

Another issue here is windows itself is notorious for not releasing/reclaiming memory.

I have one sim that has been up for 40 days on linux and I do not see a significant "leak". (but this is just a test endurance sim I keep running for the hell of it)
UbitUmarov (administrator)
2017-05-07 10:59

if course we do have the scripts problem and use of AppDomains or not discussions...
djphil (reporter)
2017-05-07 18:07

Thank you for your informative comments.

- Issue History
Date Modified Username Field Change
2017-04-28 11:16 djphil New Issue
2017-04-28 11:48 djphil Note Added: 0031810
2017-04-28 11:50 djphil Note Edited: 0031810 View Revisions
2017-04-28 11:50 djphil Note Edited: 0031810 View Revisions
2017-04-29 13:58 BillBlight Note Added: 0031811
2017-05-03 06:34 djphil Note Added: 0031820
2017-05-03 11:17 Ferd Frederix Note Added: 0031823
2017-05-03 11:18 Ferd Frederix Note Edited: 0031823 View Revisions
2017-05-07 10:20 djphil Note Added: 0031831
2017-05-07 10:21 djphil Note Edited: 0031831 View Revisions
2017-05-07 10:23 djphil Note Edited: 0031831 View Revisions
2017-05-07 10:24 djphil Note Edited: 0031831 View Revisions
2017-05-07 10:25 djphil Note Edited: 0031831 View Revisions
2017-05-07 10:44 UbitUmarov Note Added: 0031832
2017-05-07 10:49 UbitUmarov Note Added: 0031833
2017-05-07 10:56 BillBlight Note Added: 0031834
2017-05-07 10:59 UbitUmarov Note Added: 0031835
2017-05-07 18:07 djphil Note Added: 0031836
2017-05-07 18:07 djphil Status new => resolved
2017-05-07 18:07 djphil Fixed in Version => master (dev code)
2017-05-07 18:07 djphil Resolution open => fixed
2017-05-07 18:07 djphil Assigned To => djphil
2017-05-07 18:07 djphil Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker