wkitty42 wrote in Sat Feb 02, 2019 7:31 pm:i've got 16Gig of RAM and FG will easily (or has in the past) eaten 10+Gig and lead my system into swap space where everything crawls... especially on long flights around the world without exiting or stopping... the last time this happened, it took me over 10 minutes to kill the FG task... why? because the system was so slow and it took minutes to even change from one screen to another...
A mild increase in memory use on long flights is to be expected, due to FG remembering your flight path; but that's only going to be a couple megabytes max. 10+ GiB sounds like a memory leak, and that would be a bug. Which of course I'm not ruling out; this is a C++ program after all, and it's written in a coding style that is still mostly how you'd do C++ in the 1990s. The prime suspect here is probably failing to unload cached assets (3D models, textures, terrain) as they become unused - if you keep loading new models and terrain tiles and textures, and never release the RAM, then a long distance flight will keep grabbing memory. But figuring out what to unload is a hard problem, and I wouldn't expect anyone to come up with a perfect solution.
wkitty42 wrote in Sat Feb 02, 2019 7:31 pm:my recommendation comes from the fact that the OS needs some of that RAM for its operation so there's less then 8Gig available for other programs... there's also that winwhatever loves to run programs and ""hide"" them in the system tray... folks think that's just a quick link area but it is actually running programs so there's more memory consumed and we haven't even started FG yet... these days, there is similar with linux and mac as well...
The running programs and how the GUI displays them are two different things. Those programs are running whether the system tray is there or not, in fact, programs can run without any visible cues whatsoever. If you want to know what is currently running, IIRC Windows has this "task explorer" thing that lists all running processes (or at least the ones you are allowed to see), including their resource usage.
On Linux, the situation can be similar, but you have a bit more control. A typical heavyweight Desktop Environment like, say, KDE, will typically spin up a bunch of services ("daemons") for all sorts of background tasks. Some of them are useful, some are convenient, some are questionable. None of them are mandatory for Linux in general though, and you can get a pretty lean-and-mean setup by configuring things to your needs and disabling services you don't need. And if you want, you can take it a step further and use a lighter-weight GUI with fewer bells and whistles; a minimalist window manager like, say, dwm, doesn't add any services at all, at the expense of providing few integration features, and fewer conveniences like for example auto-mounting or a notification tray.
On my Linux machine, the most memory-hungry services right now are TOR (anonymizing onion-routing web proxy, 30 kB resident), CUPS (printing system, 21 kB resident), and PulseAudio (desktop audio routing / mixing, 14 kB resident). There's also Xorg, which you might consider a "service", and that one is currently eating 250 MiB.
Right now, the system is using 4.8 GiB out of 7.62 GiB usable; most of that is being used by Firefox, Chromium, and two VirtualBox VMs. By shutting down the VMs, and closing a few memory-hungry tabs, I generally have no trouble running flightgear with plenty of memory to spare. A much bigger issue is that I have to make do with Intel Graphics, which limits the amount of vertex and texture data I can keep on the GPU, and bus throughput is mediocre, so once a scene gets too complex, performance plummets, despite plenty of RAM being available. If I had a better GPU, then I could probably get more use out of that RAM, too, and bumping RAM to 16 GB could then allow me to run at higher quality settings. Or I could simply keep those VMs loaded and not worry about RAM at all.