Under some conditions, a blocking checkpoint may get hung and
never complete if some sort of parallel index build is happening
concurrently. The index build may be just a create index
statement, or a set object enabled.
The checkpoint hang occurs because the main_loop thread is
unable to flush all the dirty buffers required for that
checkpoint interval. You may see it in a stack that looks like
this:
mt_yield
ckpt_dskflush
checkpoint
main_loop
th_init_initgls
startup
So main_loop keeps trying to flush the required buffers, but
there will be some number of buffers that can be seen in onstat
-b output that will be flagged as dirty and they will be xlocked
and the thread that owns those buffers will be waiting on the
checkpoint condition.
Here is onstat -b output showing 2 dirty buffers (the "flgs"
field will have the presence of 1 in it's value) they are
xlocked (so "xflgs" field will be = "80") and both these buffers
are owned by the same thread. Following the onstat -b output
will be the stack trace of that thread along with it's onstat -g
ath output showing it waiting on the checkpoint condition.
onstat -b
IBM Informix Dynamic Server Version 12.10.FC12 -- On-Line (CKPT
REQ) -- Up 02:36:25 -- 545336 Kbytes
Blocked:CKPT
Buffers
address userthread flgs pagenum
memaddr nslots pgflgs xflgs owner waitlist
Buffer pool page size: 2048
5976e758 0 807 8:1415 5a9fa000
21 10 80 4b8a3888 0
59774ab8 0 807 8:1574 5aa49800
20 10 80 4b8a3888 0
2 modified, 90000 total, 131072 hash buckets, 2048 buffer size
onstat -g ath | grep 4b8a3888
Threads:
tid tcb rstcb prty status
vp-class name
92 4c663648 4b8a3888 1 cond wait cp
8cpu xchg_1.0
onstat -g stk 92
yield_processor_mvp
mt_fast_wait
critwait
critenter
btusearch
btadditem
btmakeroot
close_btmrg
producer_thread
startup
The session for that thread was running the following sql
Current SQL statement (4) :
create index t1_idx on t1(c1,c2,c3,c4,c5) using btree in
dbsidx |
