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,

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.


Bob Leviton wrote:

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)"
<khodgson (AT) A_SPAM_FREE_sybase (DOT) com> wrote:

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)

Bob Leviton wrote:

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 wrote:

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)"
<keating_nos... (AT) sybase (DOT) com> wrote:

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 wrote:

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

Hi Bob,

On 1/26/2010 8:47 AM, Bob Leviton wrote:
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/sybas...bacbf0445920b0

=====
"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/p...9/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/p...9/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
in the first:

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".

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,

--
Jeff Albion, Sybase iAnywhere

iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/

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


On 1/26/2010 2:24 PM, Bob Leviton wrote: