VIOC overhead

[Wim Van den Wyngaert]

I tested the VIOC hit result rate while sybase is active. While sybase is reading database files, VIOC is tested (about 1000 reads per second) but the hit rate is almost zero.

If I do set file/cache=no for all the db files, this should improve performance of the IO. Anyone an idea of how much this could improve performance ? Note : VIOC, not EFC. And hit rate almost zero !!!

Wim

[Hein van den Heuvel]

Wim,

Why are you not using XFC ? It is SOOO much better!

Typically any DB, be that Sybase, Oracle or RDB, has a large memory cache, much bigger than the typical VIOC size. So if particalur data, is not in the DB cache, it is also not going to be in the IOC cache. There are some exceptions possible as the replacement algoritmes (LRU often) may not be exactly the same.
Furthermore, a typical DB has many (hundreds?) GBs of data, perhaps 20 - 50 times larger than the memory on the system and 100 - 1000 times larger than the VIOC cache. So even with a skewed distribution, what are the odds going to be to find a block in the memory cache?

Oracle decided it was not worth even trying, and they use the IO$M_NOCACHE (sp?) modifier telling the system not to stick the data in the cache if it is not there already/

Dunno about SYBASE. They probably did not implement that OpenVMS QIO feature. I agree with your suggestion to mark the DB files, or the drive holding the DB files as no cache.
It will not hurt (nor help ) the DB file QIOS, but it will remove pressure on the cache allowing other system component (process creations, batch jobs, images) to better use it.

How big are the Vioc cache, Db-buffer-area andTotal DB-files size on the system in question?

Hope this helps some,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting

[Wim Van den Wyngaert]

Hein,

Our system is frozen and EFC was not reliable when it was frozen. So VIOC was used.

In prod, the VIOC size is 62 MB. The db size is about 30 GB. The buffer area is 500 MB (too small but dba refuses to increase).

But what would be the gain of bypassing the cache ? 5% wall time ? 5% cpu time ?
I tried some tests with search/stat on a bunch of files but no clear result was obtained. The cpu time was changing to much.

Wim

[Daniel Gustafsson]

Hein, is IO$M_NOCACHE documented?

I can only find MNT$M_NOCACHE for $MOUNT

/Daniel

[Hoff]

You're on the box -- run some tests. (You're asking questions no one out here can answer with any certainty.)

If you're considering making a few little changes, then apply the current ECO kits and switch to XFC. (In for a penny, in for a pound. Might as well fix the biggest of the problems and re-run the regressions while you can.) Staying on old releases and skipping ECOs is not without its costs. And its risks.

That written, Sybase may well be going completely past VIOC (or XFC). It would not be the first database to be using logical I/O or to otherwise disable file system caching on its own files.

[Hein van den Heuvel]

Daniel,

$ pipe libr/extr=$iodef/out=sys$output sys$library:starlet.mlb | search sys$pipe cache
$EQU IO$M_NOVCACHE <^X20000>
$EQU IO$V_NOVCACHE 17

Wim,

If you do get to test then I would recommend a large, repeatable report taking 100io/sec for 10 minutes at least: 600,000 IOs. and more than 5 minutes cpu time to see whether the CPU time, and thus the total elapsed time reduces by more than a percent or two.

You might want to run an other regular file IO intensive job (SEARC [xxx]*.* if you have to) to see whether that IO intensive job gets better cachings and speeds up.

Hein.