You have specified for each protocol 1 listener thread and 50 connections for every listerner thread. You can try increasing both protocols to 100 connections/thread (change 50 into 100 in NETTYPE parameters).
I've seen several cases where this did the job....
It is the number of sessiosn that can be serviced by this protocol. Normally a listenerthread can support 150 concurrent ransaction without any problem. If you have more usesr you can specify more threads.
Will it be advisable if I am setting the 'idleout' time to 120 sec, since in our case, some of the users keeps two/three INFORMIX logins open and then leave it idle after their use. Shall I force them out, so that I can maintain the concurrent users numbers within the limit. Will this have any negative effect on INFORMIX.
There are two issues involved. I tries to set a plus (+) for positive and a minus (-) for megative effects:
* Close long open standing connections
+ Keep number of connections low and stay within license (if user based)
- Does application handle this, or get users error message?
- Time spent reconnecting
* Keep connections open
- Higher chance on beaking your license (if user based)
* Keeping connections open is almost no overhead for IDS. IDS works
with a central listener thread and only wake up threads (connections)
that request work to be done.
Sorry to trouble you, I am again seeking help with the listener thread error
As suggested in our previous thread, I have modified the config file with the
nettype parameters (from 50 each)
NETTYPE tlitcp 1,100, NET
NETTYPE ipcshm, 1,100, CPU
Our system was running perfectly with 1 or 2 restart in between, today after 7 days of continous running Server got hanged. The maximum concurrent users had reach 104 and active users at the time of hanging was 85. Do you feel I need to increase the no of connections per thread to 150 now. I have 50 - 60 users working in the system.
Can you post (or email me personally at email@example.com) the full onconfig file of your system (onstat -c) and can you give a small situation report on your system (tyep of machine, brand, os version, number of CPU's and how most users connect (tcp/shm). Best way of knowing the last is giving the command: onstat -g ath | grep sqlexec. It will then then either sm_read (shm) or netnorm (tcp).
If you can send me this info I hope I can give you a correct answer.