TCP Performance and Connections

The following is my performance notes and connection problems for tli connections with Informix. My platform is Sequent 2000/790 dynix/ptx 2.1.5 If anyone is experiencing similar tli problems I would like to hear from you. -------------------------------------------------------------------------- TLI performance notes: -------------------------------------------------------------------------- 1. Run tli poll threads thru the CPUVPs. 2. Run multiple tli poll threads. 1 per CPUVP. I have not experienced any degradation in performance due to multiple poll threads. 3. Make sure the allowed connections for each poll thread is adequate. This is also true for your shm poll thread. Or you will find that you run out of connections to the database even though you haven't exceeded the number of USERTHREADS. 4. Both tli and shm pool threads can run thru the CPUVPs. (Informix has said, although I don't do this.) The number of configured CPU poll threads cannot exceed NUMCPUVPS. I run 2 Informix engines on a Sequent 2000/790 8 Pentium cpu platform Engine 1 (prod): 4 CPUVPs with 3 tli poll threads. My shm pool threads runs thru a NETVP NETTYPE ipcshm,1,400,NET NETTYPE tlitcp,3,200,CPU Engine 2 (devel): 2 CPUVPs with 2 tli poll threads. shm pool thread runs thru NETVP. NETTYPE ipcshm,1,100,NET NETTYPE tlitcp,2,100,CPU ------------------------------------------------------------------------- TLI Connection Problems -------------------------------------------------------------------------PROBLEM: The tli service port will close and no new connections can be made to that port. The closed port can be verified with /etc/netstat. The port will have a "CLOSED" status. The other tli ports are OK as is the shm poll thread. Users already connected were not affected. The closing can occur at anytime. The number of users connecting or already connected didn't matter. I typically have 10-20 tli users. There is an incomplete session which is holding the port closed. Using onstat -g ntt, look for a session with no thread name. With onstat -g ses you will see that it is an informix session. This session has control of the port. You cannot onmode -z it, because it is not "whole". Under 7.10.UC1: -- Once the port was closed the engine had to be rebooted to open the port. Workarounds and Solutions: -- More tli ports were added. We went from 1 to 3. If a port closed we would switch the I-Net on the PC needing to connect to an open port. But this is not easy to do for 50 PCs. -- TCP_KEEPIDLE was changed to 15 minutes from 2 hours. -- Bug #31422 was fixed. This led to the next rev. Under 7.10.UC2P4: -- Once a port was closed it would reopen within 6 minutes. (Attributed to bug fix). Unfortunately closings were frequent and made the database look unstable to the users. -- Once in a while a port would close and fail to reopen. In this case the engine was rebooted. This is actually a seperate tli problem. Workarounds and Solutions: -- Bug #40644 was fixed. This led to the next rev. Under 7.10.UC3X1: -- Under a stress test program 20,000 connect and disconnect cycles were performed without a closed port. This was against a single tli port. The program was run from 2 PCs at the same time. We feel this problem is solved. ---- BUT ---- Under 7.10.UC2P4 and 7.10.UC3X1: -- We still have ports that close and DON'T reopen although this is infrequent. For a short time we were able to replicate this problem on a test machine. From our OBSERVATIONS we felt the PC ran out of conventional memory as it was connecting to the database causing the PC program to hang. The PC was usually rebooted (power-off - power-on). The PC was running NETMANAGE 4.01. It was upgraded to NETMANAGE 4.51. Under test conditions, with no conventional memory available, the PC program now does not initiate a connection to the database, therefore no ports close. There seems to be one real nasty behavior of the UC3X1 engine with a closed port the wouldn't reopen. The engine will not respond to onmode -ky or onmonitor and I have to kill -9 oninit to bring the engine down. My bug fixes were probably related to the Sequent/Informix combination, but similar bugs may occur under other platforms. Again, if anyone has similar experiences I like to hear from you. -- Steve Berg spb@masada.nb.com