OR Memory Issues
#1
Posted 09 September 2014 - 04:59 AM
As I've been working along on my route I've started to notice some kind of memory problem while test running in OR. If I run a test train of 2 RDCs through the new part of the route I'm fine, I can make it from one end that completed to the other end. If I run a 50 car freight, I get so far then OR crashes to desktop, sometime with an error message saying it's out of system memory, sometimes nothing.
As I build further south of Bellows Falls, running the same freight causes OR to crash further south. I'm just finishing up another eight miles south and now the freight crashes OR about eight miles further south then the last area it crashed in. The RDCs still make it through to the north end that's complete and if I run the same freight in MSTS it gets pretty rough loading the Bellows Falls tile, but it does smooth out and makes it to the north end of completed scenery.
I tried adding the -mem:1024 to the target line of the short cut and ran another test but it still crashed in the same location.
Here's the log... I hope the fact that it's 666 KB doesn't mean anything nasty!
OpenRailsLog.txt (666.49K)
Number of downloads: 154
Paul :-)
#2
Posted 09 September 2014 - 06:24 AM
Didn't you disabled the page file/virtual memory? Was the system memory really full? Else the application memory was full. Did you checked the "Use large address aware binaries..." setting at experimental tab?
#3
Posted 09 September 2014 - 06:30 AM
charland, on 09 September 2014 - 04:59 AM, said:
We don't support the MSTS command-line options, but nice try. :) If you're running a 64bit version of Windows (very likely if it is Windows 7 or later) you can select the experimental "Large address aware" option to double the amount of usable space for Open Rails.
Whatever you're running, press Shift-F5 until you see "DEBUG INFORMATION" on the HUD/F5 display - this includes a textual "Memory" line and a graph (bottom right in orange) of Open Rails' memory usage relative to its own limits. Note that this limit is a limit on OR and has no relation to the operating system or your system's amount of RAM.
You can probably save and resume when the memory starts getting risky (around 1.5GB of 2.0GB) to side-step the problem for now.
It's very likely we have some memory leaks in OR, given the size and complexity of the code, but it's tricky to pin some of them down. Is this route freely available anywhere or have you experienced the same problem on another route that we might be able to try?
#4
Posted 09 September 2014 - 06:39 AM
OK, yes for the Windows 7-64.
"Large Address Aware"... is this somewhere in OR or Windows? I'll press F5 and see what I can see. I'll try the save and see if I can resume but it's usually crashing to desktop and it's not like there is much notice before hand. I will try saving it just before the area it's been crashing and see if I can resume it and pass the area though.
The route is what I'm currently working on and can upload a beta if you'd like to see what's happening yourself.
Paul :-)
#5
Posted 09 September 2014 - 06:46 AM
James Ross, on 09 September 2014 - 06:30 AM, said:
Now that's a problem that i want to ask about. Is this limit can be lifted by using newer .net or 64 bit compilation (if that's possible). I notice that when OR memory reaching 900 mbyte then the game starts with light stuttering, at 1500 mbyte it does heavy stuttering and sometimes stops for seconds. Of course save and resume solves the problem(until reaching another object heavy part of the route), as after resume the memory usage is much lower.
charland, on 09 September 2014 - 06:39 AM, said:
As i wrote before, it's in openrails options on experimental tab.
#6
Posted 09 September 2014 - 07:06 AM
disc, on 09 September 2014 - 06:46 AM, said:
XNA is 32bit-only, so OR must stay in 32bit for now - that means we're limited to 2GB or 4GB (using large address aware). New versions of .NET won't help that. However, they could help the stuttering you see (note that I do not see this almost at all) due to improvements in the memory profile and GC. There's no guarantees though, and we can't go up to .NET 4.5 without losing Windows XP support - which is still important, but probably not for much longer.
#7
Posted 09 September 2014 - 07:47 AM
It therefore seems that OR in its present state requires some serious horsepower under the bonnet to totally eliminate stuttering.
#8
Posted 09 September 2014 - 08:11 AM
copperpen, on 09 September 2014 - 07:47 AM, said:
I have an Core i7 at stock 2.80GHz so I think it may depend more on the cores/threading than raw power.
#9
Posted 09 September 2014 - 08:34 AM
OK, I did find the checkbox for Large Adress Aware and that cured the problem, bumping the available RAM to 4 GB. I did notice something interesting using the graphs, so I took some pictures along the way. After loading the heaviest tiles and then traveling through what should have been easy rural scenery, the game still held on to the heavy Bellows Falls tiles for seven miles before deleting them from the memory.
First shot is from opening the activity, just terrain, track, toggled water, and telephone poles... using about 1 GB:
http://i479.photobucket.com/albums/rr160/paul_charland/ORgraphA_zps1f0c0ab7.jpg
Second shot, this is where it was crashing, loads that big tile and then crashed, now using about 2 GB.
http://i479.photobucket.com/albums/rr160/paul_charland/ORgraphB_zpsa3acc4c7.jpg
Third shot, this is about 7 miles north of Bellows Falls, the heaviest tile on the route so far, it has 2250 objects. The train is now on a rural tile at the end of the completed scenery and the usage has dropped from about 2 GB to about 1.5 GB.
http://i479.photobucket.com/albums/rr160/paul_charland/ORgraphC_zps3e4e8c7d.jpg
Forth shot, three miles north of the last shot, that's three miles of just terrain and track, so why hasn't the usage dropped to 1 GB like the activity started with as there is even less to draw with no telephone poles and no water?
http://i479.photobucket.com/albums/rr160/paul_charland/ORgraphD_zps44db7661.jpg
Paul :-)
#10
Posted 09 September 2014 - 08:35 AM