Out of Memory

[Kosta 122]

Where is the Shader 3 most noticable? I tried over water, and saw little differences only. Ground - no difference. Clouds - I see some differences in lighting, but this might be also a texture thing. Personally, I will take no OOM with 6.5, ORBX and NGX over Shader3 anyday.

 

If memory usage (VAS) is increased, so must limit be increased, ergo 64bit native.

[sgreen91 182]

I just purchased P3D this weekend and installed on my computer. I run FSX maxed out with FSDT and NGX at 4096 texture load etc. and have never had an OOM issue.

 

I loaded up P3D and put in my NGX (with a HD paint of delta from McPhat) at the start up airport which is KGNU. I had only made one change to the p3d.cfg file which was increasing texture max load to 4096.

 

Within 2 minutes of loading I got an OOM (First one EVER!!!). I repeated this cycle over and over and over constantly getting an OOM before even moving the aircraft. Finally after a couple hours of deleting this and that I finally loaded up a default PMDG paint which is not as hard on memory as McPhat. I was able to takeoff and fly out away from KGNU.

 

While I was flying I opened up the Task manager to watch my memory usage and of course around KGNU it was around 3 to 3.1 million KB usage. Only maybe 100,000 kb away from an OOM. Well all the sudden it dropped memory usage down to 2.1 million KB within a couple seconds.

 

Long story short its the scenery causing the OOM. Norfolk is a scenery item in P3D that they made custom for this product. Disabled the sceney and no more OOM here. LM also has made custom scenery for some other areas in the scenery list so be careful going over those.

 

I don't know if it was this OP or somebody that said they were having OOM on a route between CHS and JFK. That means they were probably flying directly over this scenery which was causing an OOM.

 

I may be on the wrong track but this fixed my OOM issue for the 5 hours I've had it installed. Hope this helps somebody.

 

Sean

[Kosta 122]

-_- OOM memory usage cannot, I repeat, cannot be measured with the task manager. (I kinda gotta start talking like Mike)

 

I am tired of explaining it ever and ever again.

 

Sean,

 

it was around 3 to 3.1 million KB usage. Only maybe 100,000 kb away from an OOM.

 

That is quite wrong. While it may appear that OOM happens at a certain point in task manager, it is NO correct measurement. The correct way is to check the virtual size. One of the tools able to do it is the process explorer. NOT task manager.

 

I know, there is no place to check for explanation of OOM, so you have to go through various posts on AVSIM, but that is really so.

 

FSX/P3D will give an out of memory error ONLY when VAS (virtual size) reaches 4GB. This is what the limit is... rest what you noticed, that with deactivating scenery, using not McPhat textures, you don't have OOM - but of course, you are not pushing the sim to the 4GB limit.

 

The problem is that there is NO VAS and OOM error explanation document anywhere on AVSIM. Or anywhere else for that matter really. Not that I've found any. Sorry for going a little hard here ^_^

 

All the best.

[ChaoticBeauty 6,692]

What I noticed in P3D, why I was getting some OOMS - there is no startup menu, so what you do is load your default flight, then you change the aircraft, airport, maybe even time. Each of those reloads puts more usage into VAS.

 

One more reason for LM to add a start-up screen.

[Kosta 122]

One more reason for LM to add a start-up screen.

 

Quite correct.

[n4gix 4,947]

FSX/P3D will give an out of memory error ONLY when VAS (virtual size) reaches 4GB. This is what the limit is...

 

The problem is that there is NO VAS and OOM error explanation document anywhere on AVSIM. Or anywhere else for that matter really. Not that I've found any. Sorry for going a little hard here ^_^

Word Not Allowed,

 

I authored this Wiki entry several years ago, which describes in detail just what the "OOM" error message really means:

 

http://www.fsdeveloper.com/wiki/index.php?title=OOM_Error

 

Also, the proximate cause of VAS exhaustion isn't really surpassing the 4GB boundary. That it is most likely to occur as the upper boundary is approached is quite correct.

 

An OOM error will occur anytime there is no remaining 1MB contiguous blocks of virtual address space available.

[Kosta 122]

Ohhh, very nice! Didn't know about this one. Definitely going to book it.

 

And you are also correct, the boundary is not exactly 4GB, just that it always occurs over 4GB. Easy to measure though. I was only trying to simply the explanation, as not many will understand what you said above.

 

People need measurement tools and then to know how much. That's it. Learned that in the last couple of years battling OOMs and discussions here.

[n4gix 4,947]

The most clear "proof" that VAS has nothing whatever to do with physical memory is that even systems with only 512MBs of RAM have 4MB capacity VAS tables!

 

The VAS tables themselves are very small in terms of actual bytes, since it is simply like an index to a book, not the contents of the book. Whenever a running program is swapped into hard disk page memory, the VAS table for that process remains in physical memory, ready to restore the contents back to physical memory whenever called for by the OS.

 

On this Wikipedia page is a good illustration and explanation of how a VAS table is used to keep track of what's loaded into the physical memory at any given time:

http://en.wikipedia.org/wiki/Virtual_address_space

[mgh 89]

There is another source of OOM - exceeding the Commit Limit. It gives a Virtual Memory Minimum too Low message. This is a system, not a process. limit. It's the total of RAM plus all the page files on the system. It's a system limit that can be increased by increasing the size of the page file(s)..

 

Committed memory is the total amount of memory used/committed by the operating system and all processes running on the computer.

Windows 7 Task Manager performance pane shows two numbers against Commit (MB). The first is the Committed Memory and the second the Commit Limit.

[TheGrunt 44]

Bump for this.

 

I also suffered OOMs after installing more demanding addons and AI traffic. P3D is more sensitive for OOMs than FSX in my opinion and that is probably due the Shader 3.0 code. This is how I have avoided them so far:

 

1. Take autogen down one notch from maximum. IMO P3D looks even better with one less autogen as maximum seems overstuffed. I also ditched Aerosoft Manhattan X as it seemed to cause trouble when flying in NY area and everyone who knows that scenery understands why. It is just over the top with high settings. I also mainly fly ORBX, so it really doesn't matter that much for me.

2. For REXE I use 2048 clouds, IQ difference for 4096 is negligible, but amount of memory they consume is far less.

3. I prefer lighter AA for P3D. In game AA enhanced with 2xSGSS is enough for me. There are some jaggies on instrument panel, but overall quality vs performance is really good and memory consumption should be less compared to 8S+2SGSS we usually do (remember, DX9 maps VRAM to system memory and that is why it causes trouble for VAS too)

4. Don't overshoot with AI. I have MTX airliners 30 and GA 20.

5. So far I've used just 4.5 LOD. P3D loads textures far faster than FSX, at least for me, and higher LODs aren't that important. They of course look still better, but I wan't to avoid crashes as long as possible and maintain otherwise high detail and IQ.

 

and most importantly and this is the annoying part

 

6. For flight creation I do the following: default flight loads. I choose new location and P3D loads new location. After that I choose my aircraft, possible time, date and season and after all the selections and loadings I save the flight as a new default. After that I quit P3D and restart and P3D loads the default flight freshly to memory. Also, avoid jumping to windowed mode and back. Opening and closing ATC window may also cause trouble, as it seems to put the sim to windowed mode. Sort of, but I'm not so sure yet about that. At least one FSUIPC OOM warning started after ATC use one day so this is a possibility. I hate P3D ATC (because of the screen flashing, lack of transparency, no AA..), so I fly mostly without it.

 

P3D really lacks the startup screen and I hope Ideal Flight comes up with one soon.

 

There is still somethig really funny going on in FSX/ESP/P3D memory handling, which reflects to VAS: this habit for repeated scenery loading means and ending with OOM: that engine doesn't drop last load from memory completely and VAS mappings stay at least partly, which means gradual fragmentation of VAS and finally unused mappings reserving small amount of valuable VAS. Remember, every kernel module and such that FSX/P3D process needs has to be mapped to same VAS. There is the reason why VAS is always larger than the process memory consumption. Future DX11 version helps a lot, though addon compatibility is another question...

 

There is still a relation of course. For me, it is always pretty much the same: P3D process gets to about 3.2GB and VAS in that point is the dared 4GB (and this proves it is the VAS that is problem, not the 32-bit memory limitation).

 

DX10 and 11 really alleviates the problem as there is no requirement for VRAM mapping to VAS and soforth to system memory. That is also the reason why in FSX DX10 preview mode people don't suffer from OOMs and in that sense it is superior to DX9 mode. So this usually nowadays means 1-2GB less VAS mappings depending on the graphichs card memory, of course. Some of that amount is still defragmented and practically useless, so amount freed is not that big actually, but still large compared to normal memory consumption of the process.

 

All in all, to me it seems that engine has some sort of memory leak. It can't to a certain extent dump stuff from the memory and reallocate VAS mappings. I am not a coder, more like a communications guy as a profession, but this is how I see it, nonethless.

 

I still love P3D far more than FSX. It is more fluid and smooth, it's colour depth seems better and it is far crisper in image quality than FSX is. To me, world and cockpits look far more livelier. It is no go back for me to FSX. Few things fixed to P3D and couple of addons made compatible and we're there.

[Guest do_denver2]

This is definitely an issue. As you can see I have a pretty high end system, running ORBX, REX (2048 clouds), My Traffic X at %50, Track IR, Ezdok......... Sliders are pretty much maxed, Autogen at Very Dense, Bloom and Ground Scenery shawows are off. Cloud coverage density at 12............

 

With the new FSUIPC version it plays a dinging sound when you're getting low on memory. I have flown around quite a bit and not had issues with LOD at 6.5... except in PNW. Starting out from S43 Harvey Field which is just north of Seattle, heading off into the mountains to the East I fly around for quite a long time at LOD 5.5 with no issues. Bump it up to 6.5 and ding ding ding low memory...........

 

I also tested it several times S43 to Vashon Island, right over Seattle at 5.5. Get to Vashon island just fine. On both tests on the way back up to S43 ding ding ding, low memory. At LOD 4.5 I haven't had any problems, although I haven't tested it extensively enough to see if I get low memory even with that in certain areas.

 

ANother thing that helped was lowering AA in Nvidia inspector to 4x Combined paired with 4 x SGS..... I actually got the dinging in the mountains east of S43 with LOD 5.5 until I lowered it from 8x combined, then no problems, I flew around for several hours in the area, P3Dvana! Just amazing...........

[colang 2]

All in all, to me it seems that engine has some sort of memory leak. It can't to a certain extent dump stuff from the memory and reallocate VAS mappings. I am not a coder, more like a communications guy as a profession, but this is how I see it, nonethless.

 

Totally agree!!

I believe the engine don't release fully some memory when changing... scenery? texture? visuals?

Both FSX and Prepar3d suffers by this issues.

If you keep flying for enough time, minutes or several hours depending on your settings (mainly LOD_Radius and autogen density) and the plane you are using (simple or very complex like NGX),

sooner or later the OOM will happen.

 

In my system Prepar3D is long way better than FSX, I'm using higher settings than FSX and had only one OOM in many hours of flights.

I reduced LOD_Radius and all went ok up to now.

 

ANother thing that helped was lowering AA in Nvidia inspector to 4x Combined paired with 4 x SGS..... I actually got the dinging in the mountains east of S43 with LOD 5.5 until I lowered it from 8x combined, then no problems, I flew around for several hours in the area, P3Dvana! Just amazing...........

 

Interesting issue!!

I didn't tried reduce AA, I'll give a try to this hint.

Thanks for sharing it.

[OmniAtlas 93]

OOM fix as I mentioned in another similar thread posted here -- http://support.microsoft.com/kb/947246

 

I have no more OOM errors. I only get ENBSeries crashes now (!!)

[colang 2]

I gave a try to this fix, increased my heap values as indicated in the MS article.

Now I have to try some long flights...

[colang 2]

I tried last night a brief flight near Wien (Austria Professional) using Ants Sierra (not complex plane as NGX) LOD_Radius 6.5 and autogen max (ok little extreme settings) and... had the second OOM by Prepar3D in several months.

Reflying in same conditions repeated the error (after some minutes plus or minus).

Flying far from Wien was ok (into Austria), so maybe there is a high concentration in autogen and 3d objects.

So the settings is not bad but didn't made the miracle for me.

Anyway I want test a little further...