Re: VIOC: sizing and performance

On Nov 14, 11:46 pm, Ken Fairfield <K...@xxxxxxxxxxxxxxxxxxxxx> wrote:
We have a four-node VMSCluster consisting of two GS1280 "frames",
each partitioned into two nodes. For reasons best known to the
vendor of the primary application, Cerner Millennium, we're using
VIOC rather than XFC file caching. The cluster is not homogeneous
in that one node is dedicated to "non-production" versions of the
application, one node is the production database server, and two
nodes share the production "application server" duties (tier 2 in
a 3-tier architecture).

That said, the vendor is asking us to set VCC_MAXSIZE <= 256000,
whereas we have it set to 512000 on two nodes, and 768000 on a
third.

Looking at SHOW MEMORY/CACHE/FULL on the three production nodes,
I see Read Hit Rates of 58% (database node, 512000 maxsize),
15% on app server node w/512000 maxsize, and 66% on the other app
server node w/768000 maxsize (the non-prod node is at 256000 and
has a hit rate of 71%).

Question: What is the best, or at least a good, indicator of
VIOC effectiveness? Is it the read hit rate, or something else?
Secondly, what would one expect the effect would be of *reducing*
VCC_MAXSIZE by 50%, or even 75% in the one case?

I'm concerned that the vendor is making these recommendations
without taking into consideration the actual potential performance
impacts. Their comment reads like so:

"Sets size for closed file cache. 256,000 is the start value.
This should be tuned down later after full load conditions
are studied."

I.e., this seems like a new-installation setting, not one based on
actual running history of over 2 years. And note that every change
takes a downtime for Autogen then reboot <sigh...>.

Thanks for any and all hints, tips, and/or personal stories. ;-)

-Ken
--
Ken & Ann Fairfield
What: Ken dot And dot Ann
Where: Gmail dot Com

Ken,

Caches of all types are an excellent candidate for the "Your mileage
will vary". Even in precisely the same application context, the hit
rate is, in essence, a direct manifestation of how the applications
interact with the people who use them. Thus, I have always considered
recommendations as a starting point, with the actual numbers to be
increased or decreased as experience with the operating environment.

While the original post did not include details of the disk
configuration, it is likely that there are (at least) three levels of
caching actually present: within the database, the VIOC/XFC, and the
caching within the storage controller. The optimum performance
settings are a balancing act between all three and their effects.

CPU caches have multiple levels because of size limits inherent to
geometry and packaging, thus they typically have small L1 caches,
backed by ever increasing L2 and, in some cases, L3 caches. This
relationship does not apply in the case of mass storage.

My general recommendation over the years, always tempered by the
actual situation, is to adjust the internal database caches to
maximize performance, and then, to the extent possible, exclude the
database activity from consideration for caching. If a properly tuned
database is releasing data back to mass storage it is probably making
an intelligent choice, particularly if the database cache is tuned
correctly.

As to the hit rate, the effect of a reduction in cache size depends
where on the curve one is at the present value. The general curve for
cache performance is a curve approximating exponential decay of
benefits as size increases. The true metric here is not really hit
rate, but eviction rate: How often data must be evicted from the cache
to make room for other data. A hit rate of 50% with an eviction rate
of 0% is far different than a hit rate of 50% with a 100% eviction
rate (the latter gains by adding size, the former does not).

I would be tempted to arrange things so that the cache is not polluted
by the presence of the data back and forth from the database and
Cache. I would also consider the use of RMS tuning on other active
files as an alternative to the sledgehammer of using the cache size.
Cache size (either XFC or VIOC) is a large, somewhat imprecise tool
for achieving performance. While I will not say that one cannot wield
a sledgehammer with precision, it can be challenge.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com
.

Relevant Pages

  • Re: Datasets fundamental
    ... loading from the Database into this "cache" and you want to update on a ... another option is using SQL 2005 Express and having it ... You then move from a custom "cache" solution to a normal replication type of ... engine is better at caching than you. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Using DataSet and remoting to implement distributed cache--pattern
    ... overhead and complexity in order to provide caching. ... > maintain a static cache--a larger DataSet of the same type as the DTO. ... > record which is retrieved from the database to fill a business object ... I want this cache to be able to scale accross ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Website Running Slow Please Help.
    ... Caching is a very common way to improve performance, ... generally it's better to expire items from the cache manually ... application that write data to the database should know what items are ... underlying data changes without as much work from the developer. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Caching objects
    ... alivate this via caching I was hoping do somthing like this. ... public Product(string productName, string newConnString, Cache ... I suppose I could just cache the database results in the iniProduct ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: LDAP Performance (long)
    ... Cache the slapd's internal database lookups in slapd memory. ... The first is the new TAG:key lookup, ...
    (comp.mail.sendmail)
Quantcast