T.R | Title | User | Personal Name | Date | Lines |
---|
4302.1 | | UTRTSC::SWEEP | I want a lolly... | Tue May 27 1997 04:19 | 4 |
| How about the process states.
Are there any RWSCS states.
Adrie
|
4302.2 | New facts | H2SO4::GERSBACH | Edwin Gersbach MCS Switzerland | Thu May 29 1997 12:42 | 40 |
| I've taken the responsibility for this problem from Lenio.
>> Are there any RWSCS states.
Yes, there is PWRK$LMSRV which is in RWSCS a lot. While I first thought the
process is waiting in this state, further investigation has shown that it is in
this state again and again. I have found that opening a textfile using notepad
generates some outgoing locks on the system where the client is connected to and
a similar number of incoming on the lock-master. This is to be expected, but the
fancy thing is that using a DOS/WIN client this number is about 20 while using a
WNT client this number is about 200!!!
As the customer has migrated some 300 clients (out of 1400) from DOS/WIN to WNT
the amount of distributed locks to be handled has increased dramatically. It
seems that we have exceeded the number of distributed locks that can be handled
efficiently, either by Pathworks or by VMS.
We are currently investigating two possibilities to regain a satifactory
performance:
1) One of out WNT cracks is checking with microsoft whether there is a
possibility to reduce the amount of locking generated by WNT (I cannot
beleive that this is caused by notepad itself, but rather by the underlying
filesystem).
This is treated a short term solution only as it just delays the problem
until some more clients get migrated.
2) Replace the Cluster (which is solely used as a pathworks server) with a
single system providing the same (or more) power as the current three
2100/4/275. It seems that Pathworks/VMS is unable to cope with that many
WNT clients in a cluster environment - that is, when the server is not also
the lock-master.
The drawback here is that we lose the failover functionality in case of a
hardware breakdown. To have two systems but run pathworks only on one is a
great waste because - as I said above - this cluster is not used for any-
thing else.
Other hints are greatly appreciated.
Edwin
|
4302.3 | More info please. | CPEEDY::FLEURY | | Thu May 29 1997 13:08 | 3 |
| What is the cluster interconnect?
Dan
|
4302.4 | | UTRTSC::SWEEP | I want a lolly... | Fri May 30 1997 07:11 | 3 |
| contact off-line
Adrie
|
4302.5 | CI | H2SO4::GERSBACH | Edwin Gersbach MCS Switzerland | Fri May 30 1997 08:49 | 5 |
| CI
Is there anything more of interest?
Edwin
|
4302.6 | | H2SO4::GERSBACH | Edwin Gersbach MCS Switzerland | Wed Jun 04 1997 12:42 | 10 |
| Just for the record:
The customer has now replaced the cluster by a single A4000/5/400.
After some problems due to LMSRV running out of enqueue quota
(this problem is IPMT'ed) the system is now runing stable and with
good performance. The only drawback is the lack of failover. We are
going to discuss possible solutions with the customer, but 'till now
we don't even know what to suggest.
Edwin
|
4302.7 | | UTRTSC::SWEEP | I want a lolly... | Thu Jun 05 1997 04:31 | 6 |
| I saw your IPMT.
Do you still have debugging enabled? If so, switch it off,
or use the alternate startup mechanism.
Adrie
|
4302.8 | | H2SO4::GERSBACH | Edwin Gersbach MCS Switzerland | Fri Jun 06 1997 04:33 | 14 |
| Re .7
>> Do you still have debugging enabled? If so, switch it off,
I'm not aware that it has ever been turned on.
>> or use the alternate startup mechanism.
What do you mean by that?
btw: in the meantime we also had to increase MAX_IPC_MESSAGES in PWRK.INI
because the LMSRV hung with 'failed to allocate message buffer'.
Edwin
|
4302.9 | | UTRTSC::EISINK | No Kipling apes today | Fri Jun 06 1997 06:10 | 16 |
| %% I'm not aware that it has ever been turned on.
Look in pwrk$lanman:lanman.ini for debug = yes in the [vmsserver]
section.
>> or use the alternate startup mechanism.
%% What do you mean by that?
See note 58 in utrtsc::Pw_tools conference
%%btw: in the meantime we also had to increase MAX_IPC_MESSAGES in PWRK.INI
%% because the LMSRV hung with 'failed to allocate message buffer'.
There are some notes dealing with this, see 4247 , 4160 etc.
|