IDS very slow

I am setting up a disaster recovery server and am having an issue with the Informix. Compared to the production server, the response time for certain commands is really slow. For instance, it takes up to 25 seconds to open onmonitor and using the onspaces command is also really sluggish. The only obvious difference I note on the two servers is that my dbspaces on production have the flags 0x40001 on live and 0x60001 on the backup server when I run onstat -d. Would this matter? And why the difference if the same version ofInformix is being used to create dbspaces (11.50.UC1) under the same OS. The speed issue appears whenever a database is being accessed. If I go into dbaccess there is no delay. Once there, selecting a database (even sysmaster) causes a 20 - 25 second delay.

My gut feeling is that this is probably a DNS issue with the address of the remote server. Are you seeing this only when you connect to the database? Does everything work ok once you have connected? An experiment would be to modify the SQLHOST file to use the actual IP address and service number rather that the name of the machine. and service name. That way there would be no need to access DNS. If that seems to resolve the performance issue, then have a talk with the system administrator. It might be that the DNS values are not being properly cached. M.P. From: "ROBERT MOSS" <rmoss@newtonma.gov> To: ids@iiug.org Date: 01/17/2012 08:06 AM Subject: IDS very slow [25943] Sent by: ids-bounces@iiug.org I am setting up a disaster recovery server and am having an issue with the Informix. Compared to the production server, the response time for certain commands is really slow. For instance, it takes up to 25 seconds to open onmonitor and using the onspaces command is also really sluggish. The only obvious difference I note on the two servers is that my dbspaces on production have the flags 0x40001 on live and 0x60001 on the backup server when I run onstat -d. Would this matter? And why the difference if the same version of Informix is being used to create dbspaces (11.50.UC1) under the same OS. The speed issue appears whenever a database is being accessed. If I go into dbaccess there is no delay. Once there, selecting a database (even sysmaster) causes a 20 - 25 second delay. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi Robert, It seems that you might have an address resolution problem. The flags that you are mentionning do not have have anything to do with the slowness. Check how your hostname is being accessed; check your sqlhosts file. Try the IP address directly in the sqlhosts file. Cordialement, Regards, Khaled Bentebal Directeur Général - ConsultiX Président UGIF - User Group Informix France IIUG - Board of Directors Tél: 33 (0) 1 39 12 18 00 Fax: 33 (0) 1 39 12 18 18 Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr Site Web: www.consult-ix.fr Le 17/01/12 15:02, ROBERT MOSS a écrit : > I am setting up a disaster recovery server and am having an issue with the > Informix. Compared to the production server, the response time for certain > commands is really slow. For instance, it takes up to 25 seconds to open > onmonitor and using the onspaces command is also really sluggish. The only > obvious difference I note on the two servers is that my dbspaces on production > have the flags 0x40001 on live and 0x60001 on the backup server when I run > onstat -d. Would this matter? And why the difference if the same version of> Informix is being used to create dbspaces (11.50.UC1) under the same OS. The > speed issue appears whenever a database is being accessed. If I go into > dbaccess there is no delay. Once there, selecting a database (even sysmaster) > causes a 20 - 25 second delay. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

I altered the sqlhosts file to use onipcshm instead of onsoctcp for the local instance and that took care of the slowness in dbaccess and onmonitor. I suspect that there is a problem with the host name since it's meant to only be online when the other server is offline so a lot of the configuration is identical. I will need to track down host information and see if there is a conflict. Thanks for the information you both provided.

Is this an HPUX based system (don't remember from your other posts)? I have often seen that onstat is very slow to start up and local clients to connect to instances on HPUX system using TCP connection types. I once traced it to a very slow micro-sleep system call (nsleep?) in the connection loop deep in the Informix library - though it was the OS system call that was causing the slowness not the Informix library. That incident reminded me of a warning I got once as a developer about not using the nsleep system call on HPUX from way back when Bloomberg was testing HP/HPUX systems before settling on Sun/Solaris. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jan 17, 2012 at 1:01 PM, ROBERT MOSS <rmoss@newtonma.gov> wrote: > I altered the sqlhosts file to use onipcshm instead of onsoctcp for the > local > instance and that took care of the slowness in dbaccess and onmonitor. I > suspect that there is a problem with the host name since it's meant to > only be > online when the other server is offline so a lot of the configuration is > identical. I will need to track down host information and see if there is a > conflict. Thanks for the information you both provided. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f839c1b317f6304b6bd5ee9

Art, No, it's running on Red Hat EL5. Hopefully I'll be able to track back the name/ip issue. Bob