REPOST for Info- Contemporary thoughts Out-of-Memory Error

[Appliance 51]

Going through my archives today I ventured upon this post from the redoubtable Bob Scott.  As we have seen a number of returnees to FS9 recently it was considered pertinent to repost here for information.

 

"Subject: "Contemporary thoughts on the "out of memory" error" Previous topic | Next topic  

 

 w6kd Tue Feb-20-07 02:24 PM 

Member since Jul 25th 2002 

1975 posts       

 

#12194, "Contemporary thoughts on the "out of memory" error"

 

 

           Running FS9 with a recently-built cutting edge PC, I started seeing the dreaded Out of Memory error in FS9. My new PC has 2GB of RAM, and something like 85GB free on the drive FS runs on. How in the world could this be???

 

Well, a thorough sweep of the forums revealed that I was not alone. The majority of recent complaints of this problem are from people running relatively strong PCs, but with complex add-ons like the PMDG or Level-D, lots of scenery, traffic etc. Note that this is not a sudden CTD, but an error window that says your application has run out of memory, advising you to try freeing up disk space and run it again, even though you still have plenty of RAM and HD space. The most common time to see this error is on approach.

 

So I began the troubleshooting process. I found a scenario that produced an OOM virtually every time...a PMDG B744 flight from SimFlyers KDFW to SimFlyers KIAD, bad wx saved in ActiveSky v6.5, and Radar Contact controlling the way. Traffic was set at 34% from MyTraffic.

 

I started by monitoring the RAM usage. I note from reading through the forums that many people do not understand what they are looking at w/r/t RAM usage. The numbers reported in task manager only reflect the working set, or the RAM actually loaded in memory at a given time. The best metric to use is the "private bytes" as reported by the WinXP performance tool...this shows how much memory has been allocated to the program, including memory swapped out to disk or no longer reachable due to a memory leak. My memory allocation was very high...the perf monitor reported nearly 1000 MB at the beginning of the flight, and on approach just before the OOM error, nearly 1400 MB. The allocation was stable, with normal ups/downs due to weather/traffic throughout the ~2 hr flight. But as I approached the airport, allocations climbed steadily, and at the point when the airport scenery and all the traffic moving around the airport started to load...BAM, OOM error.

 

It's important to note that an OOM error occurs anytime a program attempts to allocate more than the 2GB max allowed for any Windows process. Doesn't matter what else is running on the PC...each process has its own 2GB virtual address space to stay within. It also doesn't matter how much actual RAM is in use...all that's needed is a request for more memory than WinXP can allocate. Seems to me that this sudden deluge of scenery and AI planes causes FS to ask WinXP for more RAM than it's allowed to have, causing the OOM error.

 

So I tried again a few times, this time with the AI slider at 0. RAM usage went down...in fact I only saw one OOM in four tries configured this way. But memory allocation was still near 1000MB approaching the field.

 

Something I saw in another post got my attention as well. Every .DLL file in the FS9 modules folder gets loaded with FS9. Every one. I ran WinDebug against FS9, and sure enough, every DLL in the folder was loaded and had an address range allocated to it. I had DLLs from the Flight1 Cessna 421 and Piper Meridian, Level-D, Lago's VimaCore, ActiveRadar etc, all loaded up and taking a bite out of a limited 2GB sandwich. If it's never called, it is paged almost immediately out and won't occupy RAM again...but it *is* still allocated and blocking available address space. Those watching the Task Manager will never see this, because once it's paged out, it's out of the working set reported by Task Manager--but not out of the picture.

 

So I cleaned out my modules folder of everything I didn't need to run the PMDG, Radar Contact, or my PFC flight controls. My RAM usage at start was now under 800 MB...approaching the field RAM usage was 75-100MB less than before, and I have not had an OOM since. This tells me I need to manage my modules folder on a per-flight basis, and this weekend I'm writing some batch files to move the right files in for each add-on I fly. No reason to have the PMDGOptions.DLL loaded when flying the Level-D, or to ever have ActiveRadar.dll since I don't use it. There were 15 DLLs there that I didn't need during the first test flights.

 

Last, I did a lot of experimenting with the /3GB option in WinXP Pro. After a lot of reading and experimenting, I'm still a bit puzzled...this option clearly results in some beneficial changes in disk caching behavior on my 2GB machine. Not sure why. But FS9 does *not* have the /LARGEADDRESSAWARE flag set in the executable's header, so even with /3GB specified, FS9 only gets the standard 2GB of address space from WinXP. I'm going to try making a change to the FS9 executable flag, and see if FS9, by some chance, is large address compliant, and can thus benefit from having an extra gig of allowable allocations. But that is complicated by the fact that every DLL loaded with FS9 will have to be compliant as well...I don't expect the results will be universally good.

 

So that's it. My little odyssey, and maybe a cure for a few of those seeing this frustrating error on an otherwise powerful system.

 

Cheers

 

Bob Scott

ATP IMEL Gulfstream II-III-IV-V

Santiago de Chile"

 

FS9 can indeed be made large address aware with excellent results when partnered by the 3Gb/4Gb patch.  Just Google  "large address aware" for the small app.

[alcanallen 0]

I get a OOM error when i get too clever fiddling with sceneries and once i get the offending entry sorted the sim runs as usual thus i don`t think it means your memory has exhausted itself but loading alien files causes the sim to bomb out. :p0128:

That`s my finding for what it`s worth.

 

And a prosperous new year to you all    

[mebull 27]

 

 

Going through my archives today I ventured upon this post from the redoubtable Bob Scott. As we have seen a number of returnees to FS9 recently it was considered pertinent to repost here for information.

 

Thanks Appliance, that was a very interesting (re)post. I had never considered that dll file(s) might have such a tie to memory usage or any effect as such. I do have the FS9 executable set to be large address aware and my 32 bit XP pro has the 3 or 4 GB patch applied to the boot.ini file. I have not had a OOM for quite some time now. The only factor missing (because of the newer GPUs with greater amounts of ram -1GB and more.) is how the PC ram and the GPU ram are allocated and used. If I am informed correctly the OS also sets aside PC ram equal to the GPU ram? ---please note the question mark!

 

Regards and Happy Holidays to all!!!!!   

[Appliance 51]

 

 

I had never considered that dll file(s) might have such a tie to memory usage or any effect as such.

 

Neither had I Mel.  Or if I ever did I have forgotten it ... getting on a bit you know !

 

Coincidentally today I noticed similar info re dll's posted in the P3D forum.  Life is strange sometimes folks.

[HaraldG 559]

Hi,

 

may I add another thought to this topic. I once read that the amount of entries in the scenery.cfg files might have an influence on the occurence of OOMs. I experienced the following: When I still used a 32bit WinXP system and my FS9 evolved further and further by addition of add-on sceneries, I suddenly experienced amassed OOMs with sceneries causing no problems before, for instance FlyTampa's Dubai or A. Svanidze's Tbilisi. I then reduced the entries in scenery.cfg - I deinstalled sceneries in completely different areas of the world so that I came below ca. 700 entries - and the problems at Tbilisi and Dubai were gone.

 

Since I use a 64bit Win7 system, I never had an OOM except one caused by a "problematic" add-on aircraft.

 

I'm not sure if this observation is pure random or a serious one. That's why I also want to add a big question mark to it. However, I think it's plausible that the more scenery loading at FS9's startup cause the more VAS usage.

 

By the way, I soon made my FS9.exe large address aware, but under WinXP, the so called 3GB patch via boot.ini file made my whole system nearly unusable. Under Win7, the large address awared FS9.exe runs very well, although I crossed the magic count of 700 entries in scenery.cfg again since then.

 

A happy new year to all of you!

Harald

[John Hinson 22]

Hi Harald,

 

With just under 1500 entries in my scenery.cfg file and a smooth trouble-free simulator, I think I can say with confidence that the quantity of entries is not significant - perhaps it is the content! This many years on I still see new sceneries with landclass files in with the main scenery which is one known key problem.

 

Best regards,

 

John