Hi!
I think sbrk() (which calls brk()) can be executed with negative value to
reduce total heap size for a process?
Anyway, on windows, SGA_MAX_SIZE didn't affect allocation of virtual memory,
my SGA was 200M and max_size was set to 512M, still only 200M was allocated
at startup.
Tanel.
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Sunday, August 03, 2003 7:19 AM
> 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).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Tanel Poder
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).
