You can use the following onstat -g options to monitor virtual processors:
Use the onstat -g glo command to display information about each virtual processor that is currently running, as well as cumulative statistics for each virtual processor class. Figure 31 shows an example of the output from this option.
MT global info: sessions threads vps lngspins 1 15 8 0 Virtual processor summary: class vps usercpu syscpu total cpu 3 479.77 190.42 670.18 aio 1 0.83 0.23 1.07 pio 1 0.42 0.10 0.52 lio 1 0.27 0.22 0.48 soc 0 0.00 0.00 0.00 tli 0 0.00 0.00 0.00 shm 0 0.00 0.00 0.00 adm 1 0.10 0.45 0.55 opt 0 0.00 0.00 0.00 msc 1 0.28 0.52 0.80 adt 0 0.00 0.00 0.00 total 8 481.67 191.93 673.60 Individual virtual processors: vp pid class usercpu syscpu total 1 1776 cpu 165.18 40.50 205.68 2 1777 adm 0.10 0.45 0.55 3 1778 cpu 157.83 98.68 256.52 4 1779 cpu 156.75 51.23 207.98 5 1780 lio 0.27 0.22 0.48 6 1781 pio 0.42 0.10 0.52 7 1782 aio 0.83 0.23 1.07 8 1783 msc 0.28 0.52 0.80 tot 481.67 191.93 673.60
Use the onstat -g ioq option to determine whether you need to allocate additional AIO virtual processors. The command onstat -g ioq displays the length of the I/O queues under the column len. You can also see the maximum queue length (since the database server started) in the maxlen column. Each chunk serviced by the AIO virtual processors has one line in the onstat -g ioq output, identified by the gfd queue name. You can correlate the line in onstat -g ioq with the actual chunk because the chunks are in the same order as in the onstat -d output. For example, in the onstat -g ioq output in Figure 32, there are two gfd queues. The first gfd queue holds requests for root_chunk because it corresponds to the first chunk shown in the onstat -d output in Figure 32. Likewise, the second gfd queue holds requests for chunk1 because it corresponds to the second chunk in the onstat -d output.
If the database server has a mixture of raw devices and cooked files, the gfd queues correspond only to the cooked files in onstat -d output.
onstat -g ioq AIO I/O queues: q name/id len maxlen totalops dskread dskwrite dskcopy adt 0 0 0 0 0 0 0 msc 0 0 1 12 0 0 0 aio 0 0 4 89 68 0 0 pio 0 0 1 1 0 1 0 lio 0 0 1 17 0 17 0 kio 0 0 0 0 0 0 0 gfd 3 0 3 254 242 12 0 gfd 4 0 17 614 261 353 0 smoke% onstat -d Dbspaces address number flags fchunk nchunks flags owner name a1de1d8 1 1 1 1 N informix rootdbs a1df550 2 1 2 1 N informix space1 2 active, 2047 maximum Chunks address chk/dbs offset size free bpages flags pathname a1de320 1 1 0 75000 66447 PO- /ix/root_chunk a1df698 2 2 0 500 447 PO- /ix//chunk1 2 active, 2047 maximum
If the length of the I/O queue is growing, I/O requests are accumulating faster than the AIO virtual processors can process them. If the length of the I/O queue continues to show that I/O requests are accumulating, consider adding AIO virtual processors.
Use the onstat -g rea option to monitor the number of threads in the ready queue. If the number of threads in the ready queue is growing for a class of virtual processors (for example, the CPU class), you might have to add more of those virtual processors to your configuration. Figure 33 shows onstat -g rea output.
Ready threads: tid tcb rstcb prty status vp-class name 6 536a38 406464 4 ready 3cpu main_loop() 28 60cfe8 40a124 4 ready 1cpu onmode_mon 33 672a20 409dc4 2 ready 3cpu sqlexec