A few general observations...
On 10/1/07, Durk Talsma <[EMAIL PROTECTED]> wrote:
> A few more random notes:
> - I usually see some swap space is in use (using KDE's system monitor applet).
> This typically fills up in the course of a few weeks until I restart KDE. I
> don't usually see this affecting FlightGear's performance though...
Swap space used is a poor indicator. Linux is aggressive in memory
management, and is known to swap things out even if you never run out
of memory, on the off chance that it will save some precious time
later when a memory hog comes along. Much better to look at how much
RAM is available. Of course, if your swap and RAM fills up to
overflowing you have an out of memory situation - and if this happens
frequently you want more RAM and/or more swap.
One of the more useful yet simple tools is free, if you know how to
read its output:
$ free -m
total used free shared buffers cached
Mem: 1518 1473 45 0 10 609
-/+ buffers/cache: 853 665
Swap: 1427 1 1425
I have 1.5G total RAM, and 1.4G are used, but when you subtract the
buffers and cache (which can be instantaneously freed at any time) I
have only 853M in use. You can get the same numbers from top, or by
doing "watch free -m" you can see the periodic results of free.
> - I let flightGear run overnight after yesterday's session. When checking this
> morning, I found the harddisk was ticking like crazy, the amount of swapspace
> had increased quite a bit, and the KDE system monitor was showing that close
> to 100% of CPU activity was run in "IOWait" state. This lasted for seconds on
> end. However, swapspace wasn't filled nowhere near capacity (probably
> something like 50 - 60%).
*sounds* like maybe you were thrashing, especially with the IOWait
stuff. Your swap space wouldn't necessarily be full to be thrashing,
just your RAM. Thrashing happens when the active set is bigger than
RAM - i.e. when the active parts of the active programs exceed the RAM
and things are constantly and repeatedly swapped in and out. Next time
check the RAM usage, and also check the page in/out activity with e.g.
vmstat (another useful program for monitoring memory usage).
>
> It seems like something is swapping, and it's occurring probably more on the
> Seneca than on other aircraft. What I don't understand is that Linux
> performance typically remains fairly stable, because the kernel is usually
> smart enough to swap out only the inactive bits of memory. These usually
> happen to be the lost memory fragments. That doesn't seem to be the case here
> though....
The kernel is smart enough to swap out only the inactive bits, but it
can't work miracles. :-) If there's not enough RAM for all the active
bits, then active stuff has to get swapped out, and it will soon be
swapped right back in. I've seen thrashing bring a desktop to its
knees. Seemingly locked up, my keystrokes would show up in the
terminal window after a few minutes, and I was able to initiate a safe
reboot. It only took an hour of waiting.
I've probably told you a lot of what you already know, but maybe you
can pick out that vital trick you may lack in how to pinpoint memory
behavior from my comments. Good luck!
--
Hans Fugal
Fugal Computing
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
