Re: Cpu vp usage

On Aug 17, 1:02 pm, "Art S. Kagel" <art.ka...@gmail.com> wrote: > On Aug 17, 4:31 am, "malcolm.iiug" <mali...@btopenworld.com> wrote: > > > > > AIX 5.3 > > > IDS 10.00.UC5 > > > We have had reports of slow performance so I have been monitoring the > > system. When I check with onstat -g glo I see that the cpu vp usage is > > skewed towards the 1st cpu vp. In the latest example cpu vp 1 has used > > ~4000 cpu seconds, cpu vp 2 has used ~2000 cpu seconds, cpu vp 3 has used > > ~1000 seconds, cpu vp 4 has used ~300 cpu seconds, cpu vp 5 has used ~170 > > cpu seconds, and cpu cp 6 has only used ~60 cpu seconds. But when I monitor > > the system with AIX monitoring tools I am seeing long periods of time when > > one of the cpus is running at 100% utilisation. > > > Should I be looking at the AIX tuning yet? Or is there something I can do at > > the IDS level first? > > > Regards > > > Malcolm > > Two known causes: > > > - This one I just discovered when it hit us. With all current ESQL > (and 4GL) releases, if the client is compiled with POSIX threads (also > SOLaris threads on Sun) as opposed to non-threaded or threaded using > DCE threads, and uses a TCP connection, for some reason only the first > TCP listener ever does any work, there's no load balancing across the > NET VPS (or presumably CPU VPs if the TCP polling's going on in CPU > VPs). New bug reported this week, and IBM's looking into it. > > Art S. Kagel This 2nd item isn't 100% correct. When you have a threaded esql app (compiled with -thread) using a non-DCE thread package and it uses a shared memory connection, the application will always pick the 1st shared memory poll thread (until it fills it's user limit) and it will then spill over to subsequent shared memory poll threads. Usually, shared memory client applications, when you have multiple shared memory poll threads, attempt to randomly pick which poll thread to use to distribute work, and in this particular case, it's not working. This is only for shared memory connections though, not TCP.

On Aug 20, 9:35 am, jpren...@yahoo.com wrote: > On Aug 17, 1:02 pm, "Art S. Kagel" <art.ka...@gmail.com> wrote: > > > > > On Aug 17, 4:31 am, "malcolm.iiug" <mali...@btopenworld.com> wrote: > > > > AIX 5.3 > > > > IDS 10.00.UC5 > > > > We have had reports of slow performance so I have been monitoring the > > > system. When I check with onstat -g glo I see that the cpu vp usage is > > > skewed towards the 1st cpu vp. In the latest example cpu vp 1 has used > > > ~4000 cpu seconds, cpu vp 2 has used ~2000 cpu seconds, cpu vp 3 has used > > > ~1000 seconds, cpu vp 4 has used ~300 cpu seconds, cpu vp 5 has used ~170 > > > cpu seconds, and cpu cp 6 has only used ~60 cpu seconds. But when I monitor > > > the system with AIX monitoring tools I am seeing long periods of time when > > > one of the cpus is running at 100% utilisation. > > > > Should I be looking at the AIX tuning yet? Or is there something I can do at > > > the IDS level first? > > > > Regards > > > > Malcolm > > > Two known causes: > > > - This one I just discovered when it hit us. With all current ESQL > > (and 4GL) releases, if the client is compiled with POSIX threads (also > > SOLaris threads on Sun) as opposed to non-threaded or threaded using > > DCE threads, and uses a TCP connection, for some reason only the first > > TCP listener ever does any work, there's no load balancing across the > > NET VPS (or presumably CPU VPs if the TCP polling's going on in CPU > > VPs). New bug reported this week, and IBM's looking into it. > > > Art S. Kagel > > This 2nd item isn't 100% correct. When you have a threaded esql app > (compiled with -thread) using a non-DCE thread package and it uses a > shared memory connection, the application will always pick the 1st > shared memory poll thread (until it fills it's user limit) and it will > then spill over to subsequent shared memory poll threads. Usually, > shared memory client applications, when you have multiple shared > memory poll threads, attempt to randomly pick which poll thread to use > to distribute work, and in this particular case, it's not working. > This is only for shared memory connections though, not TCP. Just checked with our DBAs, Jean is correct, the threading load balance problem affects shared memory connections not TCP connections. I had misunderstood what I was told last week. Also note that this was recognized here as a problem on a small number of servers that are using NET VPs for shared memory polling - a practice I recommend against. Art S. Kagel