I am trying out some experimental file tuning on my test system (AREV 3.12) and I have a question regarding the framesize value recommended by verifylh.

The file I am currently tuning is the data portion of the lists file, which has an average row length of 13952.85. According to the table in Appendix 3-6 of the AREV reference the optimum framesize should be 6144, however if I remake the table using 6144 verifylh continues to recommend a value of 4096. Which value should I use?

Many thanks for any help.

Brian

Brian,

The ideal framesize is slightly larger than the average row length. Since your average row length exceeds 8192, then I would consider 1/2 the average row length. I would also consider using 1024, 2048, 4096, or 8192 only. So I would use 8192. Basically this is an opinion I have.

One more think I would like to say… consider purging the lists file of old records. The lists file should be for temporary saved select lists. And idealy, the programs that save the select lists should also delete the select lists. If you are intentionally trying to archive saved select lists, you might consider creating and using another file just for those wanted archived saved select lists.

Thanks for your help Richard.

That's an interesting point regarding clearing out the old stuff in lists. I think we will probably transfer the contents to a "just in case" backup table and clear it down periodically in future.

Brian

Hi, I have two recommendations.

SAVED QUERIES - set the number to keep to zero. I have found many systems where the users had no idea these were being automatically saved and weren't using them. Eliminating them speeds up their processing. And, they can become orphaned and never deleted. You can see their ids in the LISTS file with @STATION ids. Go ahead, delete them!

Leave all framesizes to 1024. (I'm surprised the Sprezzazes haven't already chimed in) A memory cache is maintained using the largest framesize of all tables being cached. So, it you have a mixture of 1024 and 6144 frame sizes, you use 6144 for all of those caches. In the DOS memory segment you may find you are running out of memory.

Dave

Just about to :)

Yes, we recommend keeping framesizes at 1024, especially for AREV. In later versions of OI, the bug that wasted IO after using larger frame sizes is reportedly fixed.

From what I understand about the bug, it's not that it runs out of memory, but thinks all frames are the same size as the largest, and cannot cache them properly, so it's constantly re-reading them.

If you really want to minimise the number of records in a group, lower the threshold value instead (any get a copy of the NLM or NT Service).

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks Dave & Sprezzatura.

I have saved queries already set to 0 on some previous advice (Victor Engel I think) in this forum. It is good advice, removing the overhead of clearing large queries has produced some benefit.

We use the Universal driver for network access, however I was surprised to see that the framesize/buffer cache bug is still appears to be around. I understood it to have been fixed in an earlier version of the NTService.

I also have some additonal concerns about the Universal Driver that have emerged due to discussions in this forum. It seems that if you create a new table while running the UD, extended header information is written (presumably to enable larger file sizes etc). There have been reports that this extended header is unreadable by verifylh and dumplh. Surely both of these essential utilities need to be updated to handle the extended header format. Currently I copy my files to my workstation, modify them without the UD and return then them to the server to get around this. I would be interested in any opinions from other AREV/UD users.

Best Regards

Brian

View this thread on the forum...