SYSGEN Parameter

[EWONG]

Hi,

We will upgrade two cluster members (total of 4 members) from existing Alpha DS20E, 2 x 833Mhz, 4GB memory to Alpha ES47, 2 x 1.15Ghz, 6GB memory. Do we need to modify any SYSGEN parameters due to the upgrade of machine power and memory ? Also, any parameter/setting is hardware dependency such that we need to change as well ?

Thanks,
Edmond

[Hoff · Accepted solution]

Review the contents of the current MODPARAMS.DAT file to ensure that the values set there are still appropriate and remove those no longer needed, and then invoke AUTOGEN with FEEDBACK and reboot, and then invoke AUTOGEN again several times over the month or two, to allow the settings to adjust to the system configuration.

Remove the duplicates from MODPARAMS.DAT, and remove entries and settings that are no longer required, and replace absolute settings with relative settings -- XYZ=123 can hamper AUTOGEN if the value needs to be higher, where MIN_XYZ=123 can be more appropriate -- and hunt down and remove any references to PHYSICALPAGES in MODPARAMS.DAT.

A full system performance review can be in order here, and I'd likely look to load up and run MONITOR (recording every fifteen minutes or so) or I'd load up and run the T4 agents. This to collect baseline performance data. All this is standard stuff for tracking system performance. (See the OpenVMS performance manual for an intro to the topic of system tuning.)

If you are interested, I have posted some details of the AlphaServer ES47, ES80 and GS1280 series EV7 interconnections -- the speeds and feeds and caching and such -- over at http://64.223.189.234/node/20 The biggest change over what you have with the AlphaServer DS20E involves how fast data can be moved into and out of the processors.

Stephen Hoffman
HoffmanLabs

[Robert Gezelter]

Edmond,

I concur with Hoff. A cleanup is always a good thing, and many MODPARAMS files have accumulated contradictory and non-productive settings over time.

I must emphasize however, that simply booting the new nodes into the cluster from the existing roots will work. Please remember to check for any patches that apply to the new configuration that may not have been relevant to the old configuration.

- Bob Gezelter, http://www.rlgsc.com

[Todd Maurer]

The other two have covered things well. I'd add that I'd do the AUTOGEN, but I'd also follow up with another AUTOGEN a week or two later, SAVPARAMS to TESTFILES. Then review SYS$SYSTEM:AGEN$PARAMS.REPORT to see if it's recommending changes worth another reboot.

[Andy Bustamante]

I recently performed a similiar upgrade, using an old root to make a new system on line. You'll want to run autogen and follow up as Todd states once the new system is under load.

You may also need to update your network configuration. In my case I needed to update the definition of LLA0: since we use LAN failover. NETCONFIG.COM (or NET$CONFIG.COM) and TCPIP$CONFIG.COM may need to be run.


Andy

[EWONG]

Dear all,

Thanks for the information and recommendation. Should I use the following phases "SAVPARAMS" "TESTFILES" "FEEDBACK" to collect the autogen result ? In view of the machine power, should we change the MSCP (i.e. MSCP_BUFFER is 1024 currently) related parameters to enhance the performance ?

Thanks,

[Jon Pinkley]

Edmond,

You asked:

>In view of the machine power, should we change the MSCP (i.e. MSCP_BUFFER is 1024 currently) related parameters to enhance the performance ?

Just curious, why did you ask about that specific sysgen paramter? Have you fine tuned it on your existing systems?

This is one of the parameters that AUTOGEN will adjust based on statistics that are collected.

What disk are being MSCP served? Do you have locally attached SCSI devices that are being served to other cluster members? If so, and you want to make sure AUTOGEN has accurate statistics to base its calculations on, make sure that the "busy" period is included in the sample that autogen savparams has saved.

Look at SYS$SYSTEM:AGEN$PARAMS.REPORT after you run autogen. It will tell you what factors are being considered in its calculations.

Jon

[Ian Miller.]

Should I use the following phases "SAVPARAMS" "TESTFILES" "FEEDBACK" to collect the autogen result ?

Yes - when the system is busy.

You need to look at MSCP serving performance after the upgrade to see if altering the parameters is required. Running AUTOGEN after a week and looking at the report would be good idea.

[Hein van den Heuvel]

Hello Edmond,

First of, I am a little surprised you went from 4*DS20@2p to 4*ES47@2p instead of 2*ES47@4p or 3*DS20@2p + 1*ES47@4p which generally would have better price/performance characteristics. What is it in application or availability needs that lends itself better to more smaller machines?
What was the thinkig behind that decision?
What drove the upgrade in the first place?
(Expandability of the ES47 platform?)
What was the problem they were trying to solve (color scheme? computer room unifomity? noise? cpu horsepower?)

Next, along the lines of question from Jon and Ian.
- Are you actually using MSCP serving.
- What makes you think it is a problem.
- Why do you tink autogen can not handle it?

What is the storage and its connectivity?

Give the new config a week or to to perform and then worry about which performance attributes to tweak. Be sure to enable T4 or similar to learn where the pressure is!

Regards,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[EWONG]

Hi all,

Actually we have 4 x DS20E@2p to form the cluster currently ( 2 at primary site and 2 at secondary site), the coming upgrade is to replace 1 x DS20E at each site by ES47@2p. Our main application is running on only 1 x DS20E at each site (active-active), and other satellite application is running on the other cluster members. All those application will access the same database files. At each site we have the RA8000 disk storage and using SCSI daisy-chain to connect the cluster members. The volume shadowing is used and the remote shadow is formed for application and data disk. That's why I am quering whether should adjust the MSCP related parameters in ES47 as the machine power is more than DS20E ?

many thanks

[Jon Pinkley]

Edmond,

If I understand your last note, you are using host based volume shadowing between local SCSI attached disks and remote SCSI disks that are being MSCP served. If that is the case, then yes, you will want to look closely at your MSCP performance. You will want to look at your MSCP_CREDITS too, since a remote link is going to add latency and bandwidth constraints.

See this thread: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=549229

and look at Keith Parris' notes concerning MSCP_BUFFER and MSCP_CREDITS and how to monitor for problems.

Also, here's a link to a performance presentation given by Guy Peleg that has some slides on MSCP.

http://www.hp-interex.ch/20051004/14_openvms_information_desk.pdf

Both of these links are somewhat dated, but they still have useful info.

Have fun,

Jon

[EWONG]

Hi Jon,

Thanks for the information.

You are right as we are using host-based volume shadowing and MSCP performance is one of my concerned area.

Thanks,
Edmond