'Dir Data' - File System Caching Headache!

[Volker Halle]

Edmundo,

when looking at the T4 data you've posted to the other thread, I only see high Dir Data attempts between 22:58 and 23:05 on both days (19 and 20-MAY-2014). Has this changed now ? Could you post current T4 data ?

Did you try to look for big directories on your most busy disks ? Use $ DIR/SIZ/SEL=SIZ=MIN=1000 disk:[*...]*.DIR

Volker.

[Hein van den Heuvel]

>> The bottom line conclusion of your exposition is a little bit difficult to be applied to my problem.

Hmm, ok. I think it applies perfectly.

>> due to a couple of facts exposed in my previous post (sorry you may have to read it)

I remember that now. Actually found the T4 files on my system when I tried to re-download.

There are a few scheduled jobs (every 15 minutes early day, and ever 10 minutes peak business) that seem to stress the file system some. They are probably polling a directory over and over.

This can possibly be improved with a directory AST ... if there is a need to improve them

>> You see, main thing is that this system type of application environment, quiet depends on a big memory reservation >> were most of the Caché db instance (similar MUMPS), use it righ from the system startup, were all the db caching is >> done (all 83 db namespaces/globals has the following 'Caching attribute' enabled: No_caching - at the file level)

>> This is NOT a 'piss-poor application design effect, there is no 'BS' here.

Exactly my point. In a well writen application like that you can NOT expect the (file) system  to help.

Low cache rates are just an indication this plan is working, you should not expect, nor want to try to fix that.

 >> The only main problem generated through time that I found is disk-volumes fragmentation; were there is alot writing apart from the db writing, which actually is affected by multiple expansion caused by the big dynamic activity of users, which eventually need compaction.

Hmmm, doesn't look too bad to me.

>> Sorry, but what I perceive is that... 

>> 'High XFC cache rates "DOES-NOT" point to a stupid application which reads the same data over and over'

Well, it does, but his application, according to the T4 data is not one those.

>> May be I don't explain myself good enough for OpenVMS gurus!

You are explaining yourself fine, but you are not listening to your own explanation.

The system appears to be working fine... from a VMS perspective.

Lots of USER mode time, no lock contention, and so on, so there is little or nothing to tune form the SYSTEM perspective.

Any and all improvements will have to come from the DB (Cache) and its users.

What you have not explained fine, or maybe I missed it is why you are looking at the numbers you are looking at.

Those are just numbers, number may be an indication things can be improved, or just represent work being done.

What are the main complaints?

What are the troubling times... the morning and afternoon camel humps from 8:30 - 17:30 when the users come in?  That (backup) batch job that really kicks in 20:40 - 22:40 (batch-dirio, shad-dirio, xfc cache-bypass-read  ... and more all peak.))

Good luck.

Hein