9.40 - B-tree scanner
Hi, i am very frustrated with the new 9.40 "feature" named B-tree scanner: After upgrading 9.30 to 9.40 i found out, that we have ~ 30x (!!) more i/o requests with 9.40 as with 9.30. I have experimented with rangesize and threshold, but no change. Is there a chance to stop this (when i stop the B-tree scanner the index grows, not really a solution) or is the only solution downgrade to 9.30 ? We use 9.40UC5 on Solaris 7. Regards, try_and_err
"try_and_err" <try_and_err@web.de> wrote in message news:fbcbd702.0411210152.46b7f76f@posting.google.com... > Hi, > > i am very frustrated with the new 9.40 "feature" named B-tree scanner: > After upgrading 9.30 to 9.40 i found out, that we have ~ 30x (!!) more > i/o requests with 9.40 as with 9.30. > I have experimented with rangesize and threshold, but no change. > Is there a chance to stop this (when i stop the B-tree scanner the index > grows, not really a solution) or is the only solution downgrade to 9.30 ? http://www.informix.co.uk/btscanner.htm
Yes, i know this website, but no success.
For example:
When i set rangesize to 100, the i/o's are more highly (!).
Here are some outputs:
iostat -cx
-----------
extended device statistics cpu
device r/s w/s kr/s kw/s wait actv svc_t %w %b us sy wt id
sd17 1031.7 0.0 2063.4 0.0 0.0 0.3 0.3 0 34
sd52 1030.7 0.0 2061.4 0.0 0.0 0.4 0.4 1 36
onstat -C all
--------------Index Hot List
==============
Current Item 1 List Created 22:26:21
List Size 3 List expires in 81 sec
Hit Threshold 500 Range Scan Threshold -1
Partnum Key Hits
0x003001FD 1 1043 *
0x00300217 1 552
0x00300216 1 501
Index Cleaned Statistics
=========================
Partnum Key Dirty Hits Clean Time Pg Examined Items Del
Pages/Sec
0x003001fd 1 C 0 4995 13953182 5510
2793.43
onstat -C clean (only currently cleaned index; 10x with sleep 1)
-----------------------------------------------------------------
0x003001fd 1 C 0 4995 13953135 5510
2793.42
0x003001fd 1 C 0 4995 13955235 5510
2793.84
0x003001fd 1 C 0 4995 13957357 5510
2794.27
0x003001fd 1 C 0 4995 13959435 5510
2794.68
0x003001fd 1 C 0 4995 13961433 5510
2795.08
0x003001fd 1 C 0 4995 13963314 5510
2795.46
0x003001fd 1 C 0 4995 13965321 5510
2795.86
0x003001fd 1 C 0 4995 13967022 5510
2796.20
0x003001fd 1 C 0 4995 13968621 5510
2796.52
0x003001fd 1 C 0 4995 13970191 5510
2796.83
onstat -u (Btree scanner; 10x with sleep 1)
--------------------------------------------
59c17630 ---P--B 15 informix - 0 0 013576997 192
59c17630 ---P--B 15 informix - 0 0 0
13579138 192
59c17630 ---P--B 15 informix - 0 0 0
13581210 192
59c17630 ---P--B 15 informix - 0 0 0
13583390 192
59c17630 ---P--B 15 informix - 0 0 0
13585283 192
59c17630 ---P--B 15 informix - 0 0 0
13587201 192
59c17630 ---P--B 15 informix - 0 0 0
13589181 192
59c17630 ---P--B 15 informix - 0 0 0
13590937 192
59c17630 ---P--B 15 informix - 0 0 0
13592520 192
59c17630 ---P--B 15 informix - 0 0 0
13594097 192
It seems so, that the B-tree scanner scans (examines) the complete
index (507738 index pages used, table has 53.342.932 rows) - but there
were only ~ 500 deleted rows in the last hour ?! And: This index is in
the buffer pool (no difference with rangesize 100).
The Informix server is ~ 1 day up, this table has only 5.000 deletes
in this period.
Any suggestions, explanations ?
Regards,
try_and_err
"Neil Truby" <neil.truby@ardenta.com> wrote in message news:<30bg9kF2samq9U1@uni-berlin.de>...
> "try_and_err" <try_and_err@web.de> wrote in message
> news:fbcbd702.0411210152.46b7f76f@posting.google.com...
> > Hi,
> >
> > i am very frustrated with the new 9.40 "feature" named B-tree scanner:
> > After upgrading 9.30 to 9.40 i found out, that we have ~ 30x (!!) more
> > i/o requests with 9.40 as with 9.30.
> > I have experimented with rangesize and threshold, but no change.
> > Is there a chance to stop this (when i stop the B-tree scanner the index
> > grows, not really a solution) or is the only solution downgrade to 9.30 ?
>
> http://www.informix.co.uk/btscanner.htm