Re: AW: NETTYPE

AHHHH! NEVER put TCP listeners in CPU VPs and NEVER put shared memory poll threads in NET VPs. Either will burn CPU time, slow down response time, and cause the machine to do little else but poll for Informix connections & requests. Also unless you have at least 6 CPU VPs, the configuration below will allocate any poll/listener threads that exceed the number of CPU VPs to NET VPs . However, since you have entered the TCP NETTYPE first, if you say have 4 CPU VPs that would be the worst case as all 4 CPU VPs would be running TCP poll threads and there would be 2 NET VPs running shared memory poll threads. Search the forum and/or CDI archives for a longer more detailed explaination of why the is REALLY BAD. Alternate: NETTYPE ipcshm,4,64,CPU #One shm poll thr. for EVERY CPU VP (assuming 4 CPU VP)! NETTYPE tlitcp,3,96,NET #A reasonable but small number of NET VPs w/TCPlistener Art S. Kagel ----- Original Message ----- From: Mueller Thomas <Thomas.Mueller@szm.de> At: 2/21 5:00 > Hello, > > yes it's posssible to put several NETTYPEs in one file. > I also have two entries in one file: > NETTYPE tlitcp,4,96,CPU # Configure poll thread(s) for nettype > NETTYPE ipcshm,2,64,CPU # Configure poll thread(s) for nettype> > ciao, > Thomas > > -----Ursprungliche Nachricht----- > Von: EDMUND LAJARA [mailto:edmund.lajara@nokia.com] > Gesendet: Freitag, 21. Februar 2003 09:34 > An: ids@iiug.org > Betreff: NETTYPE [453] > > > I would just like to clarify on the setting of NETTYPE on the ONCONFIG. Can I > put several NETTYPEs on the one file, like: > > NETTYPE ipcshm,3,,CPU > NETTYPE soctcp,,20,NET> > because I use the DBSERVERNAME and the DBSERVERALIASES with different > connections? I wasn't so clear to me in the manual if I could have more than one > entry (not like the VPCLASS where it explicitly says you can have several > entries on the one onconfig). In case it is not possible, which one do I put for > the NETTYPE?

Art, Help me understand why we never want to put TCP poll threads on CPU VP's. I might well agree that we'd not want to put any poll threads on CPU VP's, since we want CPU VP's pretty much exclusively doing CPU VP kind of stuff, rather than listening for connections. What I don't understand is why it is any better to have a shared memory poll thread on the CPU VP than it is to have a TCP poll thread. My understanding of the connection process is that the VP listening for whichever type of connection you're coming in on (TCP or shared memory) picks up the request, it forces the creation of an sqlexec thread, and then hands off the session to the sqlexec thread, then goes back to listening. I understand from the documentation (and from some real life experiences that others I know have had) that the CPU VP's make faster connections, but given that the functionality of the poll threads is the same, even that doesn't make much theoretical sense. Is it because the CPU VP's have fewer yield points than the NET VP's? I'm not sure where/why you'd yield in the connection process anyway, so that doesn't make much sense, but it's the only thing I can think of. In Edmund's case, given that the existing configuration has 4 tli poll threads, my assumption is that most users are connecting via TCP, so I don't know that I'd decrease the number of VP's handling those connections. I'd probably go with something like this: NETTYPE ipcshm 1,50,NET NETTYPE tlitcp 1,200,CPU NETTYPE tlitcp 3,200,NET I'm guessing that the only shared memory connections made for this instance are maintenance ones (and the additional shared memory listener is the result of earlier misunderstandings -- I've done that in the past), so you'd only need 1 poll thread, and it doesn't have to be lightning fast. The 1 TCP poll thread that listens on the CPU VP would handle most of the connections, and do so more quickly than a NET VP would, but in cases where the instance was slammed, the NET TCP poll threads would pick up the slack at a slightly slower rate. Alternatively, increase the tlitcp/NET VP threads by 1, and get rid of the CPU VP poll threads altogether. If I'm off base, please let me, and the rest of us know... I know that there are TONS of misunderstandings about the poll threads and VP classes out there... Thanks. Dan Michaelis 813.978.6534 (office) 813.303.3225 (pager) dan.michaelis@verizon.com "ART KAGEL, ...." <KAGEL@bloomberg. To: ids@iiug.org net> cc: Sent by: Subject: Re: AW: NETTYPE [464] forum.subscriber@ iiug.org 02/21/2003 08:18 AM AHHHH! NEVER put TCP listeners in CPU VPs and NEVER put shared memory poll threads in NET VPs. Either will burn CPU time, slow down response time, and cause the machine to do little else but poll for Informix connections & requests. Also unless you have at least 6 CPU VPs, the configuration below will allocate any poll/listener threads that exceed the number of CPU VPs to NET VPs . However, since you have entered the TCP NETTYPE first, if you say have 4 CPU VPs that would be the worst case as all 4 CPU VPs would be running TCP poll threads and there would be 2 NET VPs running shared memory poll threads. Search the forum and/or CDI archives for a longer more detailed explaination of why the is REALLY BAD. Alternate: NETTYPE ipcshm,4,64,CPU #One shm poll thr. for EVERY CPU VP (assuming 4 CPU VP)! NETTYPE tlitcp,3,96,NET #A reasonable but small number of NET VPs w/TCPlistener Art S. Kagel ----- Original Message ----- From: Mueller Thomas <Thomas.Mueller@szm.de> At: 2/21 5:00 > Hello, > > yes it's posssible to put several NETTYPEs in one file. > I also have two entries in one file: > NETTYPE tlitcp,4,96,CPU # Configure poll thread(s) for nettype > NETTYPE ipcshm,2,64,CPU # Configure poll thread(s) for nettype> > ciao, > Thomas > > -----Ursprungliche Nachricht----- > Von: EDMUND LAJARA [mailto:edmund.lajara@nokia.com] > Gesendet: Freitag, 21. Februar 2003 09:34 > An: ids@iiug.org > Betreff: NETTYPE [453] > > > I would just like to clarify on the setting of NETTYPE on the ONCONFIG. Can I > put several NETTYPEs on the one file, like: > > NETTYPE ipcshm,3,,CPU > NETTYPE soctcp,,20,NET> > because I use the DBSERVERNAME and the DBSERVERALIASES with different > connections? I wasn't so clear to me in the manual if I could have more than one > entry (not like the VPCLASS where it explicitly says you can have several > entries on the one onconfig). In case it is not possible, which one do I put for > the NETTYPE?

Don't confuse the poll thread with the listener thread. The listener thread accepts a connection and spawns the sqlexec thread. The poll thread looks for network/sharedmemory-IO completion. When the poll thread is TCP and running on the CPUVP, it issues a short select in a loop every 'x' thread switches. If the TCP poll thread is in a netvp, then it blockes on a select() call. If the IPCSHM poll thread is in the cpuvp, then it uses semaphores to see if a new message has been placed in shared memory. "dan.michael...." <dan.michaelis@ve To: ids@iiug.org rizon.com> cc: Sent by: Subject: Re: AW: NETTYPE [468] forum.subscriber@ iiug.org 02/21/2003 01:08 PM Art, Help me understand why we never want to put TCP poll threads on CPU VP's. I might well agree that we'd not want to put any poll threads on CPU VP's, since we want CPU VP's pretty much exclusively doing CPU VP kind of stuff, rather than listening for connections. What I don't understand is why it is any better to have a shared memory poll thread on the CPU VP than it is to have a TCP poll thread. My understanding of the connection process is that the VP listening for whichever type of connection you're coming in on (TCP or shared memory) picks up the request, it forces the creation of an sqlexec thread, and then hands off the session to the sqlexec thread, then goes back to listening. I understand from the documentation (and from some real life experiences that others I know have had) that the CPU VP's make faster connections, but given that the functionality of the poll threads is the same, even that doesn't make much theoretical sense. Is it because the CPU VP's have fewer yield points than the NET VP's? I'm not sure where/why you'd yield in the connection process anyway, so that doesn't make much sense, but it's the only thing I can think of. In Edmund's case, given that the existing configuration has 4 tli poll threads, my assumption is that most users are connecting via TCP, so I don't know that I'd decrease the number of VP's handling those connections. I'd probably go with something like this: NETTYPE ipcshm 1,50,NET NETTYPE tlitcp 1,200,CPU NETTYPE tlitcp 3,200,NET I'm guessing that the only shared memory connections made for this instance are maintenance ones (and the additional shared memory listener is the result of earlier misunderstandings -- I've done that in the past), so you'd only need 1 poll thread, and it doesn't have to be lightning fast. The 1 TCP poll thread that listens on the CPU VP would handle most of the connections, and do so more quickly than a NET VP would, but in cases where the instance was slammed, the NET TCP poll threads would pick up the slack at a slightly slower rate. Alternatively, increase the tlitcp/NET VP threads by 1, and get rid of the CPU VP poll threads altogether. If I'm off base, please let me, and the rest of us know... I know that there are TONS of misunderstandings about the poll threads and VP classes out there... Thanks. Dan Michaelis 813.978.6534 (office) 813.303.3225 (pager) dan.michaelis@verizon.com "ART KAGEL, ...." <KAGEL@bloomberg. To: ids@iiug.org net> cc: Sent by: Subject: Re: AW: NETTYPE [464] forum.subscriber@ iiug.org 02/21/2003 08:18 AM AHHHH! NEVER put TCP listeners in CPU VPs and NEVER put shared memory poll threads in NET VPs. Either will burn CPU time, slow down response time, and cause the machine to do little else but poll for Informix connections & requests. Also unless you have at least 6 CPU VPs, the configuration below will allocate any poll/listener threads that exceed the number of CPU VPs to NET VPs . However, since you have entered the TCP NETTYPE first, if you say have 4 CPU VPs that would be the worst case as all 4 CPU VPs would be running TCP poll threads and there would be 2 NET VPs running shared memory poll threads. Search the forum and/or CDI archives for a longer more detailed explaination of why the is REALLY BAD. Alternate: NETTYPE ipcshm,4,64,CPU #One shm poll thr. for EVERY CPU VP (assuming 4 CPU VP)! NETTYPE tlitcp,3,96,NET #A reasonable but small number of NET VPs w/TCPlistener Art S. Kagel ----- Original Message ----- From: Mueller Thomas <Thomas.Mueller@szm.de> At: 2/21 5:00 > Hello, > > yes it's posssible to put several NETTYPEs in one file. > I also have two entries in one file: > NETTYPE tlitcp,4,96,CPU # Configure poll thread(s) for nettype > NETTYPE ipcshm,2,64,CPU # Configure poll thread(s) for nettype> > ciao, > Thomas > > -----Ursprungliche Nachricht----- > Von: EDMUND LAJARA [mailto:edmund.lajara@nokia.com] > Gesendet: Freitag, 21. Februar 2003 09:34 > An: ids@iiug.org > Betreff: NETTYPE [453] > > > I would just like to clarify on the setting of NETTYPE on the ONCONFIG. Can I > put several NETTYPEs on the one file, like: > > NETTYPE ipcshm,3,,CPU > NETTYPE soctcp,,20,NET> > because I use the DBSERVERNAME and the DBSERVERALIASES with different > connections? I wasn't so clear to me in the manual if I could have more than one > entry (not like the VPCLASS where it explicitly says you can have several > entries on the one onconfig). In case it is not possible, which one do I put for > the NETTYPE?