| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: 9i - Dynamic SGA - SGA_MAX_SIZE
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 physicalmemory (though some platforms do try to keep the SGA "pinned" in memory).
Phone: 01737 27 5564
Mladen Gogala
<mgogala_at_adelp To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
hia.net> cc:
Sent by: Subject: Re: 9i - Dynamic SGA - SGA_MAX_SIZE
ml-errors_at_fatc
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
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
int hblks; /* number of holding
blocks
int usmblks; /* space in small blocks
in
int fsmblks; /* space in free small
blocks */
int uordblks; /* space in ordinary
blocks
int fordblks; /* space in free
ordinary
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)" <mike.hately_at_nedl.co.uk> wrote: > > Stephen, > > > > The documentation is pretty wooly regarding this issue but the way itseems
> > 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 enoughmemory
> for > > example behaves like this unless you move to version 8. > > It's possible that your version of Tru64 has a similar limitation orthat
> > The concept guide states the following: > > > > "The SGA can grow in response to a database administrator statement, upto
> > > > and > > > > "Oracle can start instances underconfigured and allow the instance touse
> > > > 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 tojuggle
> > 'what it says on the box'. > > > > I'd ask Oracle under what cirtcumstances this is normal behaviour. It'snot
> > 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 isusing
> > you can query the following views : > > > > - V$SGA_CURRENT_RESIZE_OPS: > > Information about SGA resize operations that are currently inprogress.
> > 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 componentsin
> > 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 futuredynamic
> > 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: kirtikumar_deshpande_at_yahoo.com > > 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: ListGuru_at_fatcity.com (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: mgogala_at_adelphia.net 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: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Mon Aug 04 2003 - 05:04:23 CDT
(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: Stephen.HODGKINSON_at_eaguk.com 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: ListGuru_at_fatcity.com (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).
 |
 |