Informix

 View Only

  • 1.  NETTYPE connections per thread

    Posted Mon January 11, 2021 07:46 AM
    Hi all

    I'm trying to get a better understanding of Informix threads and performance. I have an instance using these values:

    NETTYPE ipcstr,12,200,CPU
    VPCLASS cpu,num=12,noage,autotune=1,max=14

    Is performance impacted when the number of threads starts to reach the 200 per thread?

    Does autotune modify the number of connections per thread, or does it only add another VP?

    If I extract and count the threads for each CPU VP, and find them over the 200 originally configured, is that just autotune doing it's thing, and would I get better performance by increasing the starting number of connections per thread?

    Once threads have been established on a poll, does the database move the threads to an available VP, or can I randomly get congestion on specific VP while others are dormant?

    I've seen a couple of mentions while wandering the interwebs about sleeping forever threads needing to be removed to increase performance? But no further explanation of why. 

    Yeah, that was probably more questions than I had when I first opened this post. Thanks in advance for those patient enough to answer.

    Jason

    ------------------------------
    Jason Ball
    ------------------------------

    #Informix


  • 2.  RE: NETTYPE connections per thread

    IBM Champion
    Posted Mon January 11, 2021 08:48 AM

    Jason:

    I'm going to include your original question here and I will respond to your several questions inline:

    I'm trying to get a better understanding of Informix threads and performance. I have an instance using these values:

    NETTYPE ipcstr,12,200,CPU
    VPCLASS cpu,num=12,noage,autotune=1,max=14

    First, stream and TCP connection types should be serviced by NET VPs. Only shared memory connections should use the CPU VPs. That is because when a TCP or stream connection is quiescent the NET VPs can block on the port waiting for requests from the connected client(s). However, a CPU VP cannot block it has work to do, so on a busy system the clients may have to wait for a CPU VP to become free or enter a wait condition in order to be serviced.

    Is performance impacted when the number of threads starts to reach the 200 per thread?

    No. IBM says that each listener can handle between 500 and 700 connections, so you would be good to between 6000 and 8400 connections as configured.

    Does autotune modify the number of connections per thread, or does it only add another VP?

    Not AUTOTUNE, but the engine automatically adjusts the number of connections as needed except for shared memory connection types which are fixed at startup because memory has to be allocated for each shared memory connection.

    If I extract and count the threads for each CPU VP, and find them over the 200 originally configured, is that just autotune doing it's thing, and would I get better performance by increasing the starting number of connections per thread?

    The 200 "threads" configured in the NETTYPE setting does not refer to the number of listener threads, there is only one thread per VP by default (NUMFDSERVERS can increase that). The number of threads configured in the NETTYPE settings represents the number of data structures (and in the case of shared memory connections the number of communication buffers) created to manage that number of client sqlexec threads.

    Once threads have been established on a poll, does the database move the threads to an available VP, or can I randomly get congestion on specific VP while others are dormant?

    All listener threads listen on all client ports once they are connected.

    I've seen a couple of mentions while wandering the interwebs about sleeping forever threads needing to be removed to increase performance? But no further explanation of why. 

    Not sure what this is referring to. In general, threads that are "sleeping forever" are simply not busy. In the past Informix reported may threads "sleeping forever" that were actually waiting on some resource. That has mostly been corrected, so at least in v12.10 and later these threads really are just waiting for work. Some may therefore be extraneous and reducing whichever thread type they represent could improve performance at some slight level by freeing OS resources. But, it's hard to determine in general if that is so. 

    Yeah, that was probably more questions than I had when I first opened this post. Thanks in advance for those patient enough to answer.

    Art



    ------------------------------
    Art S. Kagel, President and Principal Consultant
    ASK Database Management Corp.
    www.askdbmgt.com
    ------------------------------

    Original Message