powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
4 сообщений из 29, страница 2 из 2
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691214
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так-с. Продолжаем разговор :-)

Имеется вот такой результатик поиска "случайного ID из диапазона" (при нагрузке 200 аттачей):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
2014-07-08T22:59:34.0700 (26048:0x7fc7b7df8dd0) EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_154, SYSDBA:NONE, NONE, TCPv4:192.168.43.62)
        C:\1INSTALL\FB25SNAP\bin\isql.exe:2900
                (TRA_95309, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 315554:
-------------------------------------------------------------------------------
select id from v_random_find_avl_res where id >= ? order by id rows 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Select Expression
    -> First N Records
        -> Filter
            -> Table "V_RANDOM_FIND_AVL_RES Q" Access By ID
                -> Index " QDISTR_SND_ID " Range Scan (lower bound: 1/1)

param0 = bigint, "9644"

1 records fetched
  15148 ms, 386497 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
QDISTR                                       106941

И вот такая статистика базе и по таблице QDISTR на тот момент времени:
Код: 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.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
       Page size               16384
. . .
        Oldest transaction      76913
        Oldest active           76914
        Oldest snapshot         67592
        Next transaction        102192
. . .
        Sweep interval:         1000
. . .
Analyzing database pages ...
QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 60.57, total records: 533204
    Average version length: 40.31, total versions: 96923, max versions: 4
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 128.00, compression ratio: 2.11
    Pointer pages: 2, data page slots: 3682
    Data pages: 3682, average fill: 78%
    Primary pages: 3579, full pages: 3576, swept pages: 50
    Fill distribution:
         0 - 19% = 101
        20 - 39% = 1
        40 - 59% = 1
        60 - 79% = 2158
        80 - 99% = 1421

    Index PK_QDISTR (0)
        Root page: 431, depth: 2, leaf buckets: 590, nodes: 533222
        Average node length: 11.87, total dup: 1510, max dup: 2
        Average key length: 9.01, compression ratio: 1.00
        Average prefix length: 2.98, average data length: 6.02
        Clustering factor: 20535, ratio: 0.04
        Fill distribution:
             0 - 19% = 21
            20 - 39% = 53
            40 - 59% = 246
            60 - 79% = 38
            80 - 99% = 232

    Index QDISTR_DOC_SND (3)
        Root page: 462, depth: 2, leaf buckets: 398, nodes: 533256
        Average node length: 6.12, total dup: 481909, max dup: 99
        Average key length: 3.27, compression ratio: 8.26
        Average prefix length: 25.83, average data length: 1.17
        Clustering factor: 84757, ratio: 0.16
        Fill distribution:
             0 - 19% = 9
            20 - 39% = 52
            40 - 59% = 245
            60 - 79% = 69
            80 - 99% = 23

    Index QDISTR_SNDOP_RCVOP_SND_ID_DESC (4)
        Root page: 456, depth: 2, leaf buckets: 445, nodes: 538407
        Average node length: 6.43, total dup: 448814, max dup: 99
        Average key length: 3.58, compression ratio: 11.67
        Average prefix length: 40.36, average data length: 1.41
        Clustering factor: 108093, ratio: 0.20
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 44
            40 - 59% = 394
            60 - 79% = 4
            80 - 99% = 3

    Index  QDISTR_SND_ID  (2)
        Root page: 469, depth: 2, leaf buckets: 380, nodes: 533308
        Average node length: 5.56, total dup: 481951, max dup: 99
        Average key length:  2.71 , compression ratio: 3.33
        Average prefix length: 8.39, average data length: 0.61
        Clustering factor: 89648,  ratio: 0.17 
        Fill distribution:
             0 - 19% = 5
            20 - 39% = 55
            40 - 59% = 296
            60 - 79% = 13
            80 - 99% = 11

    Index QDISTR_WARE_SND_OPTYPE (1)
        Root page: 458, depth: 2, leaf buckets: 239, nodes: 538486
        Average node length: 4.91, total dup: 536781, max dup: 1496
        Average key length: 2.06, compression ratio: 13.13
        Average prefix length: 26.95, average data length: 0.05
        Clustering factor: 111010, ratio: 0.21
        Fill distribution:
             0 - 19% = 3
            20 - 39% = 0
            40 - 59% = 72
            60 - 79% = 107
            80 - 99% = 57


Из ratio: 0.17 для индекса QDISTR_SND_ID следует, что примерно на каждом 6-м ключике движок должен прыгать на новую страницу данных.
Трейс показывает, что всего было выполнено 106941 индексных чтений и при этом - 386497 фетчей (т.е. сумма количеств обращений к PP + DP + индексным страницам). На странице 16384 должно размещаться 16384 / 2,71 = ~6000 ключей.

Как по этим цифиркам понять, сколько раз движок прыгал на новые страницы данных и, след., создавал себе random IO ?
(хотя никаких reads'ов, как видим, не показано)

PS. статистика по индексам, запротоколированная в логе теста (пересчет её делается регулярно каким-то из аттачей):
TABIDXCURR_STATDONE_TIMESMS_MINMS_AVGMS_MAXLAST_DTSQDISTRPK_QDISTR1,4738E-636816350008.07.2014 23:05:55QDISTRQDISTR_DOC_SND1,53025E-536817457708.07.2014 23:05:55QDISTRQDISTR_SNDOP_RCVOP_SND_ID_DESC8,6322E-636817461008.07.2014 23:05:56QDISTR QDISTR_SND_ID 1,5298E-5 36816446108.07.2014 23:05:56QDISTRQDISTR_WARE_SND_OPTYPE0,000561482336817567008.07.2014 23:05:56
...
Рейтинг: 0 / 0
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691235
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКак по этим цифиркам понять, сколько раз движок прыгал на новые страницы данных и, след., создавал себе random IO ?
(хотя никаких reads'ов, как видим, не показано)
ты сам себе ответил. I/O - это reads/writes. Нет чтений - нет никакого I/O, хоть рандомного, хоть последовательного. Сколько раз мне еще это надо написать?
...
Рейтинг: 0 / 0
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691237
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тогда безумно не хватает чего-то, что могло бы объяснить вот это:Таблоид
Код: plaintext
 15148 ms , 386497 fetch(es)
Я третий месяц не могу понять, куда еще рыть, чтобы хоть как-то уменьшить эти дикие значения.
Причём, для их получения вовсе не надо запускать 200 аттачей. И 5-10 достаточно + подождать минут 5, пока они "в раж не войдут".
...
Рейтинг: 0 / 0
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
    #38691245
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
во-первых, мне не нравится вьюха в плане. Она должна быть раскручена до таблиц. Высылай мне пример. Ну и 15 сек я бы тоже искал внутри вьюхи, ибо такой запрос не может генерить 106941 индексных чтений, там явно внутри что-то накручено.
...
Рейтинг: 0 / 0
4 сообщений из 29, страница 2 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]