informix IDS 9.3 refusing to start

[Tim D Fulford]

I think we have a misunderstanding...

If you do not have a shm poll thread the instance will *not* start. INFORMIX requires it for internal communication (How does the socket speak to the internals?)

The rest was advice about how to get the most out of the socket poll thread(s) configured.
(In your case put the shm on a network vp as per first example)

I hope this is clearer now

Regards

Tim

[Umapathy S]

Solved the problem
The system was using NIS and it is not configured properly. I threw NIS out and it worked fine.

Listener thread was able to get entry from /etc/services directly.

[Umapathy S]

Coming to your suggestions Tim. I am using Informix 7.3 on hpux10.2. I have an IDS with NETTYPE onsoctcp. That is running fine and supports quite a number of people doing development and testing.

Now I am moving to Informix 9.3 on hpux11.0. I am yet to see the new features of 9.3. Could you please explain more on that NETTYPE. Because the onconfig with Informix 7.3 didnt contain a parameter NETTYPE.

warm regards
Umapathy

[Tim D Fulford]

Yep you are right, I'm wrong! You can just have one socket poll thread & no shm poll thread!!! (Live & learn)

I tried to use your ONCONFIG etc but the cut & paste failed, so I typed in the relavent info. I've got 9.21 (close enough). It worked fine.

So in the /etc/services there could be either a duplicate "thbs" entries or duplicate port numbers 1526/tcp.

Sorry I cannot help further

Tim

[Rainer von Bongartz]

Tim,

IDS will use a shared memory segment for internal communication even when you don't define a shm poll thread.

onstat -g ath will show.


Umapathy,

NETTYPE is not new in 9.x it was available in 7.x as well. Look at the description for this parameter in your Informix dynamic Server Administrator Guide.

Regards
Rainer

[Tim D Fulford]

Glad to see you got the problem fixed.

NETTYPE has been in Informix for some time, It is just that Informix is "cleaver" & fills in the relavent info if missing

NETTYPE ,,,
protocol - soctcp or ipcshm (there are others tli???>
N-vps - Number of vp's the poll thread will run on
Max-conn - use 100, maximum number of connections it can support/vp
vp-type - CPU or NET. CPU is more efficient as it will reduce the ammount of CPU context switches, which are wasted "ticks" if you can avoid it. If you are predominantly using soctcp connection put the socket on CPU, if shared memory, then ipcshm. Put others on NET

You can have more than one protocol on the cpu-vp, but you must have the appropriate nymber of NUMCPUVPS as this is the hard limit. so this will work for a "mixed" environment.
NETTYPE soctcp,6,100,CPU
NETTYPE ipcshm,10,100,CPU
NUMCPUVPS 16

The rule for setting NUMCPUVPS is
NUMCPUVPS < Total available CPU's on the machine (or partition).
I generally try to balance out the CPU% between application & database. so for an 8-CPU machine you might set NUMCPUVP 6 if App is using about 25% CPU%

If you want to check where the poll threads are actually running on an instance
onstat -g ath | grep pol
if it says Xcpu it is on a cpu-vp, Xsoc or Xshm it is a network vp.

To check the efficiency of a multi cpu-vp system
onstat -g glo
Then look for
o distribution of work between the cpu-vps
o Are the peaks on a poll thread
o Are the Network vps (Xsoc or Xshm) doing alot of work?

Regards

Tim