i/o polling process count

i/o polling process count specifies the maximum number of processes that Adaptive Server can run before the scheduler checks for disk and/or network I/O completions. Tuning i/o polling process count affects both the response time and throughput of Adaptive Server.

Adaptive Server checks for disk or network I/O completions:

• If the number of tasks run since the last time Adaptive Server checked for I/O completions equals the value for i/o polling process count, and

• At every Adaptive Server clock tick.

As a general rule, increasing the value of i/o polling process count increases throughput for applications that generate a lot of disk and network I/O. Conversely, decreasing the value improves process response time in these applications, possibly at the risk of lowering throughput.

If your applications create both I/O and CPU-bound tasks, tuning i/o polling process count to a low value (1–2) ensures that I/O-bound tasks get access to CPU cycles.

For OLTP applications (or any I/O-bound application with user connections and short transactions), tuning i/o polling process count to a value in the range of 20–30 may increase throughput, but may also increase response time.

When tuning i/o polling process count, consider three other parameters:

• sql server clock tick length, which specifies the duration of Adaptive Server’s clock tick in microseconds. See “sql server clock tick length”.

• time slice, which specifies the number of clock ticks the Adaptive Server’s scheduler allows a user process to run. See “time slice”.

• cpu grace time, which specifies the maximum amount of time (in clock ticks) a user process can run without yielding the CPU before Adaptive Server preempts it and terminates it with a timeslice error. See “cpu grace time”.

Use sp_sysmon to determine the effect of changing the i/o polling process count parameter. See the Performance and Tuning Guide for more information.

Copyright © 2005. Sybase Inc. All rights reserved.

View this book as PDF