Re: dbservername/dbserveraliases/nettype
Scott Kolaya wrote:
> Art S. Kagel wrote:
> >BTW be careful to not use the same port for shared memory and tcp in
> >the sqlhosts on the server >
> >Art S. Kagel
> Art,
> We've been using the same port for shared memory and tcp for a year now in
> production.
> 7.23
> ex. sqlhosts:
> prod onipcshm aruba sqlexec
> onconfig:
> DBSERVERNAME prod
> DBSERVERALIASES
> NETTYPE ipcshm,1,256,CPU
> NETTYPE soctcp,1,256,NET
> The engine starts a listener thread on the sqlexec port and also accepts
> shared memory connections.
Not exactly. You have a SOC VP listening for network connections and
one CPU VP polling for shared memory requests.
> if you only have a NETTYPE of ipcshm then the service entry in the sqlhosts
> for the onipcshm seems to accept anything (not needing to be defined in the
> services file) The manual says that the services entry is an internal
> placeholder when used with ipcshm, whatever that's worth.
Yes exactly.
> The local process seem to connect via shared memory fine while the tcp
> connections use the sqlexec socket.
> do you know of any drawbacks?
Yes, as I said, there will be a noticable increase in system calls per
second if you do this. With only one CPU VP and one NET VP you may not
be able to descern the effect but we run 8 NET VPs and have shared
memory listeners in all 28 CPU VPs that we run. In our case, not only
is there a noticable, and quantifiable, increase in system calls when
the network and shared memory connection share a service, there is a
noticeable slowdown in system responsiveness. This is true even though
we have 4 out of 32 CPUs reserved for UNIX services. I'd call that a
drawback!
Art S. Kagel