Re: datase connectivity problem
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I second that on <i>nprocs. </i>For some reason many of the SCO in-
<br>stalls that I have seen have gone in without the tuneable parameters
<br>being adjusted. Out of the box settings are typically way too low and
<br>need to be bumped up, afterwards many related problems go away.
<br>Check "/usr/adm/messages" and grep on "err", look for anything
<br>related to <i>fork </i>errors<i> </i>as in<i> too many forks: </i>which
is a typical ind-
<br>icator that the <i>nrpocs</i> is too low. <i></i>
<p>NETTYPE is an optimization parameter however this is not it's
<br>primary purpose. This is to define poll-threads and their behaviour,
<br>such as which VP to reside on, how many to spawn, how many
<br>concurrent connections to maintain with clients and on which trans-
<br>port protocol. Therefore NETTYPE defines poll-threads. Listen-
<br>threads are defined by DBSERVERNAME and for each alias a
<br>new listen-thread is spawned. Try onstat -g ath and look for <i>soc-</i>
<br><i>tcppoll</i> and <i>soctcplst</i> as an excercise. Poll-threads receive
connect
<br>requests from a client process then calls a listen-thread to authent-
<br>icate the user. The listen-thread starts an <i>sqlexec</i> thread.
Specifics
<br>aside, the poll-thread receives inbound communications from the
<br>client to the server and the sqlexec thread sends outbound comm-
<br>unications from the server to the client. How you configure the poll-
<br>threads via NETTYPE is a performance issue after the fact that they
<br>have been configured -- they are an integral part of IDS. Hope
<br>this helps some.
<p>have a nice day, Richard Palmer.
<p>"Henderson, Scott" wrote:
<blockquote TYPE=CITE>Christina,
<p>My advice to you would be to review the IDS_7.2 document in
<br>$INFORMIXDIR/release/en_us/0333
<p>First page you will find kernel parameters, you will also find kernel
<br>parameter suggestions on the last page. Review these with your
Unix admin,
<br>they will be able to provide you with a kernel listing. Unless
you wear 2
<br>hats, in which case you can provide this yourself ;-)
<p>109 connections - 1 userid? If so I would check the value of nproc this
<br>value specifies the number of processes a user may have active.
While your
<br>at it check maxfiles and nfiles. By default these are usually fine
but ya
<br>just never know who's been monkey'n around.
<p>It is my understanding that NETTYPE is primarily an optimization parameter
<br>for connections. But I may be wrong. I would appreciate comments
on this.
<p>Hope this helps,
<p>Scott H.
<p>> ----------
<br>> From: Christina Southam[SMTP:christina.southam@dla-law.co.uk]
<br>> Reply To: Christina Southam
<br>> Sent: Wednesday,
January 05, 2000 10:16 AM
<br>> To: informix-list@iiug.org
<br>> Subject: datase connectivity problem
<br>>
<br>> We have an application which connects from client pcs (using informix
<br>> client
<br>> software) to an informix database (v7.22) running on SCO unix
(v5.0.4.)
<br>>
<br>> Recently we have noticed that once we reach 109 connections to the
<br>> database
<br>> any subsequent connections hang/fail to connect.
<br>>
<br>> It has been suggested by Informix support that this is due to an
operating
<br>> system kernel parameter as they say the informix side of things is
<br>> configured correctly.
<br>>
<br>> Has anyone seen this before/can anyone suggest what the parameter
might
<br>> be???
<br>>
<br>> Christina Southam
<br>>
<br>></blockquote>
</html>