Non-paged dynamic memory

[Volker Halle]

Wim,

looks like we need to take a 'big step back' and re-assess the whole problem:

The summary line of your SHOW POOL/NONP/SUMM command says:

Total space used: 00D7AC80 (14134400.) bytes out of 0354E000 (55894016.) bytes
in 00002ED8 (11992.) packets

Total space utilization: 25.3%

I don't think that the system hung due to a pool consumption problem. Please check SDA> CLUE MEM/STAT - any nonpaged pool failures ?

Now if nonpaged pool on your running GS160 is all consumed, you would want to post a SDA> SHOW POOL/NONP/SUMM from the running system. But lets make sure you correctly relate the postings etc. for the 2 different problems.

Volker.

[Wim Van den Wyngaert]

Clue mem/stat of crash
(don't refer to original problem any more)

[Wim Van den Wyngaert]

Show mem of crash

[Wim Van den Wyngaert]

show pool/nonp/sum of running system.

(has less load now : no Sybase servers active)

[Volker Halle]

Wim,

something is not right here:

- the CLUE MEM/STAT from the crash shows 180 successful pool expansions, but no Expansion or Allocation failures at all.

- the SDA> SHOW POOL/NONP/SUMM from the crash shows 14 mio from 55 mio used, usage=25%

- the SDA> SHOW POOL/NONP/SUMM from the currently running system shows: 14 mio from 50 mio used, usage=28%

(the above 2 observations seem to be somehow consistent, but do not indicate a nonpaged pool shortage).

- yet SDA> SHOW MEM/POOL from the dump shows 0.7 MB free of 53 MB - I tend to NOT believe that.

Volker.

[Wim Van den Wyngaert]

HP analyzed the dump. It was a unknown pool corruption. May be solved by installing all patches, may be not.

Wim

[comarow]

Final comment.
Set npage_aggressive to 100
and npage_gentle to 100

They fragment pool. It tries to reclaim pool, but it was a great idea that has problems. Set NPAGEDYN where it will grow.

This will reduce interrupt stack and MPSYNCH
as well, especially over time.

In 8.2 they are both set to 100 by default.