INFORMATION ABOUT ACP SYSGEN PARAMETERS

[Ana M. García Olivencia]

Hi all.

We are working with OpenVMS 8.4 in a HP BL870C. We are having sporadic but painful I/O problems and, according to the Performance Tuning manual and as we have plenty of free memory, we have considered to modify the ACP SYSGEN parameters in order to increase the hit percentage of some caches.

We have tested different values online and we have realized that, although there is no fixed maximum limit for most of these parameters, when changing values. there are upper limits for some of them. We executed AUTOGEN, changed PAGEDYN  parameter, as suggested by AUTOGEN, and rebooted, but the result is the same. Look at ACP_HDRCACHE, ACP_DINDXCACHE, ACP_FIDCACHE and ACP_EXTCACHE parameters values after reboot:

$ sear sys$system:setparams.dat "acp_"
set ACP_MULTIPLE 0
set ACP_MAPCACHE 20360
set ACP_HDRCACHE 89920
set ACP_DIRCACHE 16288
set ACP_DINDXCACHE 20360
set ACP_FIDCACHE 81920
set ACP_EXTCACHE 81920
set ACP_QUOCACHE 652
set ACP_SYSACC 29
set ACP_SWAPFLGS 14

$mc sysgen

sysgen> show /acp

Parameter Name            Current    Default     Min.       Max.   Unit  Dynamic
--------------            -------    -------   -------    -------  ----  -------
ACP_XQP_RES                     1          1         0          1 Boolean    
ACP_REBLDSYSD                   1          1         0          1 Boolean    
ACP_MULTIPLE                    0          0         0          1 Boolean    D
ACP_SHARE                       1          1         0          1 Boolean    
ACP_MAPCACHE                20360          9         2         -1 Blocks     D
ACP_HDRCACHE                24384         36         8         -1 Blocks     D
ACP_DIRCACHE                16288         22         4         -1 Blocks     D
ACP_DINDXCACHE              20360         26         2         -1 Blocks     D
ACP_WORKSET                     0          0         0         -1 Pagelets   D
ACP_FIDCACHE                16384         64         0         -1 File-Ids   D
ACP_EXTCACHE                16384         64         0         -1 Extents    D
ACP_EXTLIMIT                  100        100         0       1000 Percent/10 D
ACP_QUOCACHE                  652         64         0       2337 Users      D
ACP_SYSACC                     29          8         0         -1 Directorie D
ACP_MAXREAD                    32         32         1         64 Blocks     D
ACP_WINDOW                      7          7         1         -1 Pointers   D
ACP_WRITEBACK                   1          1         0          1 Boolean    D
ACP_DATACHECK                   2          2         0         99 Bitmask    D
ACP_BASEPRIO                    8          8         4         31 Priority   D
ACP_SWAPFLGS                   14         15         0         15 Bitmask    D

Are we doing anything wrong?.  Why is the reason it's not possible to raise those four parameters?. The AUTOGEN report doesn't say anything about a problem; in fact, it seems to admit those higher values but, when booting, they don't appear.

Any help will be very appreciated.

Thank you very much in advance.

Regards.

Ana

[H.Becker]

I didn't check all of these parameters, but the system cells for them are VMS words, as you can see from the name ACP$GW_HDRCACHE:

$ printf "%d\n" $((0xffff & 89920))

24384

$ 

[Ana M. García Olivencia]

Thanks for the reply.

I don't understand what you mean. Can you explain it a little bit more or point to suitable documentation?

Ana

[H.Becker]

The system parameter is limited by the size of the system cell, where it is stored. A VMS word consists of two bytes. So for unsigned integers you have a max of %XFFFF, which is 65535. When setting a bigger value, for example 89920, which is %X15F40 only the two lower bytes are stored into the system cell, which is %X5F40, which in turn is 24384. That's the value you see for ACP_HDRCACHE. That's the same value which you get from the expression 89920 & %XFFFF.

No, I don't know whether and where this is documented.

[Hoff]

Documentation beyond what's in the system parameter help text (SYSMAN> HELP SYS_PARAMETERS, etc) and related published documentation and available via Google queries is what is found in the OpenVMS source listings; a review of the operating system source code.

I would not automatically assume that the performance manual has been updated to reflect the XFC changes, either.  XFC is built on the existing structures, but it has its own controls and displays.  (Given that there are all of five (5) references to XFC within that document, there isn't a whole lot of coverage in that manual.)

As for the "sporadic but painful I/O problems", you will want to look at what your application is doing in some detail (and describe to us what you are observing in some detail), and particularly characterize what's happening when the performance goes sideways.  VMS I/O is very slow and very cautious, and many of the I/O subsystems I've encountered on VMS (like most of the SAN hardware) are far from current speeds and feeds.  

With hit rates and I/O caching, if you're thrashing your caches due to file opens or piles of file access, or if you're generating logical I/O requests for instance, then it's not at all difficult to produce poor hit rates and ineffective caching.  Faster I/O, and reduced I/O, and application I/O, and potentially implemting changes such as enabling RMS global buffers.  But without some idea of what's occuring with these  "sporadic but painful I/O problems", all of this is sheer speculation.

Some reading: 

http://h71000.www7.hp.com/doc/82final/6549/6549pro_032.html

http://h71000.www7.hp.com/openvms/journal/v15/xfc.pdf

http://labs.hoffmanlabs.com/node/632 (finding hot files)

And various other documents and searches.

And if you need more performance-related assistance with this issue, then get somebody familiar with tracing VMS I/O, or ring up HP support and see what they might suggest.

[Bob Blunt]

Ana, there are many factors related to tuning OpenVMS and AUTOGEN alone is a conservative tool to use.  IF there are system parameters that are "out of tune" (so to speak) AUTOGEN will make adjustments as it sees fit if you're not "telling it" to be more aggressive by adjusting the rules with additions to MODPARAMS.DAT   There are other tools available that can tell you if those ACP parameters are really underallocated besides AUTOGEN.  I'd suggest reviewing the MONITOR utility as there are several "classes" of MONITORing tools you can use to watch how the ACP caches are being used.  That would show when your system's "hit rate" for those caches is low and that will usually trigger AUTOGEN (with feedback) to increase them conservatively as needed.

If your system or cluster is new or your workload has changed dramatically or you've migrated to new hardware it might be beneficial to engage someone with tuning skills to help your situation.  There are several tuning tools available (from HP and other vendors) that can be used to generate tuning suggestions.  Based on all the factors involved you might find that you're already seeing relatively optimal performance OR that you have room for improvement.  The factors related to tuning OpenVMS for your circumstances can be very complex and usually involve more than adjusting one or two system parameters or classes of parameters.  The main consideration is that there is NO "fast switch" for OpenVMS and any tuning endeavor becomes a regular, sustained effort at achieving the best balance of combined factors that hopefully achieve the most positive results.

bob

[Andy Bustamante]

>>> when booting, they don't appear

Review the help sysgen help for write.  Note the difference between SYSGEN>WRITE ACTIVE and SYSGEN> WRITE CURRENT

>>> having sporadic but painful I/O problems

It depends.  What's the storage behind this system, what's the application, what's the ratio of read to write?  A VMS system can easily generate enough I/O to bottleneck a single (raid/mirror) disk.  Work out what the application is doing and then plan to resolve the problems.  Changing sysgen parameters might be a start.  You may be better off relocating files or reconfiguring storage.  T4 can be a major help.  It depends. 

[Hoff]

> >>> when booting, they don't appear
> Review the help sysgen help for write. ...

And y'all probably shouldn't be making system parameter changes out at SYSBOOT, in general.  That's what MODPARAMS.DAT and AUTOGEN are intended and used for.  Making changes at SYSBOOT and directly in SYSGEN can destabilize a VMS system, as it's AUTOGEN that knows the relationahips and the limits among the parameters, and not SYSBOOT nor SYSGEN.  And changes made via SYSBOOT nor SYSGEN can get lost if the changes are not (also) reflected within the MODPARAMS.DAT file.

FWIW.

[Andy Bustamante]

As Hoff reminds us, using modparams.dat is the preferred way to provide input into the system tuning process and leave a history for the next frustrated system manager. Bumping these param may also require a bump in non paged pool. Autogen would (eventually) note that.

[Ana M. García Olivencia]

Thanks all for the information provided.

The problematic situation arises when accessing to directories with a lot of files and multiple users accessing them, and when doing deletion operations on them. We have seen very high values in the I/O operation rate (about 1500 ) on the affected disk. So, we are trying to reduce the disk I/O increasing  the main cachés hit ratio.

We collect MONITOR information at 5 minutes interval and, as the problem is sporadic, the average values are, in general, good. The same happens with feedback information in AUTOGEN that tells that cache hit are at 100%. But analyzing these caches in the moment of the problem are not as good.

According to the ACP parameters help, increasing the value of these parameters only has, as a negative effect, the memory consuption. As we have a system with plenty of free memory, I want to make use of a part of that memory  to increase these parameters until a reasonable amount, and I thought that AUTOGEN could tell me that information. As a test exercise and in a test system, I tried to assign the maximum value for those parameteres in MODPARAMS.DAT and execute AUTOGEN to see the changes or the warnings in case this didn't work and, after AUTOGEN calculations, the only change was, logically, the PAGEDYN parameter (a great increase, in fact). Changing this value and executing again AUTOGEN, there were no more changes. I rebooted and the message at booting was "Insufficiente dynamic memory". Clearly, there were more parameters involved that AUTOGEN didn't reply about.

Until now, I have been able to increase something these parametes (the values written in my first post )with some improvement in the performance.But my question is: Is there an easy way to increase these parameters until the highest, but not painful value for my system, without the risk of not being able to boot?.

I know this is a possible solution or improvement to my problem. Of course, I don't discard the possibility of decreasing the number of files and acceses to the disk, as you have suggested.

Thank you very much in advance.