Плохой результат при последовательностном чтении. / Informix

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

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

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохой результат при последовательностном чтении.

25 сообщений из 31, страница 1 из 2

все

Плохой результат при последовательностном чтении.

#36302178

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

Гость

Доброго дня.

Подскажите, пожалуйста почему может быть такой низкий уровень кеш-попаданий чтения при запросах типа
"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)

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

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

Спасибо.

...

Рейтинг:

0 / 0

10.11.2009, 19:07

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302248

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

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

...

Рейтинг:

0 / 0

10.11.2009, 19:35

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302255

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

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

П.С.: И ничего непонятно про размеры строк вышеупомянутых трёх таблиц

...

Рейтинг:

0 / 0

10.11.2009, 19:38

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302264

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

И точно последний на сегодня вопрос: есть предположения или факты по вопросу количества экстентов в этих таблицах?

...

Рейтинг:

0 / 0

10.11.2009, 19:45

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302266

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

Гость

АнатоЛой,

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

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

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

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

...

Рейтинг:

0 / 0

10.11.2009, 19:46

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302268

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

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

Код: plaintext

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

sysptprof смотрите.

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

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

...

Рейтинг:

0 / 0

10.11.2009, 19:47

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302457

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

Гость

АнатоЛойИ точно последний на сегодня вопрос: есть предположения или факты по вопросу количества экстентов в этих таблицах?

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

...

Рейтинг:

0 / 0

10.11.2009, 22:20

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302462

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

Гость

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

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

Код: plaintext

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

...

Рейтинг:

0 / 0

10.11.2009, 22:22

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302510

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

Гость

АнатоЛойинтересующийся__
перекачиваю таблицу запросами типа
"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 строки. Либо я чего-то не понимаю )

...

Рейтинг:

0 / 0

10.11.2009, 22:47

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302539

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

... еще RA_PAGES страниц, лежащих на диске последовательно после прочитанной. Без доп. информации 100% гарантии (и даже 90%), что там лежат 63 строки этой же таблицы, следующие по индексу вслед за считанной, Вам никто не даст :(.

...

Рейтинг:

0 / 0

10.11.2009, 23:08

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302552

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

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

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

Меня интересовало всё-таки количество extents. extent - сплошной последовательно размещённый на диске кусок таблицы ("без разрывов" ). Если каждая Ваша таблица лежит одним таким куском и записи добавлялись в порядке возрастания/убывания первичного ключа - это как раз и есть тот самый счастливый случай с упреждающим чтением, который Вы хотели увидеть...

...

Рейтинг:

0 / 0

10.11.2009, 23:16

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36302958

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

Гость

Мои экстенты ничем не хуже Ваших ))
Я действительно имел в виду "куски" таблицы, лежащие в чанках на диске. (Ниже приведу результат 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

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

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

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

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

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.

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
 [code=plaintext]

 oncheck table2 

 [code=plaintext]
    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

Основное отличие в таблицах - размер строки.

...

Рейтинг:

0 / 0

11.11.2009, 09:37

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303013

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

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

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

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

onstat -p TABLE1

Код: plaintext

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

onstat -p TABLE2
i

Код: plaintext

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

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

...

Рейтинг:

0 / 0

11.11.2009, 09:57

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303146

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

Гость

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

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

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

Я несколько раз рестартовал БД, чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1

Код: plaintext

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

равны нулю. Это 100%

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

Код: plaintext

ixda-RA  idx-RA

равны нулю,

Код: plaintext

da-RA    RA-pgsused lchwaits

растут линейно в пропорциях указанных выше.

Опять вопрос: почему так происходит? Ведь запросы SELECT одинаковые.

...

Рейтинг:

0 / 0

11.11.2009, 10:40

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303307

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

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

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

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

Я несколько раз рестартовал БД,
чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1

Код: plaintext

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

равны нулю. Это 100%

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

...

Рейтинг:

0 / 0

11.11.2009, 11:27

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303421

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

Гость

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

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

Код: plaintext

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

Не растут

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

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

...

Рейтинг:

0 / 0

11.11.2009, 11:55

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303451

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

интересующийся__
4) select * from table1

Код: plaintext

1.
2.

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

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

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

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

...

Рейтинг:

0 / 0

11.11.2009, 12:07

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303531

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

onstat-

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

Что конкретно он вычитал( читает) можно увидеть в sysmaster::sysptprof

...

Рейтинг:

0 / 0

11.11.2009, 12:30

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303585

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

Код: plaintext

1.
2.
3.

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

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

UNLOAD TO ... SELECT {+ EXPLAIN} ...

...

Рейтинг:

0 / 0

11.11.2009, 12:47

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303592

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

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

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

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

...

Рейтинг:

0 / 0

11.11.2009, 12:50

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36303759

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

Гость

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

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

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

...

Рейтинг:

0 / 0

11.11.2009, 13:34

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36304019

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

интересующийся__
Везде работают o nload to 'dev/null/' select * from table.
Не опечатывайтесь так страшно, а то страшно...
o nload - это целый инструмент, в отличие от SQL u nload....

...

Рейтинг:

0 / 0

11.11.2009, 14:38

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36304492

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Давайте и я свои "5 коп" вставлю :)
интересующийся__
> "Перекачиваю" - это по непересекающимся диапазонам всю таблицу?
Именно. Расчитывал, что благодаря RA будет хороший результат.
Странно, как можно определять "хорошесть" результата по цифрам RA.
Вам ведь, вроде, нужна скорость выгрузки из одной таблицы и загрузки в другую, т.е. время потраченное на операцию в целом. И зачем вам некие мифические цифры RA ? Тем более, что сервер умеет и без RA читать быстро последовательные объемы данных через так называемый "big buffer", размер которого 32 стр. Это хорошо видно по вами же приведенным цифрам, когда RA совсем не включается (разделите pagreads на dskreads)

Код: plaintext

1.
2.
3.
4.

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(!) раза больше)
Вот вам и бОльшая загрузка винта, соответственно физическая скорость выгрузки будет также занчительно меньше.
интересующийся__
И как мне сделать так, чтобы обе таблицы читались одинаково быстро (эффективно)?

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

...

Рейтинг:

0 / 0

11.11.2009, 16:40

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36304511

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

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

интересующийся__
Я несколько раз рестартовал БД, чистил счетчики в ОП (onstat -z) и запускал select.
При загрузке table 1

Код: plaintext

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

равны нулю. Это 100%

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

Код: plaintext

ixda-RA  idx-RA

равны нулю,

Код: plaintext

da-RA    RA-pgsused lchwaits

растут линейно в пропорциях указанных выше.
Опять вопрос: почему так происходит? Ведь запросы SELECT одинаковые.
Выше уже ответил - таблицы разные , соответственно в первом случае работает big buffer , а во втором нет (зато работает RA).

...

Рейтинг:

0 / 0

11.11.2009, 16:48

| Ответить | Цитировать | Написать

Плохой результат при последовательностном чтении.

#36304544

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Кстати, вспомнил , что использование big buffers можно мониторить, т.е. выполните команду
onstat -g iob
после 1-й таблицы и после 2-й (предварительно сбросив onstat -z)

...

Рейтинг:

0 / 0

11.11.2009, 17:00

| Ответить | Цитировать | Написать

25 сообщений из 31, страница 1 из 2

все

Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохой результат при последовательностном чтении.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=44&msg=36302539&tid=1607699]:	0ms
get settings:	9ms
get forum list:	12ms
check forum access:	4ms
check topic access:	4ms
track hit:	48ms
get topic data:	11ms
get forum data:	3ms
get page messages:	57ms
get tp. blocked users:	1ms
others:	15ms

total:	164ms