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)" <mike.hately_at_nedl.co.uk> 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: 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-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).
Received on Sat Aug 02 2003 - 23:19:23 CDT
