Has anybody found, used, and determined any or all of the commands for
getting the most throughput? I'm especially interested about machines
with disk caching controllers, but observations otherwise may be of
great help.

The help on the BUFFERS command explains what to watch out for that may
cause some slow performance. However, it really doesn't give much if
any information on what command should be used to improve performance
for each of the values.

I have found the command "BLKIO", which determines how many frames Pick
will get read into memory during disk accesses. I have yet to
experiment with this yet, and I am curious what values may be good for
systems with a hardware disk cache. Are there or can there be any
negative consequences by adjust the BLKIO value? Currently on the
systems that I deal with the BLKIO functionality is disabled and
therefore Pick will only read in one frame at a time. My thoughts here
are that if I have a lot of historical data that rarely/never gets
changed, I could expect a big performance increase if I set a file
size such that there are 5 frames per group and the BLKIO parameter is
set to 4. The initial read of the file would read the first 4 base
frames, and then would sweep in all the link frames for each group in
one read for each ground. This, of course, assuming that all the data
was freshly restored so that the linked frames themselves would be in
contiguous frames. It seems logical to me, but I could be wrong.

SET-OVF-LOCAL adjusts the PIBS local frame and file cache. Higher
values improve performance, but also increase the risk of file
corruption or lost data in the event of a power loss or system crash.

The help in D3.DOC for 'Top of Hash' states: "This number measures the
quality of the hashing algorithm used to find a frame in memory. This
number must be high (above 60% of the total buffers)." On one system,
this value generally stays close to 30%. I have not found a command to
help out with adjusting this value.

The 'Available Buffers' states: "These are the buffers that nobody has
been using recently. When this number drops below 10% of the total
buffers, performance decreases significantly. In my observation this
number starts at about 50% and slowly lowers over several days/weeks.
Then suddenly increases back to to 50% range.

These values above aren't the only values to be concerned about, so any
insight on these and other not stated here are encouraged.

Any help, observations, and anecdotal stories would be greatly
appreciated.

Regards,

Dale

dale_benedict (AT) flightcraft (DOT) ca wrote:
[snip]
You can fiddle with blkio; I used to set it to 64 as part of the
file-save job. However, there is (was) a bug on 7.4 -Red Hat systems
whereby changing blkio caused the system to crash. Since that time I
have kindof lost interest in playing with it.

However, nixxen based D3 (and AP before it) dropped the file separation
parameter, so you cannot set up your file for "5 frames per group". On
D3 nix, the separation is now always 1. I think separation still exists
on D3/NT as an option to set the frame size - up to 128K? Recent D3/nix
releases use 4K frames, I can't remember if 7.2 uses 2K or 4K frames.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Scott Ballinger wrote:
Interesting about the crashing! Do you remember if adjusting the
BLKIO increase throughput during your file saves?

I'm not talking about using the file separation here. I'm taking about
undersizing the file to 1/5th on purpose, and then doing a system
restore. During the restore the items for each frame will get moved
into disk space at the end of the base frames and the items for each
group normally would get put into contiguous frames. Therefore when
the system requests a single read the 4 frame of contiguous frames (all
the items in the llinked group outside of the base frames) would be
read in at one time. I think this method would work for historical
records that never get updated, but only reported on. There is going
to be a trade off somewhere. Set the number too high, and you probably
start the risk of the disk thrashing.

Regards,

Dale

dale_bened... (AT) flightcraft (DOT) ca wrote:
Not a lot; maybe 10-20% faster. But you get killed as your files
overflow and fragment; every time the system goes to get an over-flowed
frame you end up reading a huge chunk of disk, of which you really only
want 1 frame and all the rest are unlikely to be used, which totally
defeats the read-ahead concept. In the end, why bother? Kind of like a
current thread in the U2 group regarding large items in the VOC.
Computers these days are really really really fast and keep getting
faster. Humans are not fast and are not getting faster (I personally am
probably getting slower). The corollary is computers are cheap, I am
expensive. Tweaking files to avoid frame-faults (beyond proper file
sizing) is thus not a productive use of time, imo.

/Scott