Bug with max cache size adjustment in 8.0.3.x?

[Bob Leviton]

Just came across this and wondering if it's a known issue. ASA
8.0.3.5267 on Windows Server 2003 R2 32 bit. Machine has 4GB or more
RAM. Database service params include "-c 100M -ch3072M". On startup, a
message like the following is displayed: "Maximum cache size adjusted
to 1908124K 102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908124K". The
problem is that after this, no more than 100M RAM will ever be used by
dbserv8, and it may use less (i.e. 25M). It's as if the specified
minimum is used as the maximum, and something lower is being used as
the minimum. The result is a drastic reduction in performance.

[Kory Hodgson (Sybase iAnywhere)]

The appropriate parameter for specifying the lower limit of cache is -cl
not -c.

-c sets the initial cache size.

Post by Bob Leviton
Just came across this and wondering if it's a known issue. ASA
8.0.3.5267 on Windows Server 2003 R2 32 bit. Machine has 4GB or more
RAM. Database service params include "-c 100M -ch3072M". On startup, a
message like the following is displayed: "Maximum cache size adjusted
to 1908124K 102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908124K". The
problem is that after this, no more than 100M RAM will ever be used by
dbserv8, and it may use less (i.e. 25M). It's as if the specified
minimum is used as the maximum, and something lower is being used as
the minimum. The result is a drastic reduction in performance.

[Bob Leviton]

OK, but what about the max apparently not getting applied correctly?

On Jan 25, 11:26 am, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
The appropriate parameter for specifying the lower limit of cache is -cl
not -c.
-c sets the initial cache size.

[Kory Hodgson (Sybase iAnywhere)]

32-bit operating systems are limited to 2GB of address space, so the max
cache you could allocate would be a bit less than this.

Please see:
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_limits

Post by Bob Leviton
OK, but what about the max apparently not getting applied correctly?
On Jan 25, 11:26 am, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
The appropriate parameter for specifying the lower limit of cache is -cl
not -c.
-c sets the initial cache size.

[Bob Leviton]

OK, but the fact remains that after ASA said it was adjusting the max
cache down to 1900M, it actually limited the cache to 100M, which I
proved through repeated testing. That is the bug I'm referring to.


On Jan 25, 12:11 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
32-bit operating systems are limited to 2GB of address space, so the max
cache you could allocate would be a bit less than this.
Please see:http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_l...

[Kory Hodgson (Sybase iAnywhere)]

"Maximum cache size adjusted to 1908124K 102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908124K"

This says the max cache is about 1.9 GB and that 100MB is being used.
Max does not mean it will be used, just that it can be used is required.
The -c initial cache setting set the initial cache to 100MB as indicated
by the output you provided.

Post by Bob Leviton
OK, but the fact remains that after ASA said it was adjusting the max
cache down to 1900M, it actually limited the cache to 100M, which I
proved through repeated testing. That is the bug I'm referring to.
On Jan 25, 12:11 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
32-bit operating systems are limited to 2GB of address space, so the max
cache you could allocate would be a bit less than this.
Please see:http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_l...

[Chris Keating (Sybase iAnywhere)]

How are you measuring the cache size? You can use -cs to monitor the
cache sizing on the engine console.

Note that there is a limit to available cache on Windows 32 bit
processes. To gain access to max size for an OS, you will need to start
the OS with the /3GB option.

Post by Bob Leviton
OK, but the fact remains that after ASA said it was adjusting the max
cache down to 1900M, it actually limited the cache to 100M, which I
proved through repeated testing. That is the bug I'm referring to.
On Jan 25, 12:11 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
32-bit operating systems are limited to 2GB of address space, so the max
cache you could allocate would be a bit less than this.
Please see:http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_l...

[R. Pods]

You might want to look for the memory limits in the documentation:
dbsrv8.exe -> command line -> -cw

AFAIK the upper limit of the cache for a 32 bit server process will be
around 1800 M.

HTH
Reimer

Post by Bob Leviton
OK, but what about the max apparently not getting applied correctly?
On Jan 25, 11:26 am, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
The appropriate parameter for specifying the lower limit of cache is -cl
not -c.
-c sets the initial cache size.

["Nick Elson [Sybase iAnywhere]" <@@@@com@>]

This sound like this may be more an issue of how memory
usage is being measured.

If you are just looking at standard memory column shown in Windows
Task Manager, that is not the address space being used. It is
just the 'working set' in physical memory. Unless we are talking
about pinned memory (or even AWE) almost all memory is virtual
on Windows and the operating system is free to swap out as
much as it see's fit.

The default columns Task manager displays, do not report the total
amount of memory assigned to the application. Adding in the additional
memory columns or using the performance monitor should tell you
better what memory is assigned.

Of course, if the operating system has the database server mostly
swapped out, that would indicate one of two different scenarios
are at play. One is the whole machine is overloaded with other
tasks (in addition to just the database server). The other is the
database server may not be all that busy or demanding.


HTH

Post by Bob Leviton
Just came across this and wondering if it's a known issue. ASA
8.0.3.5267 on Windows Server 2003 R2 32 bit. Machine has 4GB or more
RAM. Database service params include "-c 100M -ch3072M". On startup, a
message like the following is displayed: "Maximum cache size adjusted
to 1908124K 102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908124K". The
problem is that after this, no more than 100M RAM will ever be used by
dbserv8, and it may use less (i.e. 25M). It's as if the specified
minimum is used as the maximum, and something lower is being used as
the minimum. The result is a drastic reduction in performance.

[Bob Leviton]

Chris & Nick, yes I was looking at "mem usage", "peak mem usage", and
"VM size" in Task Manager. Thanks for the tip about the -cs option. I
see the same figures when I use it as I saw in Task Manager.

Here's the -cs output when I have -ch set low enough that ASA will not
adjust it (-c 100M -ch 1024M) and do my test to load up the cache:
-------------------------------------------------------------------------------------------------------
Sybase Adaptive Server Anywhere Network Server Version 8.0.3.5267
...
Running on Windows XP Build 2600 Service Pack 3
102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1048576K
...
OS Available: 2059492K, Working Set: 110244K, Cache Target: 812032K
Cache size adjusted to 812032K
-------------------------------------------------------------------------------------------------------

Now here's what I get when I set -ch too high (-c 100M -ch 2048M) and
perform the same test:
-------------------------------------------------------------------------------------------------------
Sybase Adaptive Server Anywhere Network Server Version 8.0.3.5267
...
Running on Windows XP Build 2600 Service Pack 3
Maximum cache size adjusted to 1908112K
102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908112K
...
OS Available: 2128484K, Working Set: 110604K, Cache Target: 1456684K
OS Available: 2124828K, Working Set: 110644K, Cache Target: 1456684K
OS Available: 2058288K, Working Set: 110644K, Cache Target: 1456684K
-------------------------------------------------------------------------------------------------------

The above results can be reproduced consistently.


On Jan 25, 1:23 pm, "Nick Elson [Sybase iAnywhere]"

Post by "Nick Elson [Sybase iAnywhere]" <@@@@com@>
This sound like this may be more an issue of how memory
usage is being measured.
If you are just looking at standard memory column shown in Windows
Task Manager, that is not the address space being used.  It is
just the 'working set' in physical memory.  Unless we are talking
about pinned memory (or even AWE) almost all memory is virtual
on Windows and the operating system is free to swap out as
much as it see's fit.
The default columns Task manager displays, do not report the total
amount of memory assigned to the application.  Adding in the additional
memory columns or using the performance monitor should tell you
better what memory is assigned.
Of course, if the operating system has the database server mostly
swapped out, that would indicate one of two different scenarios
are at play.  One is the whole machine is overloaded with other
tasks (in addition to just the database server).  The other is the
database server may not be all that busy or demanding.
HTH

[Bob Leviton]

To summarize, what I think I'm hearing is: don't set your max cache
too high, else ASA will adjust it for you then may fail to be able to
allocate it. Which was my initial recommendation as well. Thanks for
the replies.

[Kory Hodgson (Sybase iAnywhere)]

Bob,

The max cache doesn't say to allocate that amount of cache, it is simply
setting an upper bounds of which not to exceed. If you want to start
with more cache specify a higher value with the -c parameter. If you
want to ensure we don't lower it specify a higher minimum value -cl.

Post by Bob Leviton
To summarize, what I think I'm hearing is: don't set your max cache
too high, else ASA will adjust it for you then may fail to be able to
allocate it. Which was my initial recommendation as well. Thanks for
the replies.

[Bob Leviton]

OK, so the recommendation is to not specify a max cache size, just a
minimum and/or initial size, and let ASA manage the rest? Give what
I've found in my example, I'm not sure I'd trust ASA 8 to do that...

On Jan 25, 2:49 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
Bob,
The max cache doesn't say to allocate that amount of cache, it is simply
setting an upper bounds of which not to exceed. If you want to start
with more cache specify a higher value with the -c parameter. If you
want to ensure we don't lower it specify a higher minimum value -cl.

Post by Bob Leviton
To summarize, what I think I'm hearing is: don't set your max cache
too high, else ASA will adjust it for you then may fail to be able to
allocate it. Which was my initial recommendation as well. Thanks for
the replies.- Hide quoted text -

- Show quoted text -

[Kory Hodgson (Sybase iAnywhere)]

So if you don't trust ASA 8 (very old software btw and end of life) all
you have to do is decide what cache you want and set the -cl and -ch to
that value. That way if the minimum and maximum cache sizes are equal
the server will not be able to pick a different value (as long as it is
a valid value for your system)

Post by Bob Leviton
OK, so the recommendation is to not specify a max cache size, just a
minimum and/or initial size, and let ASA manage the rest? Give what
I've found in my example, I'm not sure I'd trust ASA 8 to do that...
On Jan 25, 2:49 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
Bob,
The max cache doesn't say to allocate that amount of cache, it is simply
setting an upper bounds of which not to exceed. If you want to start
with more cache specify a higher value with the -c parameter. If you
want to ensure we don't lower it specify a higher minimum value -cl.

Post by Bob Leviton
To summarize, what I think I'm hearing is: don't set your max cache
too high, else ASA will adjust it for you then may fail to be able to
allocate it. Which was my initial recommendation as well. Thanks for
the replies.- Hide quoted text -

- Show quoted text -

[Chris Keating (Sybase iAnywhere)]

You claim this is not working. Can you verify how you determine that the
cache is not being adjusted? You can monitor cache using -ca at the
engine console or by 'CacheSize' and 'PeakCache' engine properties.
There may be other reasons why performance is not optimal.

-chris

Post by Bob Leviton
OK, so the recommendation is to not specify a max cache size, just a
minimum and/or initial size, and let ASA manage the rest? Give what
I've found in my example, I'm not sure I'd trust ASA 8 to do that...
On Jan 25, 2:49 pm, "Kory Hodgson (Sybase iAnywhere)"

Post by Kory Hodgson (Sybase iAnywhere)
Bob,
The max cache doesn't say to allocate that amount of cache, it is simply
setting an upper bounds of which not to exceed. If you want to start
with more cache specify a higher value with the -c parameter. If you
want to ensure we don't lower it specify a higher minimum value -cl.

Post by Bob Leviton
To summarize, what I think I'm hearing is: don't set your max cache
too high, else ASA will adjust it for you then may fail to be able to
allocate it. Which was my initial recommendation as well. Thanks for
the replies.- Hide quoted text -

- Show quoted text -

[Bob Leviton]

Chris, refer to my post from yesterday with -cs output. My test was to
do a query that will always load up the cache when I have set -ch to
an allowable value. When I set it too high, so that ASA adjusts max
cache to a lower value, the results when the same query is run
indicate that ASA is trying to increase the cache but is failing. This
failure has been seen on an operational customer system - that was the
original issue that led me to this discovery - customer complained of
sudden dismal performance after installing on a new server machine,
and on inspection I noticed unusually low memory use by dbsrv8 and
that ASA had adjusted the max on startup.

Bob

On Jan 25, 8:20 pm, "Chris Keating (Sybase iAnywhere)"

Post by Chris Keating (Sybase iAnywhere)
You claim this is not working. Can you verify how you determine that the
cache is not being adjusted? You can monitor cache using -ca at the
engine console or by 'CacheSize' and 'PeakCache' engine properties.
There may be other reasons why performance is not optimal.
-chris

[Chris Keating (Sybase iAnywhere)]

My bad, I missed that post yesterday.

If this is a bug, there are no engineering fixes being made to 8.0.3 (as
it is End of Lifed). You are running a fairly old build. Since this is
reproduceable, you might want to consider testing this with the last EBF
for 8.0.3.

-chris

Post by Bob Leviton
Chris, refer to my post from yesterday with -cs output. My test was to
do a query that will always load up the cache when I have set -ch to
an allowable value. When I set it too high, so that ASA adjusts max
cache to a lower value, the results when the same query is run
indicate that ASA is trying to increase the cache but is failing. This
failure has been seen on an operational customer system - that was the
original issue that led me to this discovery - customer complained of
sudden dismal performance after installing on a new server machine,
and on inspection I noticed unusually low memory use by dbsrv8 and
that ASA had adjusted the max on startup.
Bob
On Jan 25, 8:20 pm, "Chris Keating (Sybase iAnywhere)"

Post by Chris Keating (Sybase iAnywhere)
You claim this is not working. Can you verify how you determine that the
cache is not being adjusted? You can monitor cache using -ca at the
engine console or by 'CacheSize' and 'PeakCache' engine properties.
There may be other reasons why performance is not optimal.
-chris

[Bob Leviton]

Actually I had tried under the last EBF (8.0.3.5594) yesterday, but
double-checked today and confirmed that this behavior is unchanged.

Post by Chris Keating (Sybase iAnywhere)
My bad, I missed that post yesterday.
If this is a bug, there are no engineering fixes being made to 8.0.3 (as
it is End of Lifed). You are running a fairly old build. Since this is
reproduceable, you might want to consider testing this with the last EBF
for 8.0.3.
-chris

[Jeff Albion [Sybase iAnywhere]]

Hi Bob,

Post by Bob Leviton
Chris, refer to my post from yesterday with -cs output. My test was to
do a query that will always load up the cache when I have set -ch to
an allowable value. When I set it too high, so that ASA adjusts max
cache to a lower value, the results when the same query is run
indicate that ASA is trying to increase the cache but is failing. This
failure has been seen on an operational customer system - that was the
original issue that led me to this discovery -

I don't believe there is a bug here - perhaps just an interpretation
issue that needs to be clarified.

=====================
Now here's what I get when I set -ch too high (-c 100M -ch 2048M) and
perform the same test:


Sybase Adaptive Server Anywhere Network Server Version 8.0.3.5267
...
Running on Windows XP Build 2600 Service Pack 3
Maximum cache size adjusted to 1908112K
102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908112K
...
OS Available: 2128484K, Working Set: 110604K, Cache Target: 1456684K
OS Available: 2124828K, Working Set: 110644K, Cache Target: 1456684K
OS Available: 2058288K, Working Set: 110644K, Cache Target: 1456684K
=====================

You may be interpreting the metric "Cache Target" in this output
incorrectly. John Smirnios posted the following information back in Nov.
2004 on how to interpret the -cs memory numbers:

http://groups.google.com/group/sybase.public.sqlanywhere.general/msg/a0bacbf0445920b0

=====
"Cache Target: The size of the cache we have determined would like to
have. Generally, it is (OS_Available + Working_Set - Amount_left_for_OS)
but limited by max cache size, min cache size, and the sum of the sizes
of open db files."
=====

The actual important metrics for cache usage during query execution
inside the engine are really server properties that can be queried in
the database itself, at runtime: (
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbdaen9/00000786.htm
). You'll want to look at properties like "CacheHitsEng",
"CurrentCacheSize", "PeakCacheSize" and similar metrics to get a better
picture of how the server is using cache memory. You can also use the
Windows Performance monitor (
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbdaen9/00000783.htm
) to see these metrics in real-time.

---

We will dynamically load database pages into the cache as required to
satisfy database requests. The fact that your second test does not
require an "auto-size" of the cache indicates that your test isn't using
all of the initial cache space available in the second condition, but is

Post by Bob Leviton

Post by Bob Leviton
Cache size adjusted to 812032K

We auto-size the cache by default and this message in the console
indicates that we have just performed that operation. Your second test
should also start issuing these types of messages to the console as well
once you have consumed the initial cache size and need to start
expanding up the maximum cache size. You can always turn off the auto
cache-sizing behaviour by using "-ca 0".

Post by Bob Leviton
customer complained of
sudden dismal performance after installing on a new server machine,
and on inspection I noticed unusually low memory use by dbsrv8 and
that ASA had adjusted the max on startup.

Your second case actually has a higher maximum than your first case to
"auto-size" the cache up to:

=====
(-ch 1024M)
maximum cache size: 1048576K

(-ch 2048M)
maximum cache size: 1908112K
=====

and note that they both start out with the same initial cache size:

=====
(-ch 1024M)
102400K of memory used for caching

(-ch 2048M)
102400K of memory used for caching
=====

Thus, I wouldn't expect that the performance problem is related to only
the cache switches in this case. Your second case should theoretically
"run faster in a full cache scenario" since it can auto-size the cache
up to the full 1908112K, rather than 1048576K.

Regards,

[Bob Leviton]

Jeff, thanks for your input. However I've already determined to my own
satisfaction that there is a problem when ASA adjusts the max cache
size, and am preparing a service bulletin for our customers on how to
properly configure caching, as other posters have suggested, and thus
ensure this problem doesn't recur in the field.

Post by Jeff Albion [Sybase iAnywhere]
Hi Bob,

Post by Bob Leviton
Chris, refer to my post from yesterday with -cs output. My test was to
do a query that will always load up the cache when I have set -ch to
an allowable value. When I set it too high, so that ASA adjusts max
cache to a lower value, the results when the same query is run
indicate that ASA is trying to increase the cache but is failing. This
failure has been seen on an operational customer system - that was the
original issue that led me to this discovery -

I don't believe there is a bug here - perhaps just an interpretation
issue that needs to be clarified.
=====================  
Now here's what I get when I set -ch too high (-c 100M -ch 2048M) and
Sybase Adaptive Server Anywhere Network Server Version 8.0.3.5267
...
Running on Windows XP Build 2600 Service Pack 3
Maximum cache size adjusted to 1908112K
102400K of memory used for caching
Minimum cache size: 102400K, maximum cache size: 1908112K
...
OS Available: 2128484K, Working Set: 110604K, Cache Target: 1456684K
OS Available: 2124828K, Working Set: 110644K, Cache Target: 1456684K
OS Available: 2058288K, Working Set: 110644K, Cache Target: 1456684K
=====================
You may be interpreting the metric "Cache Target" in this output
incorrectly. John Smirnios posted the following information back in Nov.
http://groups.google.com/group/sybase.public.sqlanywhere.general/msg/...
=====
"Cache Target: The size of the cache we have determined would like to
have. Generally, it is (OS_Available + Working_Set - Amount_left_for_OS)
but limited by max cache size, min cache size, and the sum of the sizes
of open db files."
=====
The actual important metrics for cache usage during query execution
inside the engine are really server properties that can be queried in
the database itself, at runtime: (http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/e...
). You'll want to look at properties like "CacheHitsEng",
"CurrentCacheSize", "PeakCacheSize" and similar metrics to get a better
picture of how the server is using cache memory. You can also use the
Windows Performance monitor (http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/e...
) to see these metrics in real-time.
---
We will dynamically load database pages into the cache as required to
satisfy database requests. The fact that your second test does not
require an "auto-size" of the cache indicates that your test isn't using
all of the initial cache space available in the second condition, but is
 >> Cache size adjusted to 812032K
We auto-size the cache by default and this message in the console
indicates that we have just performed that operation. Your second test
should also start issuing these types of messages to the console as well
once you have consumed the initial cache size and need to start
expanding up the maximum cache size. You can always turn off the auto
cache-sizing behaviour by using "-ca 0".

Post by Bob Leviton
customer complained of
sudden dismal performance after installing on a new server machine,
and on inspection I noticed unusually low memory use by dbsrv8 and
that ASA had adjusted the max on startup.

Your second case actually has a higher maximum than your first case to
=====
(-ch 1024M)
maximum cache size: 1048576K
(-ch 2048M)
maximum cache size: 1908112K
=====
=====
(-ch 1024M)
102400K of memory used for caching
(-ch 2048M)
102400K of memory used for caching
=====
Thus, I wouldn't expect that the performance problem is related to only
the cache switches in this case. Your second case should theoretically
"run faster in a full cache scenario" since it can auto-size the cache
up to the full 1908112K, rather than 1048576K.
Regards,
--
Jeff Albion, Sybase iAnywhere
iAnywhere Developer Community :http://www.sybase.com/developer/library/sql-anywhere-techcorner
iAnywhere Documentation :http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :http://downloads.sybase.com/swd/summary.do?baseprod=144&client=ianywh...
Report a Bug/Open a Case :http://case-express.sybase.com/cx/

[John Smirnios [Sybase]]

When the specified max cache size is larger then the available address
space, SA does try to allocate as much address space as possible. In
allocating 1.9GB of address space, there is virtually nothing left for
any other purpose.

Looking at the output you posted where the cache stats are shown but the
cache does not grow, I'd say it is likely that the attempt to grow the
cache is failing either due to lack of backing store or, more likely,
address space. Do you have sufficient backing store? Does the same
failure to grow occur if you set your max cache size just a little
smaller with, say, -ch 1800m?

Upgrading to a newer version will not likely change the behaviour you
are seeing because the same algorithm still exists for choosing the max
cache size when a value that is too large is specified on the command line.

We will need to consider changing the '-ch' semantics so that the engine
always leaves some reasonable amount of address space unused.
Currently, -ch will allow users to squeeze as much memory into the cache
as they "dare" given that running out of address space can lead to
failures and instability.

The correct action to take here is to reduce the max cache size to
something to something such as 1600m or 1700m to leave address space for
other server functions. Meanwhile, we'll look into automating that
choice for you :)

-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

Post by Bob Leviton
Actually I had tried under the last EBF (8.0.3.5594) yesterday, but
double-checked today and confirmed that this behavior is unchanged.

Post by Chris Keating (Sybase iAnywhere)
My bad, I missed that post yesterday.
If this is a bug, there are no engineering fixes being made to 8.0.3 (as
it is End of Lifed). You are running a fairly old build. Since this is
reproduceable, you might want to consider testing this with the last EBF
for 8.0.3.
-chris

[Bob Leviton]

Thanks John, you nailed it. When I set -ch to almost as high as the
auto-adjust value (1850M), I see the same failure. I'm planning to
recommend no higher than 1536M on customer systems (assuming there is
at least 2GB RAM).

What about the -cw option for systems with more than 2GB RAM (haven't
tried it as it requires some OS level adjustments that I may not have
access to)?

Post by John Smirnios [Sybase]
When the specified max cache size is larger then the available address
space, SA does try to allocate as much address space as possible. In
allocating 1.9GB of address space, there is virtually nothing left for
any other purpose.
Looking at the output you posted where the cache stats are shown but the
cache does not grow, I'd say it is likely that the attempt to grow the
cache is failing either due to lack of backing store or, more likely,
address space. Do you have sufficient backing store? Does the same
failure to grow occur if you set your max cache size just a little
smaller with, say, -ch 1800m?
Upgrading to a newer version will not likely change the behaviour you
are seeing because the same algorithm still exists for choosing the max
cache size when a value that is too large is specified on the command line.
We will need to consider changing the '-ch' semantics so that the engine
always leaves some reasonable amount of address space unused.
Currently, -ch will allow users to squeeze as much memory into the cache
as they "dare" given that running out of address space can lead to
failures and instability.
The correct action to take here is to reduce the max cache size to
something to something such as 1600m or 1700m to leave address space for
other server functions. Meanwhile, we'll look into automating that
choice for you :)
-john.
--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

[John Smirnios [Sybase]]

-cw is a completely different beast. With -cw, there is no dynamic cache
sizing and the memory used by the cache is locked into RAM: it cannot be
swapped out by the OS if some other application needs it. Generally, I'd
say that -cw is intended for large, dedicated 32-bit systems. "Large
32-bit system" is a bit of an oxymoron these days and I suspect they are
disappearing rapidly. If you want a large server and have any control
over the system, I recommend switching to a 64-bit OS and database
server. Many home PCs are even shipping with 64-bit OSs on them so it's
definitely mainstream. 64-bit systems make all this
address-space-limitation nonsense just go away.

If you are stuck with 32-bit for now and you have machines with 3GB or
4GB RAM, check if the OS supports the /3GB option in boot.ini (or
whatever the Visa equivalent is -- I forget offhand). That will give you
another 1GB to play with. If you are stuck with a 32-bit system with
much more RAM than 4GB, use -cw but be very careful not to leave the
other things in your system with no memory to play with.

Also note that AWE caches (-cw) will be documented as deprecated in 12.0
(though it is still fully functional -- it's just a documentation
change). We may remove AWE (and thereby the complexities it adds to the
cache manager) in future versions of SA when 64-bit OS's will be by far
the norm.

-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

Post by Bob Leviton
Thanks John, you nailed it. When I set -ch to almost as high as the
auto-adjust value (1850M), I see the same failure. I'm planning to
recommend no higher than 1536M on customer systems (assuming there is
at least 2GB RAM).
What about the -cw option for systems with more than 2GB RAM (haven't
tried it as it requires some OS level adjustments that I may not have
access to)?