load distribution to kio vps

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mohit - 28 Jul 2008 20:45 GMT

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

Reply to this Message

Art Kagel - 28 Jul 2008 21:36 GMT

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

> IDS: 11.10.FC2
>
[quoted text clipped - 36 lines]
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list

Signature

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.

Reply to this Message

Mohit - 31 Jul 2008 17:07 GMT

> The KIO threads each run in one of the CPU VPs and ONLY service IO requests
> from threads running in that specific CPU VP.
[quoted text clipped - 65 lines]
>
> - Show quoted text -

When number of CPU vps are increased or a table fragments are
increased do we also need to increase PC_HASHSIZE, DS_HASHSIZE or
DD_HASHSIZE. I see mutex waits on "hash PN_ID". I don't really
understand the relation

Reply to this Message