| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 841.1 | more information please... | TAPE::SENEKER | which way to go? | Tue Jun 03 1997 10:58 | 13 |
| Your configuration is valid.
The actions of the system do not appear unusual in action. But with
the information provided I cannot tell if the length of time these
actions take is unusual. I have a few questions.
o What is the MINSWAP value after the reboot?
o When you say shutdown/reboot do you mean crash/reboot, i.e. why
didn't the JB devices get dismounted?
o Were are you doing the directory command from?
o How long is it taking to get all the JB devices remounted?
Rob
|
| 841.2 | | LEFTY::CWILLIAMS | CD or not CD, that's the question | Tue Jun 03 1997 11:28 | 11 |
| Actually, a mixed cluster with V5.5-2 and V6.2 is not recommended as
anything other than a transition from 5.5-2 to all 6.2.
I would not call this a legal configuration, nor is Ovms engineering
likely to like it.
I would expect it to work, however... Changes in the MSCP server, etc,
may be causing the problems.
Chris
|
| 841.3 | good thing about notes, multiple eyes | TAPE::SENEKER | which way to go? | Tue Jun 03 1997 14:37 | 5 |
| Chris, thanks for pointing out the 5.5-2/6.2 mix, my mistake.
Alessio, can the customer upgrade the cluster to a supported mix
of OpenVMS versions?
Rob
|
| 841.4 | sounds like... | CSC32::S_WASKEWICZ | | Tue Jun 03 1997 14:43 | 7 |
|
Sounds just like the problem that OSMSAE1034 fixed, doesn't it?
But its especially for Alpha 6.2/OSMS 3.4, I believe.
Steve
Alias CSCPAT_2222
|
| 841.5 | | TAPE::SENEKER | which way to go? | Tue Jun 03 1997 16:46 | 5 |
| Similar sounding yes, but during the testing of the OSMSAE1034 problem
nothing was found on the VAX side, i.e. VAXen would not generate the
I/O that was causing the swapping, only ALphas.
Rob
|
| 841.6 | More info here | TOSSUB::ALESSIO | | Wed Jun 04 1997 15:52 | 25 |
| Hello everybody and thank for the replies,
i try to give you more informations:
- After reboot MINSWAP is 15 seconds.
- The customer has done some shutdown and reboot of the MicroVax 3100
serving the juke box without dismounting the disks on the cluster
nodes using them (no crash has occurred) in order to simulate
some critical condition to his application.
- The "directory" command was issued on the CI nodes; the MV 3100
does't mount the JB devices, it just serves them via MSCP.
- The normal mount of JB devices takes about 30 minutes.
- The customer has a DB application that needs to run with VMS 5.5-2 on
the CI nodes in the cluster, on the MV3100 Open VMS 6.2 and OSMS
3.3-1 are needed to support RW531; OSMS version 3.4 was not installed
because it doesn't support MV 3100/10.
Best regards
Pier Giorgio Alessio
|
| 841.7 | some ideas | TAPE::SENEKER | which way to go? | Thu Jun 05 1997 12:49 | 22 |
| This is what I think is happening.
o Shutdown 3100 - all disks go into Mverify on CI nodes.
o Reboot 3100 and restarts mounts, all disks must go through mount
rebuild
o CI nodes have I/O issued to volumes in Mverify "DIR" so that I/O
is stalled until the Mverify completes. The mounts on the 3100
are forcing swaps which may delay completion of some Mverify
operations.
o After all JB devices complete Mverify on a CI node the DIR I/O is
started. If some volumes are still mounting on 3100 then additional
delays may be caused.
o Due to the constant swapping caused by all volumes being remounted
and Mverify I/O the jukebox I/O throughput is poor causing the total
time to be an 1� hours.
If this is a test, try one test with MINSWAP=5 and another with
MINSWAP=30. After the system has recovered you can reset MINSWAP to
the normal value. I think the best performance will be with MINSWAP
set to 5 during the recovery period.
Rob
|