Inactive memory pages=0 in a very busy system while some performance problems ocurred.

[F. Javier Cobas]

Hi all,

While at some very bad performance moment in one of our systems, some memory performance data were collected and then compared to data from another "bussiness as usual" day.

Only odd thing i have noticed is that (for some hours in that problematic day) the  collected data showed no inactive pages left, tough the system was very busy and a lot of memory-intensive processes were running.

After several hours  it resumed its activity like always, and performances were ok then ...

Never seen that again in recollected data for this application, nor the performance problem either ...

Free list, active pages, etc ... during that problematic period of time seemed quite "normal", if compared with another "standard" day.

   inactive memory pages = 0 seem a normal output for memory stats in a  quiet system, but ...

    Is this an normal output for memory statistics  in a busy system ?
    Could it have a meaning for (bad) performance, anyway ?.

(Processes are distributed into more than one RAD. First thing  i thought of was some  resource constraint in some RAD).

Data follows,
 ----------------------------------------------------------------------
[ Hour  ] TotalMem;FreeMem;ActiveMem;InactiveMem;WiredMem;UbcPages#;FreeSwap

[ 17:44:20]  16777216;9747008;3676472;0;2821072;80083;16777216
 .../...  Inactive mem count=0; Some dire performance problems occurred.

[07:53:37]  16777216;8109784;5292504;0;2842264;240971;16777216
           Inactive Page Mem count begins to increase

[07:53:47]  16777216;7774168;5615592;12480;2842312;282919;16777216
[07:53:57]  16777216;7455472;5906896;39824;2842360;322750;16777216

[07:54:28]  16777216;6478336;6826088;97632;2842496;444873;16777216
..../... Performance recovers. Everything normal again

---------------------------------------------------------------------------------------------------

(Unfortunately there are no other vmstat fields available).


TIA. Javier.

[Dennis Handly]

What OS version are you using?  What program produced these stats?

[Steven Schweda]

> What Windows version are you using?

   None?  It _is_ a Tru64 forum.

> What program produced these stats?

   I'd guess "vmstat":

> (Unfortunately there are no other vmstat fields available).

[F. Javier Cobas]

Thank you Dennis and Steven,

Sorry, i forgot to mention that i was under Tru64 v.5.1.B OS, running in a 8-cpu Alphaserver DS25.

Data comes from an application DB that is monitoring the OS every 10 seconds.

Swapping is disabled in this system.

The eight cpus organizes themselves into two RADs. One comprises two cpus and the other the remaining six cpus.

The OS data collection program  has "vmstat" inside, but it seems to use the OS function "table" much more intensively.
Maybe other data comes from "collect" or perhaps it is calling some other OS functions to get the data.

Process data tables dumped by this application show that there is much less memory consumption by "application processes" when these performance problems occurred than under "normal" operation.

From time to time "user + system" time percentages are around 90-something percent in some CPU.

I thought that less memory consumption by app. processes may suggest there is some resource blockage in some of the RADs, or perhaps a priority inversion issue; But i was unable to detect this blockage in the "wait" column on the corresponding CPU stats.

Since i do not have a complete monitoring data set (for example like the WCHAN column in a ps command output) i am unable to check for priority inversion.