Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Yash asked what the "btscanner 0" thread seen in 'onstat -g act' and 'onstat -g rea' means on IDS 9.40 (HP-UX), and why it is sometimes ready versus running. Art Kagel explained that btscanner processes the index hot lists (viewable with 'onstat -C', e.g. hot/clean), waking when sessions flag indexes with deleted keys; any waking thread goes to the ready queue and moves to the active queue once a CPU VP is free. He added that these queues are very dynamic, so snapshots every 5 minutes are misleading — use 'onstat -g rea -r 1' / 'onstat -g act -r 1' and worry only if threads linger more than a couple of seconds; if btscanners are constantly busy, periodically rebuild the hottest indexes with a suitable FILLFACTOR. Yash accepted the explanation.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
Where could I find info on "btscanner 0" seen on the "onstat -g act" and
"onstat -g rea" output.
I would like to know more info and the difference, correlation as to when it
becomes ready and when it becomes running.
===
IBM Informix Dynamic Server Version 9.40.FC3 -- On-Line -- Up 4 days 00:51:03
-- 1285976 Kbytes
Ready threads: <<<<tid tcb rstcb prty status vp-class name
133 c00000003ddbfdb0 c00000003c41bdb8 1 ready 1cpu btscanner 0
=====
IBM Informix Dynamic Server Version 9.40.FC3 -- On-Line -- Up 4 days 16:20:59
-- 1285976 Kbytes
Running threads: <<<tid tcb rstcb prty status vp-class name
133 c00000003ddbfdb0 c00000003c41bdb8 1 running 3cpu btscanner 0
===
This question may be considered general for any IDS version, but my specific
version is IDS 9.40.FC3 running on HP-UX 11.11 on HP9000.
Thank you,
Yash
The onstat -C report and its options report on the btscanner threads and
the table/index hot lists that it processes. As to when it runs, it runs
when there is sufficient work in the hot lists for it to process. When the
thread finds no more work it sleeps and wakes periodically to check the
lists again. Sessions place indexes on the hot list when they encounter
deleted keys in an index. When any thread in Informix wakes the thread
scheduler places the thread in the ready queue (onstat -g rea) and as soon
as a CPU VP is available it is moved to the active queue (onstat -g act)
where it remains until it finishes what it has to do, has to wait for a
resource (lock, memory latch, critical section condition, etc.) at which
point it is put to sleep for a period of time.
Art
Art S. Kagel, Principal Consultant
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Mon, Oct 7, 2013 at 2:02 PM, YASH DAVE <ydave@shoppersdrugmart.ca> wrote:
> Hi,
>
> Where could I find info on "btscanner 0" seen on the "onstat -g act" and
> "onstat -g rea" output.
>
> I would like to know more info and the difference, correlation as to when
> it
> becomes ready and when it becomes running.
>
> ===
> IBM Informix Dynamic Server Version 9.40.FC3 -- On-Line -- Up 4 days
> 00:51:03
> -- 1285976 Kbytes
>
> Ready threads: <<<<> tid tcb rstcb prty status vp-class name
> 133 c00000003ddbfdb0 c00000003c41bdb8 1 ready 1cpu btscanner 0
> =====
> IBM Informix Dynamic Server Version 9.40.FC3 -- On-Line -- Up 4 days
> 16:20:59
> -- 1285976 Kbytes
>
> Running threads: <<<> tid tcb rstcb prty status vp-class name
> 133 c00000003ddbfdb0 c00000003c41bdb8 1 running 3cpu btscanner 0
> ===
>
> This question may be considered general for any IDS version, but my
> specific
> version is IDS 9.40.FC3 running on HP-UX 11.11 on HP9000.
>
> Thank you,
>
> Yash
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11c3eee4d6350704e82a9197
Thank you Art for the quick response and great answer. You are a great help as
always. I can understand this output better now.
I did check the "onstat -C hot", "onstat -C clean" as you had mentioned.
I have two more related questions?
[1]
If I am capturing "onstat -g rea" and
"onstat -g act" every five minutes for monitoring
and seeing in different 5 min. time captures that there are "ready" threads,
but I don't get as many "running" threads,
Would it be safe assumption that those "ready" become "running" and
those "running" complete quickly before a capture gets to capture it?
[2] If 7 days ago, I captured less "Ready" and "Running" than today, would it
be safe to assume that my app. performed more deletion that btscanner has to
do more cleaning?
Thank you,
Yash
Yash:
onstat -g rea and -g act are VERY dynamic. If sessions are staying ineither queue for more than a couple of seconds at a time there is usually a
problem (OK except during the processing of very complex queries). When I
want to monitor how well a server is moving data out to users and get a
quick sense of whether there are any bottlenecks in the CPU VPs, I will run
onstat -g rea -r 1 and I want to see that no session stays in the readyqueue for more than two iterations meaning that it was waiting less than 2
seconds before being granted a CPU Vp to run on. Similarly, I will also
run onstat -g act -r 1 |grep sqlexec to make sure that I'm not seeing any
sessions that are spinning CPU for more than a few seconds (in an OLTP
environment anyway). If your btscanner threads are always active, then you
may want to schedule the indexes that are always hottest for manual
rebuilds periodically with an appropriate FILLFACTOR set just to free up
the btscanners so they can optimizer the less active indexes better.
Art
Art S. Kagel, Principal Consultant
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Mon, Oct 7, 2013 at 2:29 PM, YASH DAVE <ydave@shoppersdrugmart.ca> wrote:
> Thank you Art for the quick response and great answer. You are a great
> help as
> always. I can understand this output better now.
>
> I did check the "onstat -C hot", "onstat -C clean" as you had mentioned.
>
> I have two more related questions?
>
> [1]
>
> If I am capturing "onstat -g rea" and
>
> "onstat -g act" every five minutes for monitoring
>
> and seeing in different 5 min. time captures that there are "ready"
> threads,
>
> but I don't get as many "running" threads,
>
> Would it be safe assumption that those "ready" become "running" and
>
> those "running" complete quickly before a capture gets to capture it?
>
> [2] If 7 days ago, I captured less "Ready" and "Running" than today, would
> it
> be safe to assume that my app. performed more deletion that btscanner has
> to
> do more cleaning?
>
> Thank you,
>
> Yash
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11c34e6cf4036204e82bb8f9
Thank you Art.
I believe the active (running) threads also don't run too long, they just get
captured by the monitoring as a coincidence. I will monitor for the behaviour
that you explained to ensure the active threads of btscanner don't run too
long.
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.