|Anonymous | Login | Signup for a new account||2013-05-19 02:37 UTC|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006034||opensim||[REGION] Specific OpenSim Module||public||2012-05-26 11:50||2012-10-08 20:15|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0006034: Warp3D Map module increase memory usage without end.|
|Description||If you enable the warp3d module on mono based systems.|
It starts to eat lots of memory, in myt case so bad that it jammed things.
useing mono 2.10.8
Solutution, turn warp3d off. or (not tested) i readed to turn map refresh off.
Offcorse turn it off is a shame, because the maptiles look so much nicer. !
Note: not seen this problem with windows.
|Tags||No tags attached.|
|Git Revision or version number||0db60eea85f16b0b428190590b8e8ca1392a2e35|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux64|
|Attached Files||RamBloat-test-B.txt [^] (14,832 bytes) 2012-09-07 22:20 [Show Content]|
Pixel Tomsen (manager)
edited on: 2012-05-26 20:58
yes, warp3d push memory temporary to much more....please read lates mantis's width theme about opensim memory usages.
|Yes, this is a known bug in Warp3D, since it was added to Core OpenSim. The only current work around is to only have new maptiles made on region startup.|
I've been testing Ram Usage & Memory bloat related issues and just completed tests with & without Warp3D maptile generation.
This is running under 32bit Windows with Net Framework 3.51 & updated to full 4.0.
OpenSim Version: odb60ee-r/19080.
There appears to be no difference noted with or without Warp3D being used. The memory leak & subsequent bloating still occurs. Although it is worth noting that when Warp3D is used there is a definite CPU spike when the tiles are generated, it only lasts for a short burst while being generated.
This is more likely related to something else going on and should probably be a related issue to http://opensimulator.org/mantis/view.php?id=6031 [^]
|The issue exists in MONO/Linux. Not Windows.|
|You may want to try git master code as of commit 514dd85. This makes sure all Bitmaps used by map image generation are explicitly Dispose()d but I don't know if this will help.|
confirmed for gentoo with mono 2.10.9 and
opensim commit 19417fca41e59e931193ee99d3e4a12092488f1f
what allocates this massive memory? and why isn't it
freed after the map tile is generated once? thats
Concur, agree with whitestar, the issue is relevant to http://opensimulator.org/mantis/view.php?id=6031 [^] and not contained or directly related to warp3d.
|Wondering if people see any difference with GC.Collect() added at git master 5eb2526. In principle I don't think it should except very temporary, but principle is not necessarily correct.|
I started testing this again, attached my results in a text doc to this Mantis named RamBloat-test-B.txt.
The platform info is within that doc, it is Win-Vista/32 with MySql running Warp3D. OpenSim is built on the host machine using runprebuild & resulting compile.bat file. OpenSim EXE is patched after compile to be LAA enabled.
INI Files are curret with release and adjusted according to the usual required settings.
OpenSim is running in Standalone mode with HG enabled.
On previous versions up to Git-3cf8edf - r/19899 Ram Bloat would slowly increase to well over 1.2 Gb at which time it would start to throw random errors although from the user perspective still fully functional. By 1.8 Gb ram used, system instability required a restart of OpenSim.
Hope this helps.
|Assuming the data in RamBloat-test-B.txt is every hour it looks nominal to me - OpenSim memory usage does not increase over time. What happens before commit 5eb2526?|
edited on: 2012-09-08 01:45
Justin, correct with the assumption, it does not seem to bloat up like previously and remains within acceptable & reasonably consistent ram use. This is why I posted my findings in the txt document to show that over a period of run time there seems to be no obvious misbehaviour under Windows.
I had tried a few version between my current & Git-3cf8edf - r/19899 in between but found I had to revert back due to quirks which are now resolved. Prior versions to R/19899 as indicated, the bloat would increase over 1.2 GB and finally reach instability @ 1.8gb. I did allow it to exceed 2.0 Gb on one occassion to see what would happen, had to force shutdown OS and restart the system.
All my builds are LAA enabled, therefore not capped at 1.2gb. I have also tested this on Win-7/64 Main system with 12GB ram and seen identical results. I do not operate any flavours of Linux.
The builds, prims & scripts have remained quite consistent and I do not feel they are a contributor towards any type of warp3D issues. At this point, I cannot see that using Warp3D under windows has any great issue as I cannot replicate bloating resulting from it. I have also not observed any error messages of any form since the changes have been made to Warp3D implementation.
This link will show the result of a Warp3D tile generated which looks 100% perfect in regards to what is on the land. http://i.imgur.com/haX0x.jpg [^]
** Note I have no idea how long images last on this site.
I am running just 100 regions for max load testing using 2 servers.
Prims are about 260,000 in total with many scripts. (Each server runs 50sims with 130,000 prims.)
With mono 2.10.9 / opensim 0.7.4 / CentOS Linux 5.8 / memory cache clear cron.
The servers named A and B. their servived hours/days were:
A) Linux 32bit Mem 8GB, with Worp3D .. 6 hours or less. big memory leaked.
A) Linux 32bit Mem 8GB, w/o Worp3D .. 24 hours or less. still memory leaked.
B) Linux 64bit Mem 4GB, with Worp3D .. 7 days survived, without restart.
Then I changed A)'s OS to 64 bit.
A) Linux 64bit Mem 8GB, with Worp3D .. 10 days survived. :-)
This means that my servers became stable with Linux 64bit, with Worp3D.
I suggest to check 32bit module's bug for Linux.
|2012-05-26 11:50||Digi Fly||New Issue|
|2012-05-26 20:58||Pixel Tomsen||Note Added: 0021561|
|2012-05-26 20:58||Pixel Tomsen||Note Edited: 0021561||View Revisions|
|2012-05-26 21:11||smxy||Note Added: 0021562|
|2012-05-29 17:07||WhiteStar||Note Added: 0021589|
|2012-05-29 17:17||melanie||Note Added: 0021590|
|2012-06-06 00:52||justincc||Relationship added||related to 0005713|
|2012-06-06 03:20||justincc||Note Added: 0021624|
|2012-08-08 19:59||thomax||Note Added: 0022000|
|2012-08-09 00:54||-rjs-||Note Added: 0022003|
|2012-09-06 23:52||justincc||Relationship added||related to 0006270|
|2012-09-07 00:04||justincc||Note Added: 0022526|
|2012-09-07 22:20||WhiteStar||File Added: RamBloat-test-B.txt|
|2012-09-07 22:29||WhiteStar||Note Added: 0022530|
|2012-09-08 00:17||justincc||Note Added: 0022545|
|2012-09-08 01:31||WhiteStar||Note Added: 0022546|
|2012-09-08 01:36||WhiteStar||Note Edited: 0022546||View Revisions|
|2012-09-08 01:45||WhiteStar||Note Edited: 0022546||View Revisions|
|2012-10-08 20:15||IshTom||Note Added: 0022814|
|Copyright © 2000 - 2012 MantisBT Group|