Bug with max cache size adjustment in 8.0.3.x?

#21

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.

Quote:

Hi Bob,

On 1/26/2010 8:47 AM, 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 -

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...e.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/p...nywhere/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/p...nywhere/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
in the first:

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

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,

--
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...&client=ianywh...
Report a Bug/Open a Case :http://case-express.sybase.com/cx/

#22

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)?

Quote:

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

#23

-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

On 1/26/2010 4:38 PM, Bob Leviton wrote:

Quote:

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)?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Bug with max cache size adjustment in 8.0.3.x?

sybase.public.sqlanywhere.general sybase.public.sqlanywhere.general

Re: Bug with max cache size adjustment in 8.0.3.x? - 01-26-2010 , 03:11 PM

Re: Bug with max cache size adjustment in 8.0.3.x? - 01-26-2010 , 03:38 PM

Re: Bug with max cache size adjustment in 8.0.3.x? - 01-27-2010 , 10:22 AM