load distribution to kio vps

IDS: 11.10.FC2 I am seeing slow performance and when I look at onstat -g iov I see that out of 28 kio vp only 2 are super busy. Below is the snapshot (first 2 have 107 and 136 io/s): kio 0 i 107.7 27388858 15142656 12246202 0 45203359 0.6 0 0 kio 1 s 136.3 34657932 17039436 17618496 0 58688558 0.6 0 0 kio 2 i 51.9 13185483 6749584 6435899 0 16702456 0.8 0 0 kio 3 i 35.0 8892769 3926884 4965885 0 9802816 0.9 0 0 kio 4 b 61.1 15527901 8149519 7378382 0 20701725 0.8 0 0 kio 5 i 29.8 7566669 3218713 4347956 0 8108678 0.9 0 0 kio 6 s 46.6 11841344 5811843 6029501 0 14454630 0.8 0 0 kio 7 b 26.6 6772413 2641624 4130789 0 7476973 0.9 0 0 kio 8 i 43.4 11041033 5137391 5903642 0 13220738 0.8 0 0 kio 9 i 32.8 8343696 3752504 4591192 0 9292855 0.9 0 0 kio 10 s 31.8 8090050 3505154 4584896 0 8745305 0.9 0 0 VPCLASS settings are cpu,num=28,aff=4-31,noage I don't really understand why would the load not get distributed or is that really a problem why I could be seeing the performance degradation. I looked at the SQLTRACE also and came up with only one table that might be slowing down the performance. But, still output of onstat -g iov is rather unusual than I am used to seeing. Anysuggestion on where I should look at the reason of this anomaly

The KIO threads each run in one of the CPU VPs and ONLY service IO requests from threads running in that specific CPU VP. The only way to spread the load better between the CPU VPs is to properly tune your listener/poll threads (NETTYPE). If you are using mostly TCP connections then the listener threads should be running on one or more NET VPs (so that a maximum of 200 connections are configured or actually used per NET VP with one of two SHM poll threads configured in CPU VPs. If you are using shared memory mostly, you should configure an SHM poll thread in EVERY CPU VP with enough connections per thread so that the product of the number of connections and the number of threads is at least the maximum number of concurrent SHM connections. I've posted the reasons for this many times. You can find one such explanation in the Informix FAQ. Art On Mon, Jul 28, 2008 at 3:45 PM, Mohit <mohitanchlia@gmail.com> wrote: > IDS: 11.10.FC2 > > I am seeing slow performance and when I look at onstat -g iov I see > that out of 28 kio vp only 2 are super busy. Below is the snapshot > (first 2 have 107 and 136 io/s): > kio 0 i 107.7 27388858 15142656 12246202 0 45203359 > 0.6 0 0 > kio 1 s 136.3 34657932 17039436 17618496 0 58688558 > 0.6 0 0 > kio 2 i 51.9 13185483 6749584 6435899 0 16702456 > 0.8 0 0 > kio 3 i 35.0 8892769 3926884 4965885 0 9802816 > 0.9 0 0 > kio 4 b 61.1 15527901 8149519 7378382 0 20701725 > 0.8 0 0 > kio 5 i 29.8 7566669 3218713 4347956 0 8108678 > 0.9 0 0 > kio 6 s 46.6 11841344 5811843 6029501 0 14454630 > 0.8 0 0 > kio 7 b 26.6 6772413 2641624 4130789 0 7476973 > 0.9 0 0 > kio 8 i 43.4 11041033 5137391 5903642 0 13220738 > 0.8 0 0 > kio 9 i 32.8 8343696 3752504 4591192 0 9292855 > 0.9 0 0 > kio 10 s 31.8 8090050 3505154 4584896 0 8745305 > 0.9 0 0 > > VPCLASS settings are cpu,num=28,aff=4-31,noage > > I don't really understand why would the load not get distributed or is > that really a problem why I could be seeing the performance > degradation. I looked at the SQLTRACE also and came up with only one > table that might be slowing down the performance. But, still output of > onstat -g iov is rather unusual than I am used to seeing. Any> suggestion on where I should look at the reason of this anomaly > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.