Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Informix Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
Доброго дня.

Подскажите, пожалуйста почему может быть такой низкий уровень кеш-попаданий чтения при запросах типа
"SELECT * FROM TABLE WHERE ID > 0 and ID <1000000"?

Чуть подробнее:
перекачиваю таблицу запросами типа
"INSERT INTO table SELECT * FROM table WHERE ID > startRange and ID < endRange".
ID - первичный ключ.

вот результат onstat -p ~20 минут работы сервера-источника (на котором исполняется select)


Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
19528796 36549247 83294381 76.55 0 0 0 0.00

isamtot open start read write rewrite delete commit rollbk
20979638 0 0 20990780 0 0 0 0 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 2367.86 6438.46 0 160

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
165508 0 15141603 0 0 0 0 0

ixda-RA idx-RA da-RA RA-pgsused lchwaits
15140764 0 182709 15324697 449429


Почему всего 76%?
диски с данными грузятся на все 100. Почему не работают RA с буферами?

Вот часть onconfig'а, отвечающая (по моему мнению) за это безобразие

BUFFERS 262144
LRU_MAX_DIRTY 30
LRU_MIN_DIRTY 20
RA_PAGES 128
RA_THRESHOLD 64
SHMVIRTSIZE 131072 # initial virtual shared memory segment size
SHMADD 32768 # Size of new shared memory segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited

Буферов мало, т.к. сервер слабоват, отдать больше не получается. Но все-таки, там полгига!

Одновременно исполняются 9 SELECT'ов (3 таблицы по 3 части) IDS 7.31

Спасибо.
10 ноя 09, 19:07    [7910212]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
интересующийся__

перекачиваю таблицу запросами типа
"INSERT INTO table SELECT * FROM table WHERE ID > startRange and ID < endRange".
ID - первичный ключ.

"Перекачиваю" - это по непересекающимся диапазонам всю таблицу?
Тогда кеш-попаданий чтения по объёму будет максимум "количество селектов" * RA_PAGES (если всё лежит на диске ровненько аккуратненько). Получаем 9*128 = 1 МБ данных... Мне вообще непонятно, откуда даже 76% накапало... В статистике виден "результат" работы только этих select? Если да, то искомые данные в буфера уже поднимались до этого? И наконец, а какой объём перекачиваемых таблиц?
10 ноя 09, 19:35    [7910344]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
АнатоЛой

Получаем 9*128 = 1 МБ данных...

Пардон, вечер... То есть я хотел сказать почти 1 КБ страниц...

П.С.: И ничего непонятно про размеры строк вышеупомянутых трёх таблиц
10 ноя 09, 19:38    [7910359]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
АнатоЛой
интересующийся__

перекачиваю таблицу запросами типа
"INSERT INTO table SELECT * FROM table WHERE ID > startRange and ID < endRange".
ID - первичный ключ.
если всё лежит на диске ровненько аккуратненько


И точно последний на сегодня вопрос: есть предположения или факты по вопросу количества экстентов в этих таблицах?
10 ноя 09, 19:45    [7910377]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
АнатоЛой,

> "Перекачиваю" - это по непересекающимся диапазонам всю таблицу?
Именно. Расчитывал, что благодаря RA будет хороший результат.

> В статистике виден "результат" работы только этих select?
Да, это единственная активность

> искомые данные в буфера уже поднимались до этого?
нет.

> И наконец, а какой объём перекачиваемых таблиц?
около 10 млн строк. размер строки около 2300 байт. Все 3 таблицы такие
10 ноя 09, 19:46    [7910379]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Вопрос неправильно поставлен,
ИМХО он должен звучать "почему так медленно"
:)

ИМХО потому что используются индексы
автор

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
15140764 0 182709 15324697 449429


sysptprof смотрите.

Когда избавитесь от использования индексов может стать быстрее, и процент кеширования станет еще ниже.

ИМХО я бы диапазоны попытался поделить по rowid(или по фрагментам если есть ),
если нужно параллелить чтение и загрузку.
10 ноя 09, 19:47    [7910382]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
АнатоЛой
И точно последний на сегодня вопрос: есть предположения или факты по вопросу количества экстентов в этих таблицах?


Да, таблицы в экстентах 1 либо 2 ГБ.
10 ноя 09, 22:20    [7910769]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
onstat-
Вопрос неправильно поставлен,
ИМХО он должен звучать "почему так медленно"
:)

ИМХО потому что используются индексы
автор

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
15140764 0 182709 15324697 449429


sysptprof смотрите.

Когда избавитесь от использования индексов может стать быстрее, и процент кеширования станет еще ниже.

ИМХО я бы диапазоны попытался поделить по rowid(или по фрагментам если есть ),
если нужно параллелить чтение и загрузку.

Спасибо, попробую без индексов
10 ноя 09, 22:22    [7910777]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
АнатоЛой
интересующийся__

перекачиваю таблицу запросами типа
"INSERT INTO table SELECT * FROM table WHERE ID > startRange and ID < endRange".
ID - первичный ключ.

"Перекачиваю" - это по непересекающимся диапазонам всю таблицу?
Тогда кеш-попаданий чтения по объёму будет максимум "количество селектов" * RA_PAGES (если всё лежит на диске ровненько аккуратненько). Получаем 9*128 = 1 МБ данных... Мне вообще непонятно, откуда даже 76% накапало... В статистике виден "результат" работы только этих select? Если да, то искомые данные в буфера уже поднимались до этого? И наконец, а какой объём перекачиваемых таблиц?


Буду благодарен, если поясните, в чем я ошибаюсь:
я считал, что когда таблица читается последовательностно, при чтении страницы с первой строкой в буфера читаются еще RA_PAGES страниц. Затем, причтении 2ой строки обращение идет уже к буферам, пока не останется RA_THRESOLD страницы. Т.е, при раземре строки, скажем, в 2 страницы, а RA_PAGES в 128 страниц, за одно чтение должно считаться 64 строки. Либо я чего-то не понимаю )
10 ноя 09, 22:47    [7910850]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
интересующийся__

я считал, что когда таблица читается последовательностно, при чтении страницы с первой строкой в буфера читаются еще RA_PAGES страниц...

... еще RA_PAGES страниц, лежащих на диске последовательно после прочитанной. Без доп. информации 100% гарантии (и даже 90%), что там лежат 63 строки этой же таблицы, следующие по индексу вслед за считанной, Вам никто не даст :(.
10 ноя 09, 23:08    [7910913]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
интересующийся__
АнатоЛой
И точно последний на сегодня вопрос: есть предположения или факты по вопросу количества экстентов в этих таблицах?


Да, таблицы в экстентах 1 либо 2 ГБ.

экстент = extent

Ваше "в экстентах 1 либо 2 ГБ" скорее всего соответствует нашему "в чанках (chunks) 1 либо 2 ГБ" %)

Меня интересовало всё-таки количество extents. extent - сплошной последовательно размещённый на диске кусок таблицы ("без разрывов" ). Если каждая Ваша таблица лежит одним таким куском и записи добавлялись в порядке возрастания/убывания первичного ключа - это как раз и есть тот самый счастливый случай с упреждающим чтением, который Вы хотели увидеть...
10 ноя 09, 23:16    [7910945]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
Мои экстенты ничем не хуже Ваших ))
Я действительно имел в виду "куски" таблицы, лежащие в чанках на диске. (Ниже приведу результат oncheck)

Убрал индексы из запроса. Для чистоты эксперимента запросы привел к виду:
"unload to '/dev/null SELECT * FROM source_table".
Оставил только 2 таблицы: table1, table2.

В один момент времени выгружаю только одну таблицу (работает только 1 селект).

Заметил интересную особенность:
1) первая таблица читается (запустил SELECT по table1) очень быстро, %cached = 98.83, диск загружен на 3%.
2) вторая таблица читается (запустил SELECT по table2) в разы медленнее. %cached = 79.04, диск загружен на 70%
Почему такая большая разница? И как мне сделать так, чтобы обе таблицы читались одинаково быстро (эффективно)?
Ведь запросы без where, IDS должен просто читать данные в экстенте размером в RA_PAGES, и использовать буфера (а не диск) при чтении следующих n строк.

Ниже привел onstat -p для работы первого и второго SELECT за почти одинаковый отрезок времени и oncheck -pc для таблиц.

onstat -p TABLE1


dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
1825 57794 151335 98.79 0 0 0 0.00

isamtot open start read write rewrite delete commit rollbk
42633 0 0 42633 0 0 0 0 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 5.06 6.60 0 2

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
0 0 0 0 0 0 0 0

ixda-RA idx-RA da-RA RA-pgsused lchwaits
0 0 0 0 0

oncheck table1

table1
TBLspace Flags 802 Row Locking
TBLspace use 4 bit bit-maps
Maximum row size 81
Number of special columns 0
Number of keys 3
Number of extents 5
Current serial value 1
First extent size 499998
Next extent size 499998
Number of pages allocated 2999988
Number of pages used 2999988
Number of data pages 1674042
Number of rows 38502182
Partition partnum 4194352
Partition lockid 4194352

Extents
Logical Page Physical Page Size
0 1000003 999996
999996 147a121 499998
1499994 1c7a121 499998
1999992 227a121 499998
2499990 257a121 499998

Index information.
Number of indexes 3
Data record size 81
Index record size 2048
Number of records 3.85022e+07


onstat -p TABLE2

dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
85281 105891 408868 79.14 0 0 0 0.00

isamtot open start read write rewrite delete commit rollbk
68124 0 0 68124 0 0 0 0 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 6.06 7.85 0 2

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
0 0 0 0 0 0 0 0

ixda-RA idx-RA da-RA RA-pgsused lchwaits
0 0 68224 68124 34


oncheck table2


TBLspace Flags 802 Row Locking
TBLspace use 4 bit bit-maps
Maximum row size 2300
Number of special columns 0
Number of keys 8
Number of extents 22
Current serial value 180361630
First extent size 499998
Next extent size 999996
Number of pages allocated 15499938
Number of pages used 15499938
Number of data pages 10371375
Number of rows 10371375
Partition partnum 4194346
Partition lockid 4194346

Extents
Logical Page Physical Page Size
0 724dd5 499998
499998 800003 999996
1499994 900003 999996
2499990 1400003 499998
2999988 1500003 499998
3499986 1600003 499998
3999984 1a00003 499998
4499982 c00003 499998
4999980 d00003 499998
5499978 1d00003 499998
5999976 1e00003 999996
6999972 2000003 499998
7499970 217a121 499998
7999968 237a121 499998
8499966 247a121 499998
8999964 2500003 499998
9499962 2600003 999996
10499958 2900003 999996
11499954 2c00003 999996
12499950 2d00003 999996
13499946 2e00003 999996
14499942 3f00003 999996

Index information.
Number of indexes 8
Data record size 2300
Index record size 2048
Number of records 1.03714e+07


Основное отличие в таблицах - размер строки.
11 ноя 09, 09:37    [7911697]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
onstat-
Member

Откуда:
Сообщений: 6941
интересующийся__


Буду благодарен, если поясните, в чем я ошибаюсь:


В том что при индексном поиске таблица не читается упреждающим чтением,
с упреждением читается только индекс, он повышает процент кеширования.
нО он вам не нужен, поверьте.


интересующийся__




onstat -p TABLE1
ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
0 0 0 0 0



onstat -p TABLE2
i
xda-RA  idx-RA   da-RA    RA-pgsused lchwaits
0 0 68224 68124 34



ИМХО
в первом случае чтение производится из буферов.
Эксперемент не чистый.
11 ноя 09, 09:57    [7911816]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
onstat-

... при индексном поиске таблица не читается упреждающим чтением,
с упреждением читается только индекс, он повышает процент кеширования.
нО он вам не нужен, поверьте.



Понял, спасибо. Запросы оставил вообще без where. Это гарантирует работу SELECT'а без индексного чтения? Или надо ставить какие-нибудь hitn'ы?


onstat-

ИМХО
в первом случае чтение производится из буферов.
Эксперемент не чистый.


Я несколько раз рестартовал БД, чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1
ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
равны нулю. Это 100%

При загрузке table 2

ixda-RA  idx-RA
равны нулю,
da-RA    RA-pgsused lchwaits
растут линейно в пропорциях указанных выше.

Опять вопрос: почему так происходит? Ведь запросы SELECT одинаковые.
11 ноя 09, 10:40    [7912099]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
onstat-
Member

Откуда:
Сообщений: 6941
интересующийся__


Понял, спасибо. Запросы оставил вообще без where. Это гарантирует работу SELECT'а без индексного чтения? Или надо ставить какие-нибудь hitn'ы?


Если без where то индексы использоваться не будут.


интересующийся__


Я несколько раз рестартовал БД,
чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1
ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
равны нулю. Это 100%

onstat -z не освобождает буфера. Он только статистику чистит.
Рестарт сервера должен освобождать буфера.
Попробуйте рестартовать, сбросить статистику , и запустить единственную сессию
unload из table 1. Цифры чтений будут расти 100%.
11 ноя 09, 11:27    [7912507]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
onstat-

onstat -z не освобождает буфера. Он только статистику чистит.
Рестарт сервера должен освобождать буфера.
Попробуйте рестартовать, сбросить статистику , и запустить единственную сессию
unload из table 1. Цифры чтений будут расти 100%.

Так и делал...

Еще раз сделал:
1) onmode -ky
2) oninit
3) onstat -z
4) select * from table1
5) жду несколько минут
6) onstat -p
ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
Не растут

dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
5688 168072 477880 98.81 0 0 0 0.00

isamtot open start read write rewrite delete commit rollbk
142837 22 34 142740 0 0 0 0 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 12.63 15.97 0 6

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
6 0 70 0 0 0 0 2

ixda-RA idx-RA da-RA RA-pgsused lchwaits
6 0 0 6 1
11 ноя 09, 11:55    [7912782]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
onstat-
Member

Откуда:
Сообщений: 6941
интересующийся__

4) select * from table1


ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
6 0 0 6 1


6 страниц индекса он прочитал упреждающим чтением.
и одну страницу данных без упреждающего.


не select * from table1
а unload ...... select * from table1

Informix не будет читать с диска если ему некуда отдавать то что он уже вычитал.
11 ноя 09, 12:07    [7912875]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
onstat-
Member

Откуда:
Сообщений: 6941
onstat-


Informix не будет читать с диска если ему некуда отдавать то что он уже вычитал.


Что конкретно он вычитал( читает) можно увидеть в sysmaster::sysptprof
11 ноя 09, 12:30    [7913092]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
А как конкретно он читал (с индексами, без индексов , или даже ещё с какими-то переподвывертами ((с)), можно увидеть в ~/explain.out если сделать так:

SET EXPLAIN ON;
UNLOAD TO ... SELECT ...
SET EXPLAIN OFF;

или может сработает и так (сам unload никогда так не пробовал :) )

UNLOAD TO ... SELECT {+ EXPLAIN} ...
11 ноя 09, 12:47    [7913245]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
интересующийся__


4) select * from table1
5) жду несколько минут

select все эти несколько минут работал? не сочтите за издёвку - select или unload to select?
11 ноя 09, 12:50    [7913273]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
интересующийся__
Guest
АнатоЛой

6 страниц индекса он прочитал упреждающим чтением.
и одну страницу данных без упреждающего.

Похоже, sysmaster читал (6 страниц), или еще какую-нибудь мелочь. Не увеличиваются RA счетчики при unload to select * from table1. 100% )

АнатоЛой

select все эти несколько минут работал? не сочтите за издёвку - select или unload to select?


Везде работают onload to 'dev/null/' select * from table.
11 ноя 09, 13:34    [7913703]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
интересующийся__

Везде работают onload to 'dev/null/' select * from table.

Не опечатывайтесь так страшно, а то страшно...
onload - это целый инструмент, в отличие от SQL unload....
11 ноя 09, 14:38    [7914382]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
Давайте и я свои "5 коп" вставлю :)
интересующийся__

> "Перекачиваю" - это по непересекающимся диапазонам всю таблицу?
Именно. Расчитывал, что благодаря RA будет хороший результат.

Странно, как можно определять "хорошесть" результата по цифрам RA.
Вам ведь, вроде, нужна скорость выгрузки из одной таблицы и загрузки в другую, т.е. время потраченное на операцию в целом. И зачем вам некие мифические цифры RA ? Тем более, что сервер умеет и без RA читать быстро последовательные объемы данных через так называемый "big buffer", размер которого 32 стр. Это хорошо видно по вами же приведенным цифрам, когда RA совсем не включается (разделите pagreads на dskreads)
dskreads pagreads bufreads %cached
1825 57794 151335 98.79
...
ixda-RA idx-RA da-RA RA-pgsused lchwaits
0 0 0 0 0
Такое чтение часто еще называют в литературе light scans

интересующийся__

> И наконец, а какой объём перекачиваемых таблиц?
около 10 млн строк. размер строки около 2300 байт. Все 3 таблицы такие

Неправда, по крайней мере вы сами дали информацию по двум таблицам, одна из которых имеет 38,5млн. строк с размером 81 байт.

интересующийся__

Буду благодарен, если поясните, в чем я ошибаюсь:
я считал, что когда таблица читается последовательностно, при чтении страницы с первой строкой в буфера читаются еще RA_PAGES страниц. Затем, причтении 2ой строки обращение идет уже к буферам, пока не останется RA_THRESOLD страницы. Т.е, при раземре строки, скажем, в 2 страницы, а RA_PAGES в 128 страниц, за одно чтение должно считаться 64 строки. Либо я чего-то не понимаю )

В принципе, понимаете правильно за исключением некоторых нюансов :)
1. RA на 7.3, вроде, фактически не превышает те же 32 страницы, хотя установить в onconfig можно и значительно больше. Тут ранее уже были дискуссии на эту тему, плохо помню, можете поискать (в том числе и о вреде RA :)
2. Строки, размер которых не помещается на одну страницу, довольно своеобразны - остаток строки, не поместившийся на 1-ю страницу, записывается в специальный тип страницы (remainder page, кажется так называется) и эти страницы, как мне кажется, вряд ли будут участвовать в RA, т.к. для их получения (определения) уже нужно анализировать соедржимое первичной страницы.

интересующийся__

Заметил интересную особенность:
1) первая таблица читается (запустил SELECT по table1) очень быстро, %cached = 98.83, диск загружен на 3%.
2) вторая таблица читается (запустил SELECT по table2) в разы медленнее. %cached = 79.04, диск загружен на 70%
Почему такая большая разница?

Так ведь легко можно и самому увидеть на цифрах, тем более, что статистика взята "почти за одно и то же время".
Сравните аналогичные показатели для 1-й (таблицы с небольшой строкой, 38 млн.строк и 3 млн.страниц) и 2-й (2300б строка и 16 млн(!) страниц, хотя по кол-ву строк она и в три раза меньше)
dskreads 1825 и 85281 (дисковых операций в 46(!) раз больше)
pagreads 57794 и 105891 (а страниц прочитано всего в 2(!) раза больше)
Вот вам и бОльшая загрузка винта, соответственно физическая скорость выгрузки будет также занчительно меньше.
интересующийся__

И как мне сделать так, чтобы обе таблицы читались одинаково быстро (эффективно)?

Сделать их одинаковыми :)
Вы же сами пишете "Основное отличие в таблицах - размер строки", так почему они должны читаться "одинаково быстро" ? Законы физики еще не отменили и скорость работы вашего винта (дискового массива) пока конечная.

Сообщение было отредактировано: 11 ноя 09, 16:55
11 ноя 09, 16:40    [7915479]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
интересующийся__

Понял, спасибо. Запросы оставил вообще без where. Это гарантирует работу SELECT'а без индексного чтения? Или надо ставить какие-нибудь hitn'ы?

Это не гарантирует (у оптимизатора иногда своя логика, основанная на статистике или ее отсутствии :), но сильно повышает вероятность (99.9%)
При миграции можете вообще отключить индексы (или дропнуть их, т.к. на новом месте будете строить заново), но будьте внимательны с автоиндексами, реализующими ограничения внешнего ключа - сначала нужно убрать зависимости.

интересующийся__

Я несколько раз рестартовал БД, чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1
ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
равны нулю. Это 100%

При загрузке table 2
ixda-RA  idx-RA
равны нулю,
da-RA    RA-pgsused lchwaits
растут линейно в пропорциях указанных выше.
Опять вопрос: почему так происходит? Ведь запросы SELECT одинаковые.

Выше уже ответил - таблицы разные, соответственно в первом случае работает big buffer , а во втором нет (зато работает RA).
11 ноя 09, 16:48    [7915533]     Ответить | Цитировать Сообщить модератору
 Re: Плохой результат при последовательностном чтении.  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
Кстати, вспомнил , что использование big buffers можно мониторить, т.е. выполните команду
onstat -g iob
после 1-й таблицы и после 2-й (предварительно сбросив onstat -z)
11 ноя 09, 17:00    [7915611]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Informix Ответить