[Info-vax] What choices are available to the OpenVMS Process Scheduler once all the CPUs are in use?

[Stephen Hoffman]

On 2016-02-29 03:43:08 +0000, sean at obanion.us said:

> There are a variety of proposals being floated...

Three disks to a virtual unit, if you're going to use one for breakout 
backups.   Disks are cheap.

Get or write some tools that look for disks anywhere near capacity — 
these days and given disk prices, I'd start getting concerned north of 
60% capacity — and add capacity when you get near that.  Disks are 
cheap.

Some folks will recommend a defragger and I'm ambivalent there — they 
work, and you can use the same VMS defragging routines via DFU — but 
knowing which files are hot and fragmented is more interesting.  Disks 
are cheap.

Set the file extension size values appropriately for your hot and 
fragmented files — VMS is idiotic^Wcompatibility!^Wstupid here, and (by 
default) uses a multiple of 5 blocks rounded up past the cluster size, 
and does not adapt to usage.  As usual when VMS is being 
idiotic^Wcompatible^Wstupid here, the resulting problems are tossed 
over to the developer to deal with, or (as happens more often than it 
should for an "enterprise" and "reliable" operating system) to fail to 
deal with.   Disks are cheap.

Segment your temporary data and your file churn from your core hot 
files and your permanent data.  Again, disks are cheap.

Redundancy — that includes multiple servers.

Out of slots in your storage shelves or with disks more than ~3 years 
old?   Add a shelf, and rotate to larger disks.  (Enable DDS and DVE 
features here.  Makes migrations easier.  VMS is 
idiotic^Wcompatibility!^Wstupid here, and doesn't enable these 
shadowing features by default.)

Periodic reboot tests.  Your measured uptime is how long since your 
last tested your boot path.

Periodic disk analysis.  Probably once a week, more or less depending 
on your schedule.

Other updates as required.

-- 
Pure Personal Opinion | HoffmanLabs LLC