powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
21 сообщений из 71, страница 3 из 3
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531269
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladтак и запишем - безнадёжен.ну и ладно, записывай :-)
Только я напоследок еще разок стрельну.
Повторил тест для SC, заполнение таблицы с единственным полем, ts(id int), БЕЗ индексов, 95 млн строк. Буфер прежний, 16384.

Сопоставил gstat -r итоговой базы:
data pages = 1'171'352
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
TS (129)
    Primary pointer page: 206, Index root page: 207
    Total formats: 1, used formats: 1
    Average record length: 9.00, total records: 94879506
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 6.00, compression ratio: 0.67
    Pointer pages: 1298, data page slots: 1171352
    Data pages: 1171352, average fill: 52%
    Primary pages: 1171352, full pages: 1171351, swept pages: 0
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 0
	40 - 59% = 1171352
	60 - 79% = 0
	80 - 99% = 0
- и вот только СЕЙЧАС вижу, что SuperClassic действительно передавал страницу в файловый кеш только тогда, когда она была заполнена почти до отказа.

Отношение числа записей в таблице к числу страниц в базе: 94879506 / 1171352 = 81.
Отношение размера страницы к длине записи с учетом несжимаемого заголовка: 4096 / (16 + 8*4) = ~85.

А это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов.
Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531271
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов.
Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще.Нет такого правила и быть не может. Ты его сам придумал, сам и опроверг.
Хватит уже, кто-то может в эту чушь поверить ведь...
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531274
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladНет такого правила и быть не может. Ты его сам придумал, сам и опроверг.
Хватит уже, кто-то может в эту чушь поверить ведь...посмотри аттач в здесь .мнупри вставке 6.3 млн строк в таблицу и два её индекса счетчик writes дёргался 3.7 млн раз.

ЗЫ. Запустил 95 млн, но табличку эту, ts(x int), снабдил индексом. Пущай полетает, поглядим тогда в логи.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531465
Fr0sT-Brutal
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Таблоид,

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

isql_shell.bat - запускатель для isql, но можно и непосредственно isql использовать
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
@echo off

set CDir=%~dp0%
set User=SYSDBA
set Pass=masterkey
set DB=...alias...

"%CDir%\isql.exe" -q -u %User% -p %Pass% -nod %DB%



gen_cmd.bat - выводит все нужные команды в STDOUT
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
@echo off
// вместо бесконечного цикла можно сделать FOR
:cycle
echo select * from ...;
...
echo commit;

// здесь можно добавить паузу между запросами, вывод в лог и все, что угодно
goto :cycle



Run.bat - собственно запускает
Код: sql
1.
@gen_cmd.bat | isql_shell.bat
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531912
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидА это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов.
Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще.Нет такого правила и быть не может. Ты его сам придумал, сам и опроверг.
Хватит уже, кто-то может в эту чушь поверить ведь...Нну-с, "продолжаем разговор" (С) :-)
Сделал всё заново, на линухе.

SuperClassic, buffers = 1024, база с единственной таблицей ts(x int).
Вариант-1: добавление 95 млн строк в эту таблицу, когда для неё НЕТ индекса.
Вариант-2: то же самое, но предварительно создан неуникальный индекс по полю `x`.
Стейтмент добавления один и тот же:
Код: plaintext
insert into ts select mod(gen_id(g,1), 65535) from rdb$types,rdb$types,rdb$types,(select 1 i from rdb$types rows 6); commit; quit;

gstat -r (после заполнения таблицы 95 млн строками, вариант БЕЗ индекса):
Код: 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.
Database "/var/db/fb30/ts.fdb"
Database header page information:
        Flags                   0
        Generation              548
        System Change Number    0
        Page size               8192
        ODS version             12.0
        Oldest transaction      534
        Oldest active           535
        Oldest snapshot         535
        Next transaction        536
        Sequence number         0
        Next attachment ID      10
        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           Jan 16, 2014 14:11:55
        Attributes

    Variable header data:
        Sweep interval:         0
        *END*


Database file sequence:
File /var/db/fb30/ts.fdb is the only file

Analyzing database pages ...
TS (128)
    Primary pointer page: 156, Index root page: 161
    Total formats: 1, used formats: 1
    Average record length: 9.00, total records: 94879506
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 8.00, compression ratio: 0.89
    Pointer pages: 357, data page slots: 582088
    Data pages: 582088, average fill: 52%
    Primary pages: 582088, secondary pages: 0, swept pages: 0
    Empty pages: 5, full pages: 582082
    Fill distribution:
         0 - 19% = 5
        20 - 39% = 0
        40 - 59% = 582083
        60 - 79% = 0
        80 - 99% = 0

Таким обр., на одной странице базы размещается 163 записи таблицы.

За 1 сек до запуска стейтмента в другом окне был запущен запрос к mon$io_stats с регистрацией изменений mon$page_writes.
В третьем окне был запущен трейс с регистрацией активности только рабочего коннекта, выполняющего вставки.

ИТОГО.
Вариант-1 (в аттаче - лист "ins-NON-index-buf-1024"):
дельта значений в mon$io_stats.page_writes составила 572225, трейс показал сумму writes = 584422 (583403 по стейтменту и 1019 по коммиту). Это - очень хороший и пушистый результат: действительно видно, что SuperClassic выталкивал страницу в файловый кеш только когда она заполнена примерно 163 записями.

Вариант-2 (в аттаче - лист "ins-INDEXED-buf-1024"):
дельта значений в mon$io_stats.page_writes составила 62 794 292, трейс показал сумму writes = 62 795 289 (62794271 по стейтменту и 1018 по коммиту).
Делим общее число записей в базе и (такое же) число ключей в индексе на 62 795 000: (94879506+94879506) / 62795000 - получаем результат около 3. То есть, на каждые три новых записи в таблице и столько же ключей в индексе - и две передачи в файловый кеш из страничного буфера.

В где я ошибаюсь ?
ЗЫ. сырые логи трейса и запроса к mon$-таблица, если надо, выложу на файлопомойку.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531958
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВ где я ошибаюсь ?Что ты хочешь доказать ?

ps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге
это же МАРАЗМ в данном случае
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531973
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидВ где я ошибаюсь ?Что ты хочешь доказать ?я ничего не доказываю, просто результаты привожу. И хотел бы увидеть объяснение им.

hvladps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге
это же МАРАЗМ в данном случаеОбоснуй, плз. Не понимаю, почему разглядывание дельт в mon$iostats стало маразмом в ДАННОМ варианте.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531989
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидя ничего не доказываю, просто результаты привожу.Это такое новое развлечение: ой, я выполнил запрос - смотрите все ! Ой, ещё один, смотрите же скорее !
?

ТаблоидИ хотел бы увидеть объяснение им.Тебе всё уже объяснили. Новых вопросов ты не задаёшь. Объяснения не понимаешь.
Тебе не кажется, что кто-то ходит по кругу ?

Таблоидhvladps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге
это же МАРАЗМ в данном случаеОбоснуй, плз. Не понимаю, почему разглядывание дельт в mon$iostats стало маразмом в ДАННОМ варианте.Потому что для одного запроса они не могут отличаться от итогового результата что в трейсе, что в isql.
Ты везде ссылаешься на сумму этих дельт - так на кой они тебе (нет - нам тут!) вообще нужны ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532035
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladЭто такое новое развлечение: ой, я выполнил запрос - смотрите все ! Ой, ещё один, смотрите же скорее !Да, ты угадал. Разумеется, это развлечение. Скорее смейтесь все, дабы я провалился от стыда и больше так не никогда делал. А смотреть в приаттаченные результаты - даже не вздумайте, там бред один. Ога.

hvladдля одного запроса они не могут отличаться от итогового результата что в трейсе, что в isql.
Ты везде ссылаешься на сумму этих дельт - так на кой они тебе (нет - нам тут!) вообще нужны ?Ты не читаешь то, что я спрашиваю.
Я не сравниваю сумму дельт в mon$io_stats с трейсом! Они там вместе приведены просто для верности: проверяю сам себя, дабы избежать ошибки копипаста "не с того места".
Меня интересует различие в отношении числа добавляемых записей к числу writes , когда вставки идут 1) без индексов, а затем 2) с индексом.
Интерес вызван не праздным любопытством, а потерей большого кол-ва времени на ожидание результатов известных тебе скриптов.

Для варианта вставки в не- индексированную таблицу это отношение (163) выглядит действительно так, как говорилось выше: SC передаёт страницу базы в файловый кеш только когда она будет почти вся заполнена.
Для варианта вставки в таблицу + индекс отношение становится совершенно другим (около 3).

ТЫ МОЖЕШЬ ОБЪЯСНИТЬ ЭТО РАЗЛИЧИЕ ? БОЛЬШЕ МНЕ НИЧЕГО НЕ НУЖНО В ЭТОМ ТОПИКЕ.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532161
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТы не читаешь то, что я спрашиваюА что ты спрашиваешь ? Что ?! Где вопрос ?

Ты так заспамил свои же сообщения, что найти в них зерно - нереально.
Например, какое отношение имеют твои последние N писем к твоей же теме топика ?

ТаблоидМеня интересует различие в отношении числа добавляемых записей к числу writes Нет никакой прямой связи между этими двумя числами. Нет. НЕТ. НЕТ
Так понятно ?
У тебя страницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях.
И тебе на это неоднократно намекалось выше.
Но ты вбил себе в голову только страницы данных и не видишь ничего вокруг...

ТаблоидИнтерес вызван не праздным любопытством, а потерей большого кол-ва времени на ожидание результатов известных тебе скриптов.Я тебе уже сказал 100500 раз - ты не найдёшь эту причину в статистике ФБ.
Ты читаешь то, что тебе пишут ???
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532228
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladстраницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях.

И тебе на это неоднократно намекалось выше.
Но ты вбил себе в голову только страницы данных и не видишь ничего вокруг...Я как раз вижу , что при записи именно индексных страниц показатель writes меняется, причём радикально.
Надо добавить 95 млн записей и столько же ключей (пусть это будет в ДЕСЯТЬ раза больше инфы, чем без индекса), а writes увеличивается в 62795289 / 584422 - больше чем в 100 раз!

Если ключ индекса состоит из одного int-поля и в таблицу добавляется три записи, то сколько новых индексных страниц должны добавиться ? Или (что скорее всего) сколько раз он должен обновить *одну и ту же* индексную страницу ?

hvladты не найдёшь эту причину в статистике ФБ.Ты читаешь то, что тебе пишут ???Да, именно поэтому хочу выяснить это У ТЕБЯ, а не разглядывая статистику. Больше на Земном шаре всё равно никто не ответит.
На каком языке еще надо объяснять мой вопрос, чтобы он был наконец-то понят ?...
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532240
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

hvladстраницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532252
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид Или (что скорее всего) сколько раз он должен обновить *одну и ту же* индексную страницу ?
при вставке в data pages перечитывать особо ничего не надо, а вот при обновлении индексов - надо. То есть, листовые страницы выпадают из кэша и их надо перечитывать, а еще и есть такое понятие как "расщепление страниц" b-tree при вставке ключей.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532258
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидсколько новых индексных страниц должны добавитьсяgstat -r
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532429
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvлистовые страницы выпадают из кэша и их надо перечитывать, а еще и есть такое понятие как "расщепление страниц" b-tree при вставке ключей.hvladТаблоидсколько новых индексных страниц должны добавитьсяgstat -rВ общем, имею вот что сказать.
0) База создана со страницей = 8192, подключение имеет кеш = 16384 страницы. ФБ работает в режиме SuperClassic. FW = OFF.
1) в таблицу ts(x int) с единственным индексом по этому полю было предварительно добавлено ~95 млн записей;
2) в базе создана вьюха для просмотра снимка mon$-статистики:
Код: 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.
create or alter view vmon as
select
      current_time dts
      -- mon$attachments:
      ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
      ,a.mon$remote_address remote_IP
      ,a.mon$attachment_id attach_id
      ,a.mon$user mon_user
      ,a.mon$stat_id       stat_id
      ,a.mon$server_pid    server_PID
      ,a.mon$remote_pid    remote_PID
      -- mon$memory_usage:
      ,u.mon$memory_used used_memory
      ,u.mon$memory_allocated alloc_by_OS
      -- mon$io_stats:
      ,i.mon$page_reads reads
      ,i.mon$page_writes writes
      ,i.mon$page_fetches fetches
      ,i.mon$page_marks marks
      -- mon$record_stats:
      ,r.mon$record_seq_reads seq_reads
      ,r.mon$record_idx_reads idx_reads
      ,r.mon$record_inserts ins_cnt
      ,r.mon$record_updates upd_cnt
      ,r.mon$record_deletes del_cnt
      ,r.mon$record_backouts bk_outs
      ,r.mon$record_purges purges
      ,r.mon$record_expunges expunges
      -- aux info:
      ,right(a.mon$remote_process,30) remote_process
      -- mon$statements:
      --,left(cast(s.mon$sql_text as varchar(32760)),50) sql_txt
    from mon$attachments a
    --left join mon$statements s on a.mon$attachment_id = s.mon$attachment_id
    left join mon$memory_usage u on a.mon$stat_id=u.mon$stat_id
    left join mon$io_stats i on a.mon$stat_id=i.mon$stat_id
    left join mon$record_stats r on a.mon$stat_id=r.mon$stat_id
    where
    --a.mon$state=1 and
    a.mon$attachment_id<>current_connection
;
3) запущен (для верности) трейс.
4) снята статистика базы ПЕРЕД вставкой 100 строк:
index ts_x: leaf buckets: 105200, nodes: 94879926
Код: 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.
Database header page information:
        Flags                   0
        Generation              125
        System Change Number    0
        Page size               8192
        ODS version             12.0
        Oldest transaction      93
        Oldest active           94
        Oldest snapshot         94
        Next transaction        95
        Sequence number         0
        Next attachment ID      28
        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           Jan 16, 2014 14:11:55
        Attributes

    Variable header data:
        Sweep interval:         0
        *END*


Database file sequence:
File /var/db/fb30/ts.fdb is the only file

Analyzing database pages ...
TS (128)
    Primary pointer page: 156, Index root page: 161
    Total formats: 1, used formats: 1
    Average record length: 9.00, total records: 94879926
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 8.00, compression ratio: 0.89
    Pointer pages: 357, data page slots:  582088 
    Data pages: 582088, average fill: 52%
    Primary pages: 582088, secondary pages: 0, swept pages: 0
    Empty pages: 2, full pages: 582085
    Fill distribution:
         0 - 19% = 2
        20 - 39% = 1
        40 - 59% = 582085
        60 - 79% = 0
        80 - 99% = 0

    Index TS_X (0)
        Root page: 7314, depth: 3,  leaf buckets: 105200, nodes: 94879926 
        Average node length: 5.76, total dup: 94814391, max dup: 1447
        Average key length: 2.00, compression ratio: 1.84
        Average prefix length: 3.68, average data length: 0.00
        Clustering factor: 94879926, ratio: 1.00
        Fill distribution:
             0 - 19% = 153
            20 - 39% = 19
            40 - 59% = 65789
            60 - 79% = 13364
            80 - 99% = 25875


Далее:

session #1.

Код: plaintext
/opt/fb30/bin/isql localhost/3330:ts

session #2

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
$ isql localhost/3330:ts
Database:  localhost/3330:ts
SQL> set list on; commit; select * from vmon;
. . .
READS                           42
WRITES                          3
FETCHES                         1038
MARKS                           3
SEQ_READS                       430
IDX_READS                       17
. . .

session #1
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> set stat on; insert into ts select mod(gen_id(g,1), 65535) from rdb$types rows 100; commit;
Current memory = 144749520
Delta memory = 529056
Max memory = 144822104
Elapsed time= 0.01 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 502
Writes = 0
Fetches = 1569
Current memory = 144710696
Delta memory = -38824
Max memory = 144822104
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 2
Writes = 106
Fetches = 2

session #2
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> set list on; commit; select * from vmon;
. . .
READS                           546
WRITES                          109
FETCHES                         2609
MARKS                           308
SEQ_READS                       530
IDX_READS                       43
INS_CNT                         100
. . .
Trace (просто для инфы, никаких сравнений ни с чем!):
Код: 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.
2014-01-20T21:02:06.8210 (20813:0x7f6a9044f1e0) EXECUTE_STATEMENT_FINISH
        ts (ATT_30, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:23111
                (TRA_97, CONCURRENCY | WAIT | READ_WRITE)

Statement 56:
-------------------------------------------------------------------------
insert into ts select mod(gen_id(g,1), 65535) from rdb$types rows 100
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$TYPES NATURAL)
0 records fetched
      3 ms, 466 read(s), 1363 fetch(es), 303 mark(s)

Table                             Natural     Index    Update    Insert  
xpunge
*************************************************************************
******
RDB$TYPES                             100                                

TS                                                                  100  


2014-01-20T21:02:06.8220 (20813:0x7f6a9044f1e0) COMMIT_TRANSACTION
        ts (ATT_30, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:23111
                (TRA_97, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 1 read(s), 105 write(s), 1 fetch(es), 1 mark(s)
Снимаю статистику базы ПОСЛЕ вставки 100 строк:
leaf buckets: 105200, nodes: 94880026
Код: 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.
Analyzing database pages ...
TS (128)
    Primary pointer page: 156, Index root page: 161
    Total formats: 1, used formats: 1
    Average record length: 9.00, total records: 94880026
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 8.00, compression ratio: 0.89
    Pointer pages: 357, data page slots:  582088 
    Data pages: 582088, average fill: 52%
    Primary pages: 582088, secondary pages: 0, swept pages: 0
    Empty pages: 1, full pages: 582086
    Fill distribution:
         0 - 19% = 2
        20 - 39% = 0
        40 - 59% = 582086
        60 - 79% = 0
        80 - 99% = 0

    Index TS_X (0)
        Root page: 7314, depth: 3,  leaf buckets: 105200, nodes: 94880026 
        Average node length: 5.76, total dup: 94814491, max dup: 1447
        Average key length: 2.00, compression ratio: 1.84
        Average prefix length: 3.68, average data length: 0.00
        Clustering factor: 94880026, ratio: 1.00
        Fill distribution:
             0 - 19% = 153
            20 - 39% = 19
            40 - 59% = 65789
            60 - 79% = 13364
            80 - 99% = 25875
(насколько понимаю, неизменное число leaf buckets = 105200 означает, что расщеплений не было)

Число страниц с данными не изменилось (582088).
Сколько ФБ добавил новых ИНДЕКСНЫХ страниц, я по gstat -r не вижу. Пролейте свет кто-нить, как это можно определить.

По трейсу и дельтам в mon$io_stats.page_writes получается, что:
1) либо ФБ изменил около 100 разных страниц на вставку 100 int-чисел. Но как такое может быть вообще ?
2) либо менялось меньшее число страниц с одними и теми же номерами, но они бесконца вытеснялись , оттого и writes ~100. Но это тоже выгляит нереальным, т.к. страничный кеш = 16384 - он покрывает все эти разности (fetshes2-fetches1 + writes2-writes2 + reads2-reads1) - как бык овцу, тут и считать ничего не надо.

Если есть третий вариант, то это вопрос уже к корректности статистики.
Такие вот делы.

Дальше можете обзывать меня как хотите, посылдать проспаться, пинать ногами и прочая.
Только объясните вышеприведенное, пож-ста.

PS. Блин я этот тест никогда не забуду, чтоб его об тумбочку!..
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532544
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид1) либо ФБ изменил около 100 разных страниц на вставку 100 int-чисел.Дошло ! Наконец-то ! Пойду - напьюсь

ТаблоидНо как такое может быть вообще ?Не, рано радуюсь :'(

Разных ключей у тебя сколько ? Ответ - 65535
Листовых страниц в индексе сколько ? leaf buckets: 105200
Каждый ключ занимает сколько ? Более полутора страниц.
Т.е. на каждой странице может быть 1 или 2 разных ключа.
Какие ключи ты вставляешь ? Ответ - разные ! РАЗНЫЕ !
Куда ты их вставляешь ? В конец таблицы, т.е. recno будут максимальные.
Так в какое место в цепочке дубликатов попадут новые ключи ? В конец каждой цепочки.
Так сколько листовых страниц мы запачкаем сотней разных ключей ? А ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532559
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladРазных ключей у тебя сколько ? Ответ - 65535
Листовых страниц в индексе сколько ? leaf buckets: 105200
Каждый ключ занимает сколько ? Более полутора страниц.
Т.е. на каждой странице может быть 1 или 2 разных ключа.Ну-ка стой! Как это полторы страницы (12 КБ!) на 1 фигов ключик, который содержит в себе int-число, плюс номер записи туда прилепить, ну пусть еще и с "заголовком" каким-нибудь (или как там его звать) ?..
ЕЯПП, ты поделил 105200 на число уникальных ключей. А почему не на ОБЩЕЕ число ключей, которое 95 млн ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532564
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladРазных ключей у тебя сколько ? Ответ - 65535
Листовых страниц в индексе сколько ? leaf buckets: 105200
Каждый ключ занимает сколько ? Более полутора страниц.
Т.е. на каждой странице может быть 1 или 2 разных ключа.Ну-ка стой! Как это полторы страницы (12 КБ!) на 1 фигов ключик, который содержит в себе int-число, плюс номер записи туда прилепить, ну пусть еще и с "заголовком" каким-нибудь (или как там его звать) ?..
ЕЯПП, ты поделил 105200 на число уникальных ключей. А почему не на ОБЩЕЕ число ключей, которое 95 млн ?Пардон, забыл я про рисунок Анны в эпизодах, где индексы. С этим вариантом, когда дубликатов полно, вроде бы прояснилось. Остался вариант с уникальным индексом.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532578
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидОстался вариант с уникальным индексом.Всё ясно. Дубликаты ключей - Мировое зло.
Та же база+таблица, 95 млн строк, только залиты они были так: insert into ... select gen_id(g,1) from ...

В итоге:
isql
Код: 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.
SQL> show sequ;
Generator G, current value is 94879506
Generator GDETL, current value is 100000
Generator GMAIN, current value is 1000
SQL> set stat on; insert into ts select gen_id(g,1) from rdb$types rows 100; commit;
Current memory = 144739120
Delta memory = 287456
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 388
Writes = 0
Fetches = 1553
Current memory = 144703496
Delta memory = -35624
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 2
Writes = 7
Fetches = 2
SQL>
SQL> set stat on; insert into ts select gen_id(g,1) from rdb$types rows 100; commit;
Current memory = 144737920
Delta memory = 23336
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 1
 Writes = 0 
Fetches = 1011
Current memory = 144703496
Delta memory = -34424
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 2
 Writes = 7 
Fetches = 2
SQL> set stat on; insert into ts select gen_id(g,1) from rdb$types rows 100; commit;
Current memory = 144737920
Delta memory = 23336
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 0
Writes = 0
Fetches = 1006
Current memory = 144703496
Delta memory = -34424
Max memory = 144811720
Elapsed time= 0.00 sec
Cpu = 0.00 sec
Buffers = 16384
Reads = 2
 Writes = 5 
Fetches = 2
trace
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
insert into ts select gen_id(g,1) from rdb$types rows 100
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$TYPES NATURAL)
0 records fetched
      2 ms, 365 read(s), 1363 fetch(es), 303 mark(s)

Table                             Natural     Index    Update    Insert   
xpunge
**************************************************************************
******
RDB$TYPES                             100                                 

TS                                                                  100   


2014-01-21T00:50:14.7260 (26903:0x7f38483bacc8) COMMIT_TRANSACTION
        ts (ATT_18, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:27485
                (TRA_28, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 1 read(s),  6 write(s) , 1 fetch(es), 1 mark(s)
(остальные два запуска - практически то же самое)
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532604
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВсё ясно. Дубликаты ключей - Мировое зло.В твоём предыдущем тесте мировым злом был индекс на поле с guid - тут тоже дубликаты виноваты ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38532678
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ты про тест, который tmain=2 млн и tdetl=200 млн строк ? там просто были неверно выбраны "гарабиты": надо было поменьше раз в 10 на каждую таблицу, и всё прошло бы без шума и пыли, за 3-4 часа :-)

PS. насчет мирового зла - поправка: плохи не дубли, а большое кол-во цепочек, если они заканчиваются на разных страницах базы. Тогда действительно получается, что вставка 100 значений приводит к пачканию 300 страниц.
...
Рейтинг: 0 / 0
21 сообщений из 71, страница 3 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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