| > The number of concurrent ALL-IN-1 users on the cluster is +/- 2000.
I hope it's a "big/fast" VAX.
> The customer has now a problem with the number of DDS-listerner
> processes on the system and the system can't create more DDS-listenr
> processes on the VAX.
How are you reaching this conclusion? Please state the evidence.
(I'm not saying you are wrong; I'm simply testing your analysis.)
> Because when starting EM under ALL-IN-1, the system does a mail
> initialise. Is this already creating a link or not and how long is this
> link staying open?
Normally, 'mail init' does a DDS$INIT call, and also submits two
queries. A link will exist during this processing and is then closed.
> When doing a remote DDS lookup from the AXP, you are using the REMOTE QUERY
> SERVERS. Are those query servers handling all the communication calls or
> are they talking to the local VAX listeners?
The Listeners are handling the communications. The Query servers are
processing the transactions. (FYI - "Introduction to Message Router"
documents the flow of work for various types of DDS activities.)
> When you have a look at the DDS-Listener processes you can see that they
> don't have 5 links open for each process. The configuration of DDS was
> "Number of query servers = 2" and "Number of maximum links =5".
DECnet limits only one process to being declared as an object at any
given instant. When a link request comes in for object 55, and if there
is a process declared as object 55, the link is handed to that process,
else the link is handed to a compatible netserver process, else it
starts a netserver process and (eventually) hands the link to it. (FYI
the currently declared process can be determined on Phase IV systems
via NCP SHO OBJ DDSLSTN CHAR; look for 'process id' in the output.)
When a listener reaches it's max number of links, it UNdeclares itself
and does a creprc to start a new listener process. When this new proc
finishes it's initialization, it (tries to) declare itself as object 55.
(Ditto for any listeners started via DECnet's netserver processing.)
The first process continues handling communication tasks for its links.
As these tasks complete and the other end disconnects, it will attempt
to REdeclare itself as object 55 so it can accept more links. If another
process is currently declared as object 55, this attempt will fail. The
listener will continue to attempt to REdeclare itself every time a link
closes until it has no open links, at which time it exits (and becomes
a normal DECnet netserver process, which may eventually disappear).
Given an (interactive) client only hold a link open during search
processing and the above, what you observe is entirely possible.
> When looking in the manual it can happen in a certain condition that
> the listener doesn't accept any requests anymore (page 3-16 Planning
> and Config guide) before starting up a new listener.
This does not apply to your situation, since you ARE running Query servers.
> Is it possible to change the timeout of those links (are they just
> using the default network timeout or are they using the following
> DDS-config parameters NETTIMOUT and NET2TIMOUT?
There is no 'timeout' on the links. A link is opened when a search is
requested, and closed when the client is finished with the results.
The DDS timeout parameters you refer to are internal timers having to
do with communications across a link (ie ack timers). Note that there
is an exception to the above; NON-interactive proceses (ie servers)
will keep the link up indefinitely (since they are likely to do many
searches back to back) in order to improve response/reduce overhead.
BTW, what is the image ident on the SYS$LIBRARY:DDS$RMT_ALPHA.EXE?
There have been a couple of fixes/improvements to this image since
the version that shipped with ALL-IN-1 V3.1.
Dave
|
| Hello,
Dave.
The version of SYS$COMMON:[SYSLIB]DDS$RMT_ALPHA.EXE is
Press RETURN to continue, or enter a period (.) for next file:
Image Identification Information
image name: "DDS$REMOTE"
image file identification: "DDS V3.3-016"
link date/time: 19-MAR-1996 09:02:40.99
linker identification: "T10-62"
Press RETURN to continue, or enter a period (.) for next file:
Hello,
Concerning the error message. The customer doesn't have the exact error
message anymore. They didn't have this message anymore today and they
didn't write it down. I was something with %XPO... error appending
[invalid string] too 100...
The customer thinks that is has something to do with the process names
that exceeds 15 characters when starting the DDS$l..._100 process.
I will ask to increase the number od links to 20 instead of 5 and
perhaps they will move also the DDS$INQUEU.DAT and DDS$OUTQUE.DAT files
to a RAM-disk.
Do you have other ideas to improve performance?
Thanks,
Regards,
Luc.
|
| You do have the up-to-date dds$rmt image; someone must have put it
on their system (since it's not in the ALL-IN-1 V3.1 kit).
Yes, you are running into the process name length limit.
I'm surprised you really got up to 99 listeners...
Increasing the max number of links is a good move. If you get really
desperate wrt the 99 limit, raise an IPMT case; there may be a way to
shorten the other parts of the process name...
Putting the INQUE onto a RAM disk may be a bad move; queuries are not
the only things that go into the INQUE, and a system failure would
result in these being lost (unless you are talking about an ESE disk
with hard-disk backup). There was an ALL-IN-1 performance guide that
had a number of suggestions in this area (a couple which I recall I
did not agree with, but I don't remember the details...) Other things
to look at would be RMS tuning - increasing the bucket size, for example.
BTW, I hope the VAX member isn't Ethernet clustered, or if it is that
the disks with the DDS files are local to the VAX...
If you have a lot of concurrant queries going on, you might also want to
increase the number of query servers.
Dave
|