gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ? / Firebird, InterBase

ReSQL.ru

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

Гость

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

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

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

Цитировать

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

Вложение:

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

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

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

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

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

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

29 сообщений из 29, показаны все 2 страниц

все

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38689940

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hi all

Допустим, есть вот такие две таблички:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.

recreate table qdistr(
   id dm_ids generated by default as identity constraint pk_qdistr primary key using index pk_qdistr
   . . . other fields . . .
);

recreate table qstorned(
   id dm_ids constraint pk_qdstorned primary key using index pk_qdstorned
   . . . other fields . . .
);

Данные сначала всегда попадают в первую из них. При этом поле id монотонно увеличивается (см DDL).
В процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.

До начала любого вида перемещения выполняется попытка блокировки выбранной записи в таблице-источнике, дабы бестолку не вызывать insert в таблице-приёмнике. Из этого следует, что сколько бы транзакций-конкурентов не трудилось одновременно, бубликатов в первичном ключе не будет (ни в одной из таблиц).

Тогда как объяснить результат gstat -r для этих табличек:

Код: 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.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.

QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 64.25, total records: 4780985
    Average version length: 51.09, total versions: 435633, max versions: 4
    Average fragment length: 57.50, total fragments: 2, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.99
    Pointer pages: 11, data page slots: 37537
    Data pages: 37483, average fill: 69%
    Primary pages: 37278, full pages: 16846, swept pages: 11706
    Fill distribution:
	 0 - 19% = 212
	20 - 39% = 255
	40 - 59% = 5340
	60 - 79% = 31435
	80 - 99% = 241

    Index PK_QDISTR (0)
	Root page: 18778, depth: 3, leaf buckets: 5827, nodes: 4780985
	Average node length: 11.53,  total dup: 2360, max dup: 3  <<<<<<<<<<<<<< [ 1 ] <<<<<<<<<<<<<
	Average key length: 8.55, compression ratio: 1.05
	Average prefix length: 3.45, average data length: 5.55
	Clustering factor: 744689, ratio: 0.16
	Fill distribution:
	     0 - 19% = 215
	    20 - 39% = 1130
	    40 - 59% = 2382
	    60 - 79% = 390
	    80 - 99% = 1710

    Index QDISTR_DOC_SND (3)
	Root page: 15991, depth: 3, leaf buckets: 2959, nodes: 4780985
	Average node length: 6.10, total dup: 4327928, max dup: 90
	Average key length: 3.11, compression ratio: 8.68
	Average prefix length: 25.98, average data length: 1.02
	Clustering factor: 2932562, ratio: 0.61
	Fill distribution:
	     0 - 19% = 22
	    20 - 39% = 358
	    40 - 59% = 1124
	    60 - 79% = 724
	    80 - 99% = 731

    Index QDISTR_ID_DESC (4)
	Root page: 15052, depth: 3, leaf buckets: 7648, nodes: 4780985
	Average node length: 11.53, total dup: 2360, max dup: 3
	Average key length: 8.55, compression ratio: 1.05
	Average prefix length: 3.45, average data length: 5.55
	Clustering factor: 744725, ratio: 0.16
	Fill distribution:
	     0 - 19% = 2
	    20 - 39% = 1812
	    40 - 59% = 5782
	    60 - 79% = 39
	    80 - 99% = 13

    Index QDISTR_SND_ID (2)
	Root page: 28666, depth: 3, leaf buckets: 3498, nodes: 4780985
	Average node length: 5.66, total dup: 4327928, max dup: 90
	Average key length: 2.67, compression ratio: 3.37
	Average prefix length: 8.42, average data length: 0.58
	Clustering factor: 2938598, ratio: 0.61
	Fill distribution:
	     0 - 19% = 26
	    20 - 39% = 651
	    40 - 59% = 2434
	    60 - 79% = 359
	    80 - 99% = 28

    Index QDISTR_WARE_SND_OPTYPE (1)
	Root page: 21748, depth: 3, leaf buckets: 2890, nodes: 4802188
	Average node length: 5.01, total dup: 4798781, max dup: 7421
	Average key length: 2.03, compression ratio: 13.33
	Average prefix length: 26.97, average data length: 0.03
	Clustering factor: 2838778, ratio: 0.59
	Fill distribution:
	     0 - 19% = 7
	    20 - 39% = 153
	    40 - 59% = 2259
	    60 - 79% = 323
	    80 - 99% = 148

QSTORNED (152)
    Primary pointer page: 241, Index root page: 242
    Total formats: 1, used formats: 1
    Average record length: 70.92, total records: 794944
    Average version length: 71.15, total versions: 13779, max versions: 1
    Average fragment length: 60.14, total fragments: 7, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.80
    Pointer pages: 2, data page slots: 5644
    Data pages: 5643, average fill: 77%
    Primary pages: 5641, full pages: 4411, swept pages: 3751
    Fill distribution:
	 0 - 19% = 2
	20 - 39% = 4
	40 - 59% = 111
	60 - 79% = 3239
	80 - 99% = 2287

    Index PK_QDSTORNED (0)
	Root page: 550, depth: 2, leaf buckets: 883, nodes: 794944
	Average node length: 11.89,  total dup: 6169, max dup: 2   <<<<<<<<<<<<<< [ 2 ] <<<<<<<<<<<<<
	Average key length: 8.99, compression ratio: 1.00
	Average prefix length: 3.00, average data length: 6.00
	Clustering factor: 710396, ratio: 0.89
	Fill distribution:
	     0 - 19% = 2
	    20 - 39% = 0
	    40 - 59% = 347
	    60 - 79% = 370
	    80 - 99% = 164

    Index QSTORNED_DOC_ID (1)
	Root page: 872, depth: 2, leaf buckets: 390, nodes: 794944
	Average node length: 5.11, total dup: 773596, max dup: 3633
	Average key length: 2.21, compression ratio: 4.07
	Average prefix length: 8.82, average data length: 0.18
	Clustering factor: 144666, ratio: 0.18
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 5
	    40 - 59% = 179
	    60 - 79% = 130
	    80 - 99% = 76

    Index QSTORNED_RCV_ID (3)
	Root page: 907, depth: 2, leaf buckets: 446, nodes: 794944
	Average node length: 5.20, total dup: 753956, max dup: 64103
	Average key length: 2.30, compression ratio: 3.59
	Average prefix length: 7.94, average data length: 0.33
	Clustering factor: 61537, ratio: 0.08
	Fill distribution:
	     0 - 19% = 15
	    20 - 39% = 21
	    40 - 59% = 245
	    60 - 79% = 112
	    80 - 99% = 53

    Index QSTORNED_SND_ID (2)
	Root page: 854, depth: 2, leaf buckets: 437, nodes: 794944
	Average node length: 5.73, total dup: 704798, max dup: 108
	Average key length: 2.83, compression ratio: 3.17
	Average prefix length: 8.28, average data length: 0.72
	Clustering factor: 169008, ratio: 0.21
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 1
	    40 - 59% = 195
	    60 - 79% = 165
	    80 - 99% = 75

PS. И еще вопрос, вернее - просьба.
2 dimitr / hvlad : я правильно понимаю (перечитав топег про clustering factor ), что если разделить число `nodes` на число `Clustering factor`, то результат будет говорить, насколько часто происходит random IO при выполнении навигации по данному индексу (plan order ...) ?
Например, для вот этого:

Код: plaintext

1.
2.
3.
4.
5.

    Index QDISTR_DOC_SND (3)
	Root page: 15991, depth: 3, leaf buckets: 2959, nodes:  4780985 
	Average node length: 6.10, total dup: 4327928, max dup: 90
	Average key length: 3.11, compression ratio: 8.68
	Average prefix length: 25.98, average data length: 1.02
	Clustering factor:  2932562 , ratio: 0.61

- получаем 4780985 / 2932562 = ~1.6, т.е. для это ~5/3.
Для каждых 5 ключей будет 3 скачка со страницы на страницу - правильно ?

PPS. Что такое "ratio", рядом с фактором кластеризации ?

...

Рейтинг:

0 / 0

08.07.2014, 01:58

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38689967

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Таблоидя правильно понимаю что если разделить число `nodes` на число `Clustering factor`, то результат будет говорить, насколько часто происходит random IO при выполнении навигации по данному индексу (plan order ...) ?
PPS. Что такое "ratio", рядом с фактором кластеризации ?
правильно. Но делить необязательно, ratio это уже результат деления (только обратный от твоего) - каждый 1.6-й ключ будет скачек на другую страницу.

...

Рейтинг:

0 / 0

08.07.2014, 07:06

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38689970

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

т.е. ratio это просто фактор отнесенный к числу ключей (иными словами, вынесенный в диапазон 0-1)

...

Рейтинг:

0 / 0

08.07.2014, 07:13

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38689974

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

еще уточню, что будет или нет random I/O также зависит от кеша, фактор кластеризации это не учитывает. Т.е. фактор скорее показывает, какая процентная часть page reads может оказаться случайной.

...

Рейтинг:

0 / 0

08.07.2014, 07:22

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690027

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

dimitrфактор скорее показывает, какая процентная часть page reads может оказаться случайной.Значит, чем меньше ratio, тем реже будут перепрыгивания на другую страницу, т.е. - тем лучше. Ок.
dimitrеще уточню, что будет или нет random I/O также зависит от кеша , фактор кластеризации это не учитывает.Я правильно понимать, что если страничный кеш задан с большим запасом и read(s) по данным трейса отсутствуют, а write(s) - не очень значительные (1-2 сотни), то можно считать, что random'ного IO - нету.
Или он всё таки есть, но это уже когда операционка пишет в фоновом режиме на диск, и тут нужно анализировать статистику оси, а не ФБ-трейс ?

PS. Ну, и по сабжу хотелось бы понять, как такое может быть...

...

Рейтинг:

0 / 0

08.07.2014, 09:18

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690073

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

ТаблоидЯ правильно понимать, что если страничный кеш задан с большим запасом и read(s) по данным трейса отсутствуют, а write(s) - не очень значительные (1-2 сотни), то можно считать, что random'ного IO - нету.
если пара сотен возможно рандомных записей тебе незначительны, то можешь считать :-) Кластер факторизации отражает только чтения, если reads нулевой то фактор полезной информации не дает. Вот только в реальной жизни это скорее исключение.

...

Рейтинг:

0 / 0

08.07.2014, 10:10

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690339

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ТаблоидТогда как объяснить результат gstat -r для этих табличек:
Таблоид

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 64.25, total records: 4780985
    Average version length: 51.09,  total versions: 435633, max versions: 4 
    Average fragment length: 57.50, total fragments: 2, max fragments: 1
...
    Index PK_QDISTR (0)
	Root page: 18778, depth: 3, leaf buckets: 5827, nodes: 4780985
	Average node length: 11.53,  total dup: 2360, max dup: 3  <<<<<<<<<<<<<< [ 1 ] <<<<<<<<<<<<<

Мусор собирать не пробовал ? :)

...

Рейтинг:

0 / 0

08.07.2014, 13:09

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690363

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hvladМусор собирать не пробовал ? :)Собрал - помогло :-)
Только всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.

...

Рейтинг:

0 / 0

08.07.2014, 13:24

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690452

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Таблоид,

select ... with lock тоже создаёт версии

...

Рейтинг:

0 / 0

08.07.2014, 14:12

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690464

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

Симонов Денис,

но не в индексах

...

Рейтинг:

0 / 0

08.07.2014, 14:20

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690574

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

Таблоидоткудова могли взяться версии (=значения) одних и тех же ID'шников, которые
генератором дёргаются.
Удалили запись, но мусор не собрали - нода в индексе осталась.
Вставили снова эту же запись - в индексе уже две ноды с одним значением.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

08.07.2014, 15:09

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690591

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ТаблоидТолько всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.А вот это кто писал ?
ТаблоидВ процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.

...

Рейтинг:

0 / 0

08.07.2014, 15:20

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690629

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hvladТаблоидТолько всё равно не догоняю, откудова могли взяться версии (=значения) одних и тех же ID'шников, которые генератором дёргаются.А вот это кто писал ?
ТаблоидВ процессе работы некоторые записи могут быть перемещены из qdistr в qstorned (т.е. с удалением в первой). Затем они могут быть перемещены обратно. При таком "обратном" движении (из qstorned в pdistr) значение в поле ID сохраняется - его всё равно не будет в приемнике ввиду предыдущего удаления оттудова.А тогда у мну претензии к фоновому сборщику! Чё он не удаляет-то их при вот таком раскладе счетчиков :

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

Database "/var/db/fb30/oltp30.page16k.after3hr.200attaches_runcase08x4.fdb"
Database header page information:
        Flags                   0
        Generation              529587
        System Change Number    0
        Page size               16384
        ODS version             12.0
        Oldest transaction      529194
        Oldest active           529195
         Oldest snapshot         529193 
         Next transaction        529199 
        Sequence number         0
        Next attachment ID      955
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jul 7, 2014 22:00:30
        Attributes

    Variable header data:
        *END*

(это база, которая была до сборки мусора)

...

Рейтинг:

0 / 0

08.07.2014, 15:33

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690720

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ТаблоидА тогда у мну претензии к фоновому сборщику!Последний insert\delete в какой тр-ции был ? Новая тр-ция потом была ? А она сдвинула OST? А полный дисконнект был ?

...

Рейтинг:

0 / 0

08.07.2014, 16:05

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690764

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hvladТаблоидА тогда у мну претензии к фоновому сборщику!Последний insert\delete в какой тр-ции был ? Новая тр-ция потом была ? А она сдвинула OST? А полный дисконнект был ?

Код: plaintext

1.
2.
3.
4.

SQL> select max(trn_id) from qdistr;

                  MAX
=====================
               528385

(это номер последней транзакции, добавлявшей запись в QDISTR)

Код: plaintext

1.
2.
3.
4.

SQL> select max(trn_id) from qstorned;

                  MAX
=====================
               528296

(это - номер транзакции, УДАЛЯВШЕЙ запись из QDISTR'a, т.к. она же добавляла её в QSTORNED; таков алгоритм).

==> новых транзакций после этого было больше тысячи.
И они, надо полагать, сдвигали OST, он же стал в итоге = 529193.
Полного дисконнекта не было, молотилки были просто остановлены (все "самозавершились" нефорсированными роллбаками).
А что, нужен был еще и полный дисконнект ?

...

Рейтинг:

0 / 0

08.07.2014, 16:26

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690817

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ТаблоидИ они, надо полагать, сдвигали OST, он же стал в итоге = 529193.Ну так он мог таким стать совсем не сразу.
ТаблоидА что, нужен был еще и полный дисконнект ?Как раз полный дисконнект не даёт шансов поработать фоновому сборщику и сбрасывает накопленную им инф-цию.

...

Рейтинг:

0 / 0

08.07.2014, 16:46

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690844

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

А такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ? Ибо "заранее знает", в каких страницах мусор есть и сразу туда лезет - так или нет ?
(я к тому, что если так, то поставлю gfix -h 1000 - и "пущай полетает", вдруг попустит :))

...

Рейтинг:

0 / 0

08.07.2014, 16:58

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690875

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

ТаблоидА такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ?Не должен, а может. Чувствуешь разницу ?

...

Рейтинг:

0 / 0

08.07.2014, 17:19

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690899

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hvladТаблоидА такой вопрос: свип в 3.х - он ведь должен гораздо быстрее работать, чем в 2.х ?Не должен, а может. Чувствуешь разницу ?Что-то не очень чую... Что значит "может" и при каких обст-вах "не сможет" ?
Вот, к примеру, nbackup - вон какой шустрый стал в 3.х, загляденье просто. Лопатит только изменённые страницы вместо всей базы.
А свип что же ?

...

Рейтинг:

0 / 0

08.07.2014, 17:38

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690912

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Таблоид,

ты sweep со сборкой мусора не путай. sweep однозначно должен быть быстрее.

...

Рейтинг:

0 / 0

08.07.2014, 17:45

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38690915

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Симонов Денисты sweep со сборкой мусора не путай. sweep однозначно должен быть быстрее.быстрее, чем ЧТО ? чем фоновый сборщик ?

...

Рейтинг:

0 / 0

08.07.2014, 17:48

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691013

Гаджимурадов Рустам

Участник

Сообщения: 64 024

Рейтинг: 0 / 0

Чем грузины. Смешной топик, ей-Богу.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

08.07.2014, 18:48

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691081

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Таблоид,

чем sweep в 2.5 конечно.

...

Рейтинг:

0 / 0

08.07.2014, 20:00

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691103

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Симонов Денисчем sweep в 2.5 конечно.я из этого:авторты sweep со сборкой мусора не путай- подумкал, что ты говоришь про другое.

...

Рейтинг:

0 / 0

08.07.2014, 20:25

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691177

Симонов Денис

Участник

Откуда: Рязань

Сообщения: 11 624

Рейтинг: 0 / 0

Дык это был ответ на
ТаблоидА свип что же ?
причём ранее шёл разговор о фоновом сборщике мусора, которые к sweep почти никакого отношения не имеет.
Насколько я понял из презентаций именно sweep должен быть намного быстрее за счёт флана "без мусора".

...

Рейтинг:

0 / 0

08.07.2014, 22:30

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691214

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Так-с. Продолжаем разговор :-)

Имеется вот такой результатик поиска "случайного 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

       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

08.07.2014, 23:33

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691235

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

ТаблоидКак по этим цифиркам понять, сколько раз движок прыгал на новые страницы данных и, след., создавал себе random IO ?
(хотя никаких reads'ов, как видим, не показано)
ты сам себе ответил. I/O - это reads/writes. Нет чтений - нет никакого I/O, хоть рандомного, хоть последовательного. Сколько раз мне еще это надо написать?

...

Рейтинг:

0 / 0

08.07.2014, 23:51

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691237

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Тогда безумно не хватает чего-то, что могло бы объяснить вот это:Таблоид

Код: plaintext

 15148 ms , 386497 fetch(es)

Я третий месяц не могу понять, куда еще рыть, чтобы хоть как-то уменьшить эти дикие значения.
Причём, для их получения вовсе не надо запускать 200 аттачей. И 5-10 достаточно + подождать минут 5, пока они "в раж не войдут".

...

Рейтинг:

0 / 0

08.07.2014, 23:54

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

gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?

#38691245

dimitr

Участник

Откуда: PNZ

Сообщения: 7 059

Рейтинг: 0 / 0

во-первых, мне не нравится вьюха в плане. Она должна быть раскручена до таблиц. Высылай мне пример. Ну и 15 сек я бы тоже искал внутри вьюхи, ибо такой запрос не может генерить 106941 индексных чтений, там явно внутри что-то накручено.

...

Рейтинг:

0 / 0

09.07.2014, 00:06

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

29 сообщений из 29, показаны все 2 страниц

все

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

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

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

start [/forum/topic.php?all=1&fid=40&tid=1563479]:	0ms
get settings:	9ms
get forum list:	15ms
check forum access:	4ms
check topic access:	4ms
track hit:	228ms
get topic data:	9ms
get forum data:	2ms
get page messages:	46ms
get tp. blocked users:	1ms
others:	242ms

total:	560ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы