After ASA server start in log is written follow data about cache size
I. 05/29 08:36:06. Running on Linux 2.6.21.5 #1 SMP Tue Jul 17
11:07:49 IDT 2007
I. 05/29 08:36:06. 917440K of memory used for caching
I. 05/29 08:36:06. Minimum cache size: 917440K, maximum cache size:
917440K
I. 05/29 08:36:06. Using a maximum page size of 4096 bytes

In the same time RAM size for applications is 3G (and 1G is for
kernal). Why cache size isn't 50% of RAM (according to start flag -c
50p)

Thanks for help, Hanan Brener

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote:

I looked into it and the "percentage" notation for cache size notation
is a percentage of
min( total_physical_ram, available_address_space ).

There isn't a way to determine the available address space on UNIX so we
use
available_address_space = total_usable_address_space-256MB.

For SA on 32-bit UNIX, total_usable_address_space is hard-wired to 2GB
which is probably something we should fix.

In your case, 50p is evaluated as 0.5*min(4GB,2GB-256MB) which is about
896MB so the number you are seeing is slightly higher than expected.

The cache will never exceed the maximum size so memory is clearly being
allocated OUTSIDE of the cache as I wrote in my original posting. We
need to find that leak. Do you have anything else going on in your
server that might leak memory? For example, an external stored procedure
that allocates memory but doesn't free it could do that. It's not likely
to be the SA ODBC driver or the remote table support but it's possible too.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Hanan Brener wrote: