TCP poll listeners: run as a NET or CPU virtual process?

At the recent Avnet Informix Community Event, Jon Ritson did an excellent presentation about hot topics including performance tuning. Many of the tips were not new but one that got me thinking was his suggestion that TCP poll threads should run on a network virtual processor (VP) rather than a CPU one. This seemed to go against previous advice I’ve read elsewhere.

Jon went on to say that running the poll thread in this way allowed them to be scheduled in a way that took up fewer resources than if they ran on a CPU VP. In the latter case we would expect the response time would be marginally better but it would use more processing power for not much gain. At least, I think that’s what he said.

The job of TCP poll threads is to listen for new data on existing connections and notify other threads. I think what’s being suggested here is that if it takes a few clock cycles longer for the database engine to detect that your SQL statement is waiting, it might not matter too much

So what to do? Refer to the IBM documentation and do some experimenting! One thing I noticed is that the 11.50 documentation is slightly more clear about it than the version 10.00 docs were:

Poll threads can run either on CPU virtual processors or on network virtual processors. In general, and particularly on a single-processor computer, poll threads run more efficiently on CPU virtual processors. This might not be true, however, on a multiprocessor computer with many remote clients.

And under a note labelled important (which was only labelled note in the 10.00 documentation) it adds:

TCP connections must only be in network virtual processors, and you must only have the minimum required to maintain responsiveness.

There’s a second statement there: have only the minimum required to maintain responsiveness. This again seems to be suggesting they use up resources.

You can monitor thread CPU usage with onstat -g cpu. Compare the output below: the first is from an idle instance running for one minute with the poll thread running on a NET VP; the second has it running on a CPU VP. There are 222 wake ups against 1310. I guess 222 wake ups is enough to “maintain responsiveness”.

Net VP:

informix@ids1150srvr[demo_on]:/opt/IBM/informix/etc$ onstat -g cpu

IBM Informix Dynamic Server Version 11.50.UC4DE -- On-Line -- Up 00:01:00 -- 22556 Kbytes

Thread CPU Info:
tid name vp Last Run CPU Time #scheds status
2 lio vp 0 6lio* 11/13 10:57:24 0.0180 14 IO Idle
3 pio vp 0 7pio* 11/13 10:57:22 0.1270 3 IO Idle
4 aio vp 0 8aio* 11/13 10:58:07 0.1504 338 IO Idle
5 msc vp 0 9msc* 11/13 10:57:19 0.1838 5 IO Idle
6 aio vp 1 10aio* 11/13 10:57:24 0.1025 41 IO Idle
7 main_loop() 1cpu 11/13 10:58:13 0.0059 83 sleeping secs: 1
8 soctcppoll 11soc* 11/13 10:58:13 53.9641 222 running
9 soctcplst 1cpu* 11/13 10:57:19 0.0053 6 sleeping forever
10 soctcplst 1cpu* 11/13 10:57:19 0.0053 5 sleeping forever
11 flush_sub(0) 1cpu 11/13 10:58:13 0.0001 56 sleeping secs: 1
12 flush_sub(1) 1cpu 11/13 10:58:13 0.0001 56 sleeping secs: 1
13 flush_sub(2) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
14 flush_sub(3) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
15 flush_sub(4) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
16 flush_sub(5) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
17 flush_sub(6) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
18 flush_sub(7) 1cpu 11/13 10:58:13 0.0001 54 sleeping secs: 1
19 aio vp 2 12aio* 11/13 10:57:24 0.1048 4 IO Idle
20 aslogflush 1cpu 11/13 10:58:13 0.0002 53 sleeping secs: 1
21 btscanner_0 1cpu 11/13 10:57:54 0.0077 15 sleeping secs: 1
37 onmode_mon 1cpu* 11/13 10:58:13 0.0003 52 sleeping secs: 1
38 periodic 1cpu 11/13 10:58:13 0.0013 54 sleeping secs: 1
44 dbScheduler 1cpu* 11/13 10:57:24 0.0394 203 sleeping secs: 251
45 dbWorker1 1cpu 11/13 10:57:24 0.0051 73 sleeping forever
46 dbWorker2 1cpu 11/13 10:57:24 0.0547 96 sleeping forever

CPU VP:

informix@ids1150srvr[demo_on]:/opt/IBM/informix/etc$ onstat -g cpu

IBM Informix Dynamic Server Version 11.50.UC4DE -- On-Line -- Up 00:01:00 -- 22556 Kbytes

Thread CPU Info:
tid name vp Last Run CPU Time #scheds status
2 lio vp 0 6lio* 11/13 10:55:36 0.0206 11 IO Idle
3 pio vp 0 7pio* 11/13 10:55:34 0.1220 3 IO Idle
4 aio vp 0 8aio* 11/13 10:56:19 0.2182 172 IO Idle
5 msc vp 0 9msc* 11/13 10:55:32 0.2904 3 IO Idle
6 aio vp 1 10aio* 11/13 10:55:36 0.1028 53 IO Idle
7 main_loop() 1cpu 11/13 10:56:26 0.0068 115 sleeping secs: 1
8 soctcppoll 1cpu* 11/13 10:56:26 54.0073 1310 running
9 soctcplst 1cpu* 11/13 10:55:32 0.0042 7 sleeping forever
10 soctcplst 1cpu* 11/13 10:55:32 0.0038 7 sleeping forever
11 flush_sub(0) 1cpu 11/13 10:56:26 0.0001 57 sleeping secs: 1
12 flush_sub(1) 1cpu 11/13 10:56:26 0.0001 57 sleeping secs: 1
13 flush_sub(2) 1cpu 11/13 10:56:26 0.0001 54 sleeping secs: 1
14 flush_sub(3) 1cpu 11/13 10:56:26 0.0001 54 sleeping secs: 1
15 flush_sub(4) 1cpu 11/13 10:56:26 0.0001 54 sleeping secs: 1
16 flush_sub(5) 1cpu 11/13 10:56:26 0.0001 54 sleeping secs: 1
17 flush_sub(6) 1cpu 11/13 10:56:26 0.0001 54 sleeping secs: 1
18 flush_sub(7) 1cpu 11/13 10:56:26 0.0035 55 sleeping secs: 1
19 aio vp 2 11aio* 11/13 10:55:36 0.0964 21 IO Idle
20 aslogflush 1cpu 11/13 10:56:26 0.0002 53 sleeping secs: 1
21 btscanner_0 1cpu 11/13 10:56:25 0.0079 17 sleeping secs: 24
37 onmode_mon 1cpu* 11/13 10:56:26 0.0003 53 sleeping secs: 1
38 periodic 1cpu 11/13 10:56:26 0.0012 55 sleeping secs: 1
44 dbScheduler 1cpu* 11/13 10:55:36 0.0289 305 sleeping secs: 250
45 dbWorker1 1cpu 11/13 10:55:36 0.0066 93 sleeping forever
46 dbWorker2 1cpu 11/13 10:55:36 0.0543 119 sleeping forever

I am not sure that the CPU times above are too important since top showed the system to be more or less idle during both tests.

I haven’t been able to benchmark this in a production system and it’s unlikely I’ll be able to. But I would like to say “thanks for the top tip, Jon”.

Advertisements

One Comment on “TCP poll listeners: run as a NET or CPU virtual process?”

  1. Tim Steele says:

    The note about ensuring you have just enough poll threads and not too much is what I have seen in a number of environments to be best. Having too many poll threads is overkill. A poll thread today can handle alot more connections then they used to say a decade ago.
    And JJ is very knowledgeable.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s