Oracle have changed there response when I pointed out that ask Tom
indicated that different operating systems appear to perform differently
Oracle's response is below and from all your replies this would appear to
be the case.
Thanks, for your help. stephen
**************************************************************************
***************
Yes, on most platforms the shared memory would be pre-allocated for the
SGA. equivalent to SGFA_MAX_SIZE. Solaris with Dynamic ISM enabled is one
exception.
There may be others. It's not 100% obvious if this is really wasting
resources. If the
memory is never being referenced it may not have to be resident in
physical
memory (though some platforms do try to keep the SGA "pinned" in memory).
**************************************************************************
*******************
Phone: 01737 27 5564
[EMAIL PROTECTED]
Mladen Gogala
<[EMAIL PROTECTED] To: Multiple recipients of list
ORACLE-L <[EMAIL PROTECTED]>
hia.net> cc:
Sent by: Subject: Re: 9i - Dynamic SGA -
SGA_MAX_SIZE
[EMAIL PROTECTED]
ity.com
03/08/03 05:19
Please respond
to ORACLE-L
Kirti, problem is in the malloc mechanism. The subroutine to free the
memory
doesn't return it to the OS, it returns it to the "allocation pool instead.
As a consequence, when oracle does "free", its address space is not going
to
go down. You realize, of course, that malloc, calloc, realloc and free are
the
only options, because of their portability. There are low level allocation
routines like brk() to increase the address space, but unaware of any
routine
to decrease the address space. Here is the manual page for the library
subroutine called "mallopt", which is mostly obsolete but still exists on
HP-UX. The mechanism remained the same, but the control was taken away from
the users. Manual page does illustrate the mechanism, though.
malloc(3C) malloc(3C)
NAME
malloc(), free(), realloc(), calloc(), mallopt(), mallinfo(),
memorymap() - main memory allocator
SYNOPSIS
#include <stdlib.h>
void *malloc(size_t size);
void *calloc(size_t nelem, size_t elsize);
void *realloc(void *ptr, size_t size);
void free(void *ptr);
void memorymap(int show_stats);
SYSTEM V SYNOPSIS
#include <malloc.h>
char *malloc(unsigned size);
void free(char *ptr);
char *realloc(char *ptr, unsigned size);
char *calloc(unsigned nelem, unsigned elsize);
int mallopt(int cmd, int value);
struct mallinfo mallinfo(void);
Remarks
The functionality in the old malloc(3X) package has been
incorporated
into malloc(3C). The library (/usr/lib/libmalloc.a) corresponding
to
the -lmalloc linker option is now an empty library. Makefiles that
reference this library will continue to work. Applications that
used
the malloc(3X) package should still work properly with the new
malloc(3C) package. If the old versions must be used, they are
provided in files /usr/old/libmalloc3x.a and /usr/old/libmalloc3c.o
for Release 8.07 only.
DESCRIPTION
The functions described in this manual entry provide a simple,
general-purpose memory allocation package:
malloc() allocates space for a block of at least size
bytes, but does not initialize the space.
calloc() allocates space for an array of nelem elements,
each of size elsize bytes, and initializes the
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August
1992
malloc(3C)
malloc(3C)
space to zeros.
realloc() changes the size of the block pointed to by ptr
to
size bytes and returns a pointer to the
(possibly
moved) block. Existing contents are unchanged
up
to the lesser of the new and old sizes. If ptr
is
a NULL pointer, realloc() behaves like malloc()
for the specified size. If size is zero and ptr
is not a NULL pointer, the object it points to
is
freed and NULL is returned.
free() deallocates the space pointed to by ptr (a
pointer
to a block previously allocated by malloc(),
realloc(), or calloc()) and makes the space
available for further allocation. If ptr is a
NULL pointer, no action occurs.
mallopt() provides for control over the allocation
algorithm
and other options in the malloc(3C) package.
The
available values for cmd are:
M_MXFAST Set maxfast to value. The
algorithm allocates all
blocks
below the size of maxfast in
large groups, then doles
them
out very quickly. The
default
value for maxfast is zero
(0).
M_NLBLKS Set numlblks to value. The
above mentioned ``large
groups'' each contain
numlblks
blocks. numlblks must be
greater than 1. The default
value for numlblks is 100.
M_GRAIN Set grain to value. The
sizes
of all blocks smaller than
maxfast are considered to be
rounded up to the nearest
multiple of grain. grain
must
be greater than zero. The
default value of grain is
the
smallest number of bytes
that
can accommodate alignment of
any data type. value is
rounded up to a multiple of
the default when grain is
set.
M_KEEP Preserve data in a freed
block
until the next malloc(),
realloc(), or calloc().
This
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August
1992
malloc(3C)
malloc(3C)
option is provided only for
compatibility with the old
version of malloc() and is
not
recommended.
M_BLOCK Block all blockable signals
in
malloc(), realloc(), calloc
(),
and free(). This option is
provided for those who need
to
write signal handlers that
allocate memory. When set,
the malloc(3C) routines can
be
called from within signal
handlers (they become re-
entrant). Default action is
not to block all blockable
signals.
M_UBLOCK Do not block all blockable
signals in malloc(),
realloc(), calloc(), and
free(). This option cancels
signal blocking initiated by
the M_BLOCK option.
These values are defined in the <malloc.h>
header
file.
mallopt() can be called repeatedly, but must not
be called after the first small block is
allocated
(unless cmd is set to M_BLOCK or M_UBLOCK).
mallinfo() provides instrumentation describing space usage,
but cannot be called until the first small block
is allocated. It returns the structure:
struct mallinfo {
int arena; /* total space in arena
*/
int ordblks; /* number of ordinary
blocks */
int smblks; /* number of small
blocks */
int hblkhd; /* space in holding
block
headers */
int hblks; /* number of holding
blocks
*/
int usmblks; /* space in small blocks
in
use */
int fsmblks; /* space in free small
blocks */
int uordblks; /* space in ordinary
blocks
in use */
int fordblks; /* space in free
ordinary
blocks */
int keepcost; /* space penalty if keep
option is used */
}
This structure is defined in the <malloc.h>
header
file.
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August
1992
malloc(3C)
malloc(3C)
Each of the allocation routines returns a pointer to space suitably
aligned (after possible pointer coercion) for storage of any type of
object.
memorymap() can be used to display the contents of the
memory
allocator. A list of addresses and block
descriptions is written (using printf()) to
standard output. If the value of the show_stats
parameter is 1, statistics concerning number of
blocks and sizes used will also be written. If
the value is zero, only the memory map will be
written.
The addresses and sizes displayed by memorymap
may
not correspond to those requested by an
application. The size of a block (as viewed by
the allocator) includes header information and
padding to properly align the block. The
address
is also offset by a certain amount to accomodate
the header information.
RETURN VALUE
Upon successful completion, malloc(), realloc(), and calloc() return
a
pointer to space suitably aligned (after possible pointer coercion)
for storage of any type of object. Otherwise, they return a NULL
pointer. If realloc() returns a NULL pointer, the memory pointed to
by the original pointer is left intact.
mallopt() returns zero for success and non-zero for failure.
ERRORS
[ENOMEM] malloc(), realloc(), and calloc() set errno to ENOMEM
and return a NULL pointer when an out-of-memory
condition arises.
[EINVAL] malloc(), realloc(), and calloc() set errno to EINVAL
and return a NULL pointer when the memory being
managed
by malloc() has been detectably corrupted.
DIAGNOSTICS
malloc(), realloc(), and calloc() return a NULL pointer if there is
no
available memory, or if the memory managed by malloc() has been
detectably corrupted. This memory may become corrupted if data is
stored outside the bounds of a block, or if an invalid pointer (a
pointer not generated by malloc(), realloc(), or calloc()) is passed
as an argument to free() or realloc().
If mallopt() is called after any allocation of a small block and cmd
is not set to M_BLOCK or M_UBLOCK or if cmd or value is invalid,
non-
zero is returned. Otherwise, it returns zero.
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August
1992
malloc(3C)
malloc(3C)
WARNINGS
malloc functions use brk() and sbrk() (see brk(2)) to increase the
address space of a process. Therefore, an application program that
uses brk() or sbrk() must not use them to decrease the address
space,
because this confuses the malloc functions.
free() and realloc() do not check their pointer argument for
validity.
If free() or realloc() is passed a pointer that was not the result
of
a call to malloc(), realloc(), or calloc(), or if space assigned by
an
allocation function is overrun, loss of data, a memory fault, bus
error, or an infinite loop may occur at that time or during any
subsequent call to malloc(), realloc(), calloc(), or free().
The following actions are not supported and cause undesirable
effects:
o Attempting to free() or realloc() a pointer not generated as
the result of a call to malloc(), realloc(), or calloc().
The following actions are strongly discouraged and may be
unsupported
in a future implementation of malloc(3C):
o Attempting to free() the same block twice.
o Depending on unmodified contents of a block after it has
been
freed.
Undocumented features of earlier memory allocators have not been
duplicated.
COMPATIBILITY
The only external difference between the old malloc(3X) allocator
and
the malloc(3C) allocator is that the old allocator would return a
NULL
pointer for a request of zero bytes. The malloc(3C) allocator
returns
a valid memory address. This is not a concern for most
applications.
Although the current implementation of malloc(3C) allows for freeing
a
block twice and does not corrupt the contents of a block after it is
freed (until the next call to realloc(), calloc(), or malloc()),
support for these features may be discontinued in a future
implementation of malloc(3C) and should not be used.
SEE ALSO
brk(2), errno(2).
STANDARDS CONFORMANCE
malloc(): AES, SVID2, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C
calloc(): AES, SVID2, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C
free(): AES, SVID2, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C
mallinfo(): SVID2, XPG2
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August
1992
malloc(3C)
malloc(3C)
mallopt(): SVID2, XPG2
realloc(): AES, SVID2, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C
Hewlett-Packard Company - 6 - HP-UX Release 9.0: August
1992
On 2003.08.01 14:19, Kirtikumar Deshpande wrote:
> It does not work as advertised, in AIX either... I played with this in
AIX
> 5L.
>
>
> - Kirti
>
>
> --- "Hately, Mike (LogicaCMG)" <[EMAIL PROTECTED]> wrote:
> > Stephen,
> >
> > The documentation is pretty wooly regarding this issue but the way it
seems
> > to be intended to work is this:
> > At startup Oracle will allocate an SGA sized as specified in the
> > sga_max_size parameter. This is to ensure that the system has enough
memory
> > accomodate what you see as a maximum requirement for the SGA.
> > After it's allocated this and started the database it should deallocate
any
> > memory it holds over and above that required to store the components of
the
> > SGA. In some platforms/versions this deallocation doesn't occur.
Solaris
> for
> > example behaves like this unless you move to version 8.
> > It's possible that your version of Tru64 has a similar limitation or
that
> > you're seeing a bug.
> > To my mind though, Oracle Support's claim that this is expected
behaviour
> is
> > a bit of a cop out. This is certainly not the way it was supposed to
work.
> > The concept guide states the following:
> >
> > "The SGA can grow in response to a database administrator statement, up
to
> > an operating system specified maximum and the SGA_MAX_SIZE
specification."
> >
> > and
> >
> > "Oracle can start instances underconfigured and allow the instance to
use
> > more memory by growing the SGA components, up to a maximum of
SGA_MAX_SIZE"
> >
> > Both of these statements imply that the unused memory is supposed to be
> > released back to the operating system.
> > The way that this feature operates on your system it allows you to
juggle
> > storage backwards and forwards between caches which is still useful but
not
> > 'what it says on the box'.
> >
> > I'd ask Oracle under what cirtcumstances this is normal behaviour. It's
not
> > the way the software is intended to work so maybe it's a platform
> > limitation.
> >
> > In order to give you a better idea of what Oracle thinks it's SGA is
using
> > you can query the following views :
> >
> > - V$SGA_CURRENT_RESIZE_OPS:
> > Information about SGA resize operations that are currently in
progress.
> > An operation can be a grow or a shrink of a dynamic SGA component.
> >
> > - V$SGA_RESIZE_OPS:
> > Information about the last 100 completed SGA resize operations.
> > This does not include any operations currently in progress.
> >
> > - V$SGA_DYNAMIC_COMPONENTS: Information about the dynamic components
in
> > SGA.
> > This view summarizes information based on all completed SGA resize
> > operations since startup.
> >
> > - V$SGA_DYNAMIC_FREE_MEMORY:
> > Information about the amount of SGA memory available for future
dynamic
> > SGA resize operations.
> >
> >
> > Hope this helps,
> > Mike Hately
> >
> >
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Kirtikumar Deshpande
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
**********************************************************************
This email contains information which is confidential. It is for the
exclusive use of the addressee. If you are not an addressee please
contact us immediately on 01737 275500. Please note that any
distribution, copying or use of this communication or its contents is
prohibited.
This footnote also confirms that this email message and all associated
attachments have been swept by Network Associates VirusScan for the
presence of computer viruses.
**********************************************************************
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
