Re: Oracle 10g on Windows 2003 x64 Memory Useage

On Aug 10, 7:28 am, Charles Hooper <hooperc2...@xxxxxxxxx> wrote:
On Aug 9, 6:14 pm, "Paul Linehan" <plinehan__A@xxxxxxxxxxxxxxxxxxx>
wrote:
I have read quite a few of your posts and I think
that:

a) you know what you're talking about

and

b) you genuinely try to help people.

I hope that this info can help you and/or others.

ForWindows, there is a nifty/cool/rad/awesome(for Yanks
only) - (choose term which hasn't gone out of fashion, or
better yet, the one which has come back into fashion!!)

Go towww.sysinternals.comandgo for procexp (process
explorer).exe - it gives more reliable results than
theWindowsperformance monitor.

Inconsistent numbers should not happen. The site also
has a number of other useful bits and bobs for anyone
concerned with performance.

Paul...

Thanks for the suggestion - I have not experimented with that utility
in quite a while.

Looking at the page file on the hard drive, it is currently at
3,199,488KB, with an upper limit hard coded at 4,092MB (4,190,208KB).

Process Explorer:
Commit: 13.6GB (roughly 14,260,634KB)
Commit charge current: 14,254,748KB
Commit charge peak: 18,208,828KB

(recorded roughly 60 seconds after the above)
Task Manager:
PF Usage: 13.5GB (roughly 14,155,776KB)
Commit charge total: 14,258,808KB
Commit charge peak: 18,208,828KB
Physical memory total: 16,772,124KB
" " available: 3,798,000KB

Comparing the numbers between Process Explorer (now a Microsoft
product) and Task Manager onWindows2003x64 are very consistently
inconsistent.
16,772,124KB
- 3,798,000KB
-------------
12,974,124KB physical memory in use
+14,254,748KB page file in use
-------------
27,228,872KB total memory usage

-or-

12,974,124KB physical memory in use
+ 3,199,488KB actual page file size
-------------
16,173,612KB total memory usage

I *suspect* that the problem has to do with the memory page size being
4096KB for applications using large page support, rather than the
expected 4KB memory page size. There is probably a bit of code inWindowsthat does not yet recognize the change (this is a new feature
forWindows), either that or Microsoft should patent the approach of
jamming 14,254,748KB of data into a 3,199,488KB file. :-)

Charles Hooper
IT Manager/OracleDBA
K&M Machine-Fabricating, Inc.

A member of this forum suggested to me a different possible cause for
the inconsistency of the page file usage numbers shown in the Task
Manager and Process Explorer. So, I used Google to search Microsoft's
site for additional clues.

It appears that on Windows XP and Windows 2003 Server that the "PF
Usage" statistic (not present in previous versions of Windows) is NOT
page file usage. Instead, it is total virtual memory usage for
Windows and all applications, which includes both RAM and data stored
in the page file (32 bit applications on 32 bit Windows have access to
either a 2GB or 3GB virtual memory range). The "PF Usage" statistic
is esentially the same as the "Commit Charge: Total" statistic, which
is the size of the virtual memory in use by all processes.

References:
http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part6/proch27.mspx?mfr=true
"Commit Charge: Total - Size of virtual memory in use by all
processes, in kilobytes."

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/taskman_monitor_perf_fields_overview.mspx?mfr=true
Commit Charge (K): Memory allocated to programs and the operating
system. Because of memory copied to the paging file, called virtual
memory, the value listed under Peak may exceed the maximum physical
memory. The value for Total is the same as that depicted in the Page
File Usage History graph."

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/taskman_monitor_perf_fields_overview.mspx?mfr=true
"PF Usage: The amount of paging file being used by the system. If your
computer is running near the maximum, you can increase the page file
size."

http://www.microsoft.com/technet/archive/winntas/maintain/monitor/03wntpca.mspx?mfr=true
"Commit Charge Provides information on the total memory used by the
operating system. Total lists all physical and virtual memory
currently in use. Limit lists the total physical and virtual memory
available. Peak lists the maximum memory used by the system since
bootup."

http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part6/proch28.mspx?mfr=true
"To see how much virtual memory your Windows 2000 Professional-based
computer uses, start all applications and use Task Manager to see the
Peak Commit Charge value. This value appears in the Commit Charge box
on the Performance tab. Commit charge is the number of pages reserved
for virtual memory that are backed by the paging file. Peak committed
memory is the highest amount of virtual memory (in bytes) that has
been committed over this sample. To be committed, these bytes must
either have a corresponding amount of storage available on disk or in
main memory. Compare this value against the size of the paging file to
determine whether the paging file is sized appropriately."

http://www.microsoft.com/technet/archive/ntwrkstn/reskit/03tools.mspx?mfr=true
Shows "Mem Usage" where later versions of Windows show "PF Usage".
Windows Vista shows "Memory" in the same location. The "Page File"
statistic in Vista, which is currently 1471MB (roughly 1,507,328KB) on
my laptop, matches up very closely with the value 1,512,852KB reported
by "Commit Charge Current" in Process Explorer.

Note that there is a bit of inconsistency in the above quotes, which
are all from various Microsoft sources. From the above, using the
numbers that I previously posted:
14,254,748KB (PF Usage, Commit charge total)
-16,772,124KB (Physical memory total)
+ 3,798,000KB (Physical memory available)
-------------
1,280,624KB (Calculated page file size in use)

This seems to make a bit more sense, as the calculated page file in
use falls below the hard coded maximum page file size of 4,190,208KB.

Thanks to Paul Linehan for suggesting the Process Explorer utility,
Howard Rogers for providing a reference to a related Oracle bug, and
Yong Huang for suggesting that there is possibly a different
explanation for the inconsistency.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

.

Relevant Pages

  • Re: Running out of memory - but Im sure I have enough
    ... However, according to Task Manager, PF Usage is: 1.06 GB. ... The system allocates blocks of virtual memory to applications. ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Running out of memory - but Im sure I have enough
    ... Thanks for the Page File Monitor tip. ... Is my PF Usage 118MB or 1.06GB? ... I have not installed any memory boosters. ... > The system allocates blocks of virtual memory to applications ( ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Page File excessive usage
    ... using a huge amount of virtual memory. ... memory sizes and a reboot doesn't seem to affect it. ... Does anyone have any idea of what might be causing this memory usage? ... There's something seriously wrong with this server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Running out of memory - but Im sure I have enough
    ... > don't see how it could be a memory leak if my commit charge won't go above ... > I use Norton AV and Web Root Spy Sweeper, ... > 9:34 PM: Processing Startup Alerts ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Low Virtual Memory Messages
    ... The Commit Charge Peak is very high. ... I ran Disk Cleanup but did not remove Temp Sync Files ... I should have enough memory. ...
    (microsoft.public.windowsxp.basics)
Loading