powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
71 сообщений из 71, показаны все 3 страниц
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530448
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all.

Дано: новая база (alias = huge_noext), page_size=8K, FW = OFF, buffers=512K, LI-T3.0.0.30824, SuperServer.

Изменённые параметры firebird.conf:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
$ grep "^[^#;]" firebird.conf
DefaultDbCachePages = 512K
FileSystemCacheThreshold = 1024K
AuthServer = Legacy_Auth,Srp
AuthClient = Legacy_Auth,Srp,Win_Sspi
UserManager = Legacy_UserManager
BugcheckAbort = 1
WireCrypt = Disabled
RemoteServicePort = 3333

В базе создаются мастер и деталь таблицы, связанные FK. Кроме того, на каждую таблицу навешено еще по 2 "простых" индекса.
Запускаю скрипт, вставляющий большое число строк (2 млн в мастер таблицу и 200 млн в деталь):
Код: 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.
--/*
set autoddl on;
show version;
commit;
set term ^;create or alter procedure sp_huge_ext as begin end^set term ;^
commit;
recreate table tdetl(id int); commit;
recreate table tmain(id int); commit;
recreate table tlog(id int); commit;

recreate sequence gmain;
recreate sequence gdetl;
recreate table tdetl(id bigint primary key using index tdetl_pk_idx, pid bigint, s01 varchar(36), s02 varchar(36));
recreate table tmain(id bigint primary key using index tmain_pk_idx, s01 varchar(36), s02 varchar(36));
recreate table tlog( gmain bigint, gdetl bigint, dts_before timestamp, dts_after timestamp, elapsed_ms computed by(datediff(millisecond from dts_before to dts_after)) );

alter table tdetl add constraint tdetl_fk foreign key(pid) references tmain using index tdetl_fk_idx;
create index tmain_s01 on tmain(s01);
create index tmain_s02 on tmain(s02);
create index tdetl_s01 on tdetl(s01);
create index tdetl_s02 on tdetl(s02);
commit;
set stat on;
set list on;
select * from mon$database;
commit;
set list off;
set stat off;
--*/

set term ^;
create or alter procedure sp_huge_ext(a_n_main int = -1) returns(msg varchar(100)) as
  declare n_main int = 2000000;
  declare n_detl int = 100; -- child records in tdetl per each parent row in tmain
  declare v_id bigint;
  declare i int;
  declare j int;
  declare verbose_step int=100;
  declare tx timestamp;
  declare tc timestamp;
  declare elapsed_ms_now int;
  declare elapsed_ms_min int = 999999999;
  declare elapsed_ms_max int = -1;
  declare msg4min varchar(25);
  declare msg4max varchar(25);
begin
  n_main=iif(a_n_main > 0, a_n_main, n_main);
  tx=cast('now' as timestamp);
  while(n_main>0) do begin
    j=verbose_step;
    while(j>0) do begin

        n_main = n_main-1; -- main counter

        insert into tmain(id, s01, s02)
        values( gen_id(gmain,1), uuid_to_char(gen_uuid()), uuid_to_char(gen_uuid()) )
        returning :j-1, id into j, v_id;

        i=n_detl;
        while (i>0) do
          insert into tdetl(id, pid, s01,s02)
          values( gen_id(gdetl,1), :v_id, uuid_to_char(gen_uuid()), uuid_to_char(gen_uuid()) )
          returning :i-1 into i;
    end -- j=verbose_step downto 1

    tc=cast('now' as timestamp);
    insert into tlog(gmain, gdetl, dts_before, dts_after)
    values( gen_id(gmain,0), gen_id(gdetl,0), :tx, :tc )
    returning elapsed_ms into elapsed_ms_now;

    if ( elapsed_ms_min > elapsed_ms_now ) then begin
      elapsed_ms_min=elapsed_ms_now;
      msg4min='min_ms='||elapsed_ms_min||' at '||left(right(tc,13),8);
    end

    if ( elapsed_ms_max < elapsed_ms_now ) then begin
      elapsed_ms_max=elapsed_ms_now;
      msg4max='max_ms='||elapsed_ms_max||' at '||left(right(tc,13),8);
    end

    tx=cast('now' as timestamp);

    msg=left(right(tx,13),8)||': gdetl='||right(cast(1000000000+gen_id(gdetl,0) as varchar(10)),9)||'  '||msg4min||'  curr_ms='||elapsed_ms_now||'  '||msg4max;
    suspend;

  end -- while (n_main>0)
end
^set term ;^
commit;

set transaction read write read committed record_version no wait;
select * from sp_huge_ext for update;
commit;
Запускаю во втором окне .sh, который делает 20 коннект-дисконнектов и снимает данные мониторинга с интервалом между выходом и повторным запуском = 10 сек:
askmon.sh
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
delay=10
fdb=huge_noext
fbport=3333
fbhome=/opt/fb30trnk
log=./logs/mon30_$(date +'%y%m%d_%H%M%S').log
err=./logs/mon30_$(date +'%y%m%d_%H%M%S').err
rm -f $log
while :
do
  echo -----------------------------------------------------------------------------------
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - starting quering mon tables
  echo check result in $log, errors in $err
  echo $fbhome/bin/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n i ...
  $fbhome/bin/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n \
                    -i askmon30.sql  2>>$err | sed -e "s/ \{1,\}$//" >>$log
  ls -la $log $err
  p=$delay # temply, 30.10.2013 1658, was: $(( $delay + RANDOM % 30))
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - done. Now take pause $p seconds. . .
  sleep $p
done
askmon30.sql
Код: 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.
set autoddl off;
set list off;
set blob on;
set width mon_user 20;
set width remote_process 30;
set width sql_txt 50;
set width remote_ip 15;
set width rn 3;
commit;
    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
    from mon$attachments a
        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$attachment_id<>current_connection
;

Скрипт отрабатывает 20 раз, вот фрагмент его лога:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
          DTS RN  REMOTE_IP          ATTACH_ID MON_USER                  STAT_ID   SERVER_PID   REMOTE_PID           USED_MEMORY           ALLOC_BY_OS                 READS                WRITES               FETCHES                 MARKS             SEQ_READS             IDX_READS               INS_CNT               UPD_CNT               DEL_CNT               BK_OUTS                PURGES              EXPUNGES REMOTE_PROCESS
============= === =============== ============ ==================== ============ ============ ============ ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ==============================
12:10:59.0000 1   <null>                    13 Cache Writer                   12        28998       <null>                  9672                131072                     0              32097624                     2                     1                     0                     0                     0                     0                     0                     0                     0                     0 <null>
12:10:59.0000 2   127.0.0.1                 14 SYSDBA                          5        28998        29279               1810928               3427992              30686726               4024446            2487716139             517814324                   319                   947              84215045                    57                    29                     9                     2                     0 /opt/fb30trnk/bin/isql
12:10:59.0000 3   <null>                    15 Garbage Collector              10        28998       <null>                188928                327680                     2                    91                  1474                   159                   502                     0                     0                     0                     0                     0                     3                    29 <null>


          DTS RN  REMOTE_IP          ATTACH_ID MON_USER                  STAT_ID   SERVER_PID   REMOTE_PID           USED_MEMORY           ALLOC_BY_OS                 READS                WRITES               FETCHES                 MARKS             SEQ_READS             IDX_READS               INS_CNT               UPD_CNT               DEL_CNT               BK_OUTS                PURGES              EXPUNGES REMOTE_PROCESS
============= === =============== ============ ==================== ============ ============ ============ ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ===================== ==============================
12:11:09.0000 1   <null>                    13 Cache Writer                   12        28998       <null>                  9672                131072                     0              32226473                     2                     1                     0                     0                     0                     0                     0                     0                     0                     0 <null>
12:11:09.0000 2   127.0.0.1                 14 SYSDBA                          5        28998        29279               1814120               3427992              30814107               4030330            2491296812             518546973                   319                   947              84334190                    57                    29                     9                     2                     0 /opt/fb30trnk/bin/isql
12:11:09.0000 3   <null>                    15 Garbage Collector              10        28998       <null>                188928                327680                     2                    91                  1474                   159                   502                     0                     0                     0                     0                     0                     3                    29 <null>

Этот лог далее затаскивается в эксель, из него удаляются лишние строки с заголовками и пропусками, после чего он упорядочивается по графам {MON_USER, DTS}.
Затем добавляется графа diffWrites, в которую пишутся разности значений графы WRITES (это алиас столба MON$IOSTATS.mon$page_writes).

Ну, и вот: диву даюсь. Получается так, что поток CACHE_WRITER'а пишет за каждые 10 сек по 60-80 тыс страниц. А основной поток, который инсертит в базу, пишет за то же время по 2...3 тысячи.

Чем это объяснить ?
(в аттаче - причёсанный эксельный лист; сравните там значения в графе diffWrites для групп строк с mon_user = cache_writer vs sysdba).
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530455
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а что именно тебе не нравится? Рабочий поток изменил страницу в кеше, пошел делать дальше свою работу, грязные страницы он писать на диск начнет только когда засрет весь кеш. А пока суть да дело, кешрайтер пишет грязные страницы сам, так что в кеше почти всегда остаются свободные буферы и рабочий поток не тормозится на ненужный I/O. Объем работы (с точки зрения CPU) у кешрайтера намного меньше, поэтому он успевает больше. А основной поток пока запись на страницу положит, пока две-три индексных страницы прочитает, пока ключ вставит...
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530459
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrОбъем работы (с точки зрения CPU) у кешрайтера намного меньше, поэтому он успевает больше. А основной поток пока запись на страницу положит, пока две-три индексных страницы прочитает, пока ключ вставит...Если так, то кешрайтер рано или поздно должен будет некоторое время сидеть сложа руки: он пишет в ДВАДЦАТЬ раз больше страниц, чем рабочий поток и должен когда-нить "догнать и перегнать Америку".
Значит, я могу сейчас запустить мониторинг на 2-3 часа и увидеть в его отчете длительные периоды с diffWrites = 0 - так ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530466
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кешрайтер пишет ровно столько, сколько рабочий поток пачкает. Отдыхать он будет когда хотя бы четверть кеша станет доступной для повторного использования. Если он успеет писать быстрее, чем рабочий поток пачкать, то да - периодически кешрайтер будет простаивать.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530469
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrкешрайтер пишет ровно столько, сколько рабочий поток пачкает. Отдыхать он будет когда хотя бы четверть кеша станет доступной для повторного использования. Если он успеет писать быстрее, чем рабочий поток пачкать, то да - периодически кешрайтер будет простаивать.Какой интервал между снимками посоветуешь сделать, чтобы это увидеть ? Мну кажется, что 10 сек - слишком большой.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530487
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКакой интервал между снимками посоветуешь сделать, чтобы это увидеть ? Мну кажется, что 10 сек - слишком большой.Ты не теми единицами оперируешь :) Он может простаивать, например, по 1-10 мс между циклами записи - микроскоп бери :)

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

Чего узнать-то хочешь ?фигасе... про 1...10 мс - не знал. Это сильно меняет дело :-)
А узнать хотел, как всегда, одно: что так тормозит добавление записей на странице 8К (да и на 16 К будет, наверное, то же самое).
При том, что уже writes barrier = 0 и выставлен noatime. Осталось только data=writeback добавить, но это уже крайняк.

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

можешь этот же тест повторить для классика ? Там нет cache writer'а, сравним статистику.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530510
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladможешь этот же тест повторить для классика ? Там нет cache writer'а, сравним статистику.Сейчас не смогу - заливка еще идёт. А обязательно ли для Classic'a ? Нельзя ли для SC ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530513
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидhvladможешь этот же тест повторить для классика ? Там нет cache writer'а, сравним статистику.Сейчас не смогу - заливка еще идёт. А обязательно ли для Classic'a ? Нельзя ли для SC ?Нет, срочно сейчас - всё бросай !
Есс-но, можно и для SC.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530522
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladможно и для SC.Да, но там вопрос об интервале между запросами к монам - очень актуальный, в отличие от супера. Каким его задать ?

PS. А сохраню-ка сюда еще и батничек, который генерит .sql-скрипт, выполняющий без переконнектов любое число таких запросов к mon$-таблицам, который показан выше. И с любой паузой между окончанием N-го запроса и началом (N+1)-го.
То есть, если ввести вот это:
Код: plaintext
mkaskmon.bat 10 0.5
- то будет сгенерён вот такой монстрик:
Код: 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.
-- created auto, do NOT edit!
-- run: $fbhome/bin/isql localhost/$fbport:$fdb -pag 999 -n -i askmon.tmp 2>>$err | sed -e "s/ \{1,\}$//" >>$log 
set autoddl off;
set list off;
set blob on;
set width dts 12;
set width mon_user 20;
set width remote_process 30;
set width sql_txt 50;
set width remote_ip 15;
set width rn 3;
set heading off;
select substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts,'iter #'||1 msg from rdb$database;
set heading on;
 commit; 
select
     substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts
     -- mon$attachments:
     ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
     . . . 
;
where
      a.mon$attachment_id<>current_connection
;
shell sleep 0.5;


set heading off;
select substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts,'iter #'||2 msg from rdb$database;
 commit; 
select
     substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts
     -- mon$attachments:
     ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
   . . . 
where
      a.mon$attachment_id<>current_connection
;
shell sleep 0.5;
. . . и так далее 10 раз . . .
- и будет вроде как имитация работы в isql без переконнекта .

Вот этот батник (запускать на винде, копировать затем скрипт askmon.tmp на линух):
mkaskmon.bat
Код: 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.
@echo off
cls
set sql=askmon.tmp
set n=%1
set p=%2
if .%1.==.. set n=5
if .%2.==.. set p=10

echo -- created auto, do NOT edit!>%sql%
echo -- run: $fbhome/bin/isql localhost/$fbport:$fdb -pag 999 -n -i %sql% 2^>^>$err ^| sed -e "s/ \{1,\}$//" ^>^>$log >>%sql%
echo set autoddl off;>>%sql%
echo set list off;>>%sql%
echo set blob on;>>%sql%
echo set width dts 12;>>%sql%
echo set width mon_user 20;>>%sql%
echo set width remote_process 30;>>%sql%
echo set width sql_txt 50;>>%sql%
echo set width remote_ip 15;>>%sql%
echo set width rn 3;>>%sql%
for /l %%x in (1, 1, %n%) do (
  echo set heading off;>>%sql%
  echo select substring(cast(current_timestamp as varchar(25^)^) from 12 for 12^) dts,'iter #'^|^|%%x msg from rdb$database;>>%sql%
  if .%%x.==.1. echo set heading on;>>%sql%
  echo commit;>>%sql%
  echo select>>%sql%
  echo      substring(cast(current_timestamp as varchar(25^)^) from 12 for 12^) dts>>%sql%
  echo      -- mon$attachments:>>%sql%
  echo      ,cast^(row_number^(^)over^(order by mon$attachment_id^) as char^(3^)^) rn>>%sql%
  echo      ,a.mon$remote_address remote_IP>>%sql%
  echo      ,a.mon$attachment_id attach_id>>%sql%
  echo      ,a.mon$user mon_user>>%sql%
  echo      ,a.mon$stat_id       stat_id>>%sql%
  echo      ,a.mon$server_pid    server_PID>>%sql%
  echo      ,a.mon$remote_pid    remote_PID>>%sql%
  echo      -- mon$memory_usage:>>%sql%
  echo      ,u.mon$memory_used used_memory>>%sql%
  echo      ,u.mon$memory_allocated alloc_by_OS>>%sql%
  echo      -- mon$io_stats:>>%sql%
  echo      ,i.mon$page_reads reads>>%sql%
  echo      ,i.mon$page_writes writes>>%sql%
  echo      ,i.mon$page_fetches fetches>>%sql%
  echo      ,i.mon$page_marks marks>>%sql%
  echo      -- mon$record_stats:>>%sql%
  echo      ,r.mon$record_seq_reads seq_reads>>%sql%
  echo      ,r.mon$record_idx_reads idx_reads>>%sql%
  echo      ,r.mon$record_inserts ins_cnt>>%sql%
  echo      ,r.mon$record_updates upd_cnt>>%sql%
  echo      ,r.mon$record_deletes del_cnt>>%sql%
  echo      ,r.mon$record_backouts bk_outs>>%sql%
  echo      ,r.mon$record_purges purges>>%sql%
  echo      ,r.mon$record_expunges expunges>>%sql%
  echo      -- aux info:>>%sql%
  echo      ,right(a.mon$remote_process,30^) remote_process>>%sql%
  echo      -- mon$statements:>>%sql%
  echo      --,left(cast(s.mon$sql_text as varchar(32760^)^),50^) sql_txt>>%sql%
  echo from mon$attachments a>>%sql%
  echo       left join mon$memory_usage u on a.mon$stat_id=u.mon$stat_id>>%sql%
  echo       left join mon$io_stats i on a.mon$stat_id=i.mon$stat_id>>%sql%
  echo       left join mon$record_stats r on a.mon$stat_id=r.mon$stat_id>>%sql%
  echo where>>%sql%
  echo       a.mon$attachment_id^<^>current_connection>>%sql%
  echo ;>>%sql%
  if .%%x.==.%n%. exit
  echo shell sleep %p%;>>%sql%
  echo.>>%sql%
  echo.>>%sql%
)
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530526
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидтам вопрос об интервале между запросами к монам - очень актуальный
при одном рабочем коннекте?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530529
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидтам вопрос об интервале между запросами к монам - очень актуальный
при одном рабочем коннекте?Про один коннект не могу пока сказать - проверить надо, какой там отклик будет при аналогичных вставках. А вот когда idx_under_load грузил, то там была видна сильная разница (в пользу SS).
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530647
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сгенерил скриптик на 7200 итераций, с паузой 0.5 сек между окончанием текущей и commit + select следующей.
Затем всё также вытряхнул в эксель, оставил там первые 7000 строк (иначе нельзя сюда приаттачить .rar). Далее провёл всё теже манипуляции со значениями в графе WRITES для CW.
Может, он и отдыхал в какие-то моменты по 1...10 мс, не знаю.
Но эксель показывает, что он всё время со следующим старанием РАБОТАЛ:
1) строк, в которых кол-во writes в диапазоне от 100 до 1000 - около 100;
2) от 1001 до 2000 - около 450;
3) от 2001 до 3000 - около 1000;
4) от 3001 до 3000 - около 1100;
. . .
5) свыше 10'000 - около 700 строк.

Значительная доля строк показывает, что CW передавал в кеш линуха от 6 до 9 тыс страниц каждые 500 мс. То есть, моменты отдыха этого потока если и были, то какие-то нечастые, ИМХО.

Но главный вопрос в следующем.

С базой работает только ОДИН аттач (в мониторинге - поток от sysdba).
Разность значений writes для него на момент начала и окончания теста = ~1.4 млн.
А разность значений writes для Cache Writer'a за эти же моменты времени составляет 40 млн.

Я не могу осилить причину этого дифферента %-/
В аттаче - эксель для CW. В следующем посте - для рабочего потока от SYSDBA.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530648
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
окончание предыдущего поста - см второй аттач, для рабочего потока от SYSDBA.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530706
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
... а еще вопрос: если я начинаю вставку (скрипт см тут) в пустую базу небольшого числа строк (20'000 в tmain, 2'000'000 в tdetl) - то может ли поток CacheWriter'a иметь нулевое изменение статистики в mon$iostats.writes ? (см аттач)
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530709
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидскрипт см тутимелся в виду стартовый пост, вызов ХП с входным параметром = 20000.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530723
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
отгадку можно найти в моих ответах выше. Пока рабочий поток не испачкает своими вставками 3/4 кеша, то кешрайтер не пошевелится писать что-либо на диск.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530763
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrотгадку можно найти в моих ответах выше. Пока рабочий поток не испачкает своими вставками 3/4 кеша, то кешрайтер не пошевелится писать что-либо на диск.Да, но когда скрипт заканчивает свою работу commit'ом, кто-то же должен записать страницы на диск ? В отчете на момент после окончания скрипта значения writes для CW так и остаются прежними. И "кто" тогда передаёт данные в файловый кеш операционки из страничного кеша ФБ ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530789
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нескладуха какая-то со статистикой, КМК.
0) рестартовал ФБ, установил в database.conf на пустой базе нищенский кеш = 128 страниц;
1) запустил isql, выяснил ID его аттача; добавил в конфиг трейса фильтр на отлов событий только для этого attach_id;
2) запустил трейс;
3) запустил огромный скрипт, делающий без переконнектов снимки с мониторных таблиц и складывающий их в лог, с интервалом = 0.5 сек (пример его я приводил выше в этом топеге);
4) запустил на выполнение скрипт, добавляющий 20 тыс строк в tmain и 2 млн в tdetl:
Код: plaintext
1.
select * from sp_huge_ext(20000) for update;
commit;
5) дождался окончания работы ХП, после чего остановил также скрипт снимков мониторинга.

Далее смотрю статистику трейса:
99833 write(s)
Код: 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.
2014-01-19T01:26:06.1380 (19458:0x7f1cd9294d08) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/askmon_n.fdb (ATT_84, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:23275
                (TRA_2028, CONCURRENCY | WAIT | READ_WRITE)

Statement 172:
-------------------------------------------------------------------------------
select * from sp_huge_ext(20000) for update
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (SP_HUGE_EXT NATURAL)
200 records fetched
 422175 ms, 7850564 read(s), 99833 write(s), 58629037 fetch(es), 12358863 mark(s)

Table                             Natural     Index    Update    Insert    Delete
unge
*********************************************************************************
****
RDB$PAGES                                                            20          

RDB$INDICES                                       9                              

RDB$RELATION_CONSTRAINTS                          2                              

TDETL                                                           2000000          

TMAIN                                                             20000          

TLOG                                                                200          


Вытряхнул лог мониторинга в эскель (см аттач), причесал его там.
В итоге вижу в экселе, что дельта в графе writes между последними и первыми значениями:
1) для рабочего потока от SYSDBA: 99'907 - 5 = 99'902 - вполне объяснимое значение, близкое к данным трейса;
2) для Cache Writer'a: 4'124'841 - 0 = 4'124'841 страниц. Разница в 41 раз. Опять соотношение в 3..4 десятка раз.

Чего он (CW) делал в 40 раз больше, чем поток-молотилка ?!
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530790
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

тот, кто делает коммит, есс-но.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530792
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ты с SC\CS сравнил те же действия ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530795
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladтот, кто делает коммит, есс-но.Это делает коннект-молотилка. "Кому" он передаёт грязные страницы - непосредственно файловому кешу, получается ? (раз CW сидит без дела)
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530796
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТы с SC\CS сравнил те же действия ?Нет пока... всё еще с SS "борьба" идёт. Завтра, надеюсь, смогу и к Вильяму нашему Шекспиру SC подступиться.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530800
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид"Кому" он передаёт грязные страницы - непосредственно файловому кешу, получается ?Нет, он на деревню деду письма пишет.
У тебя какие-то совершенно дикие представления о том, как всё устроено... где ты их только берёшь ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530881
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоид"Кому" он передаёт грязные страницы - непосредственно файловому кешу, получается ?Нет, он на деревню деду письма пишет.
У тебя какие-то совершенно дикие представления о том, как всё устроено... где ты их только берёшь ? В mon$io_stats.page_writes, вестимо.
Я не понимаю ситуацию, при которой значение в этом столбе может оставаться постоянным (нулевым) для потока CacheWriter'a, пример тут .
И не понимаю также, почему в другом случае CW увеличил этот же счетчик на 4.1 млн, тогда как рабочий поток - только на 100 тыс.

Если не затруднит, объясни, плз, как такое может быть. Все скрипты приведены выше.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530901
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а я не понимаю, что можно было не понять в объяснениях выше. Писать страницы (page writes) может (а) рабочий поток при коммите, либо (б) рабочий поток при заполнении кеша, либо (в) кешрайтер при заполнении кеша. Соотношение (б) и (в) зависит от нагрузки, от размера кеша и от объема изменений. На разных тестах будут разные цифры. Но кто именно будет писать - абсолютно неважно, кешрайтер просто по мере возможности помогает рабочему потоку, беря часть I/O на себя. На SC/CS помогать некому, там все пишет рабочий поток (а + б).
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530907
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrкто именно будет писать - абсолютно неважно, кешрайтер просто по мере возможности помогает рабочему потоку, беря часть I/O на себя. На SC/CS помогать некому, там все пишет рабочий поток (а + б).Спасибо, теперь ясно.
Я пребывал в заблуждении: считал, что ВСЕ страницы всегда пишет только поток CW, а рабочий поток пишет только в страничный кеш, не более того.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530930
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

объясни, плз, еще одно.

В аттаче номе 123 некий стейтмент, запущенный в момент t1 и законченный в момент t2, приводит к 1000 writes в трейсе. А разность значений в mon$io_stats.page_writes для моментов t2 & t1 аттача 123 - совсем другая, не 1000.

Такое может быть ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530944
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

совсем другая - это сколько? Отличие небольшое или в разы?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530946
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrсовсем другая - это сколько? Отличие небольшое или в разы?Отличие в 40 раз. Тынц .
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38530947
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидdimitrсовсем другая - это сколько? Отличие небольшое или в разы?Отличие в 40 раз. Тынц .пардон, это не то совсем: там CW превышает статистику молотилки в 40 раз. Но всё равно интересно :-)
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531075
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТы с SC\CS сравнил те же действия ?сравнил статистику SS vs SC для следующего сценария:
1) база создается с нуля, FW = ON, page_size=4K, buffers = 128 ;
2) в базе создается генератор `g` и таблица:
Код: plaintext
1.
2.
3.
4.
5.
6.
SQL> show table t;
ID                              INTEGER Not Null
S01                             VARCHAR(36) Nullable
CONSTRAINT INTEG_2:
  Primary key (ID)
CONSTRAINT INTEG_3:
  Unique key (S01)

В таблицу заливается 305 тыс строк:
Код: plaintext
1.
SQL> insert into t select gen_id(g,1), uuid_to_char(gen_uuid()) from rdb$types,rdb$types,
CON> (select 1 i from rdb$types rows 5); commit;

Перед началом заливки:
1) в конфиге трейса ставится фильтр connection_id = <current_connection >
2) запускается огромный скрипт, делающий снимки мон-таблиц без переконнекта, с паузами = 1 сек (батник для его создания был приведен выше; скрипт содержит 7200 итераций, что должно хватать на время работы коннекта-молотилки и отследить его статистику).

Статистика по времени: SuperClassic оказался немного быстрее SuperServer'a.
Результаты см. в аттаче.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531079
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS-1. По трейсу и mon$iostats в SS наглядно, как общая статистика writes "перекочевала" из insert-стейтмента в cache_writer. Но деяния кешрайтера в трейсе вообще не отражаются

PS-2. Общая сумма разностей (по CW и рабочему потоку) в поле page_writes для SS оказывается меньше общего числа вставляемых в таблицу строк примерно на 6 тыс, а в SC аналогичное отличие составляет 10 тыс. Коммит выдает в трейсе около 60-70 writes (см аттач). Куда остальные тысячи подевались ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531105
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКуда остальные тысячи подевались ?
Тебе приходило в голову, что на одну страницу помещается несколько записей?.. И что SC
пишет страницу только когда она полностью заполнена, а у SS cache writer может ту же
станицу скинуть пару раз в недозаполненном состоянии?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531120
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидсравнил статистику SS vs SC для следующего сценария:
1) база создается с нуля, FW = ON, page_size=4K, buffers = 128 ;SS и буфер в 128 страниц ? Выкинь это всё сразу же.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531163
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидКуда остальные тысячи подевались ?Тебе приходило в голову, что на одну страницу помещается несколько записей?.. И что SC
пишет страницу только когда она полностью заполнена, а у SS cache writer может ту же
станицу скинуть пару раз в недозаполненном состоянии?..Причём тут число записей таблицы в одной странице базы ? У мну в 4096 байт должно быть floor(4096 / (16 + (4+36))), т.е. ~ около 70 записей (не помню точно, сколько байт занимает заголовок: не то 13, не то 17; взял 16) - дальше что ?
Если одна и та же страница меняется кешрайтером много раз, то результат должен быть обратным: сумма разностей mon$io_stats.page_writes будет больше , чем то, что показывает трейс.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531167
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидсравнил статистику SS vs SC для следующего сценария:
1) база создается с нуля, FW = ON, page_size=4K, buffers = 128 ;SS и буфер в 128 страниц ? Выкинь это всё сразу же.я намеренно сделал так, чтобы CW пришлось потрудиться.
Почему "выкинуть" и какой тогда буфер ставить ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531173
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

что ты тестируешь ? Какая у тебя цель ?
Откуда ты взял, что кол-во writes должно совпадать с кол-вом inserts ????
cache writer не меняет страницы, что за бред ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531175
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоиддальше что ?
Дальше пойди проспись, а потом точно сформулируешь: что именно "меньше" и чего именно оно
"меньше". В то ты уже начал говорить как Болтик.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531188
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоиддальше что ?Дальше пойди проспись, а потом точно сформулируешь: что именно "меньше" и чего именно оно "меньше". В то ты уже начал говорить как Болтик.я не пил с НГ и постарался сформулировать всё доходчиво; жаль, что тебе в лом открывать тот аттач с экселем.
На, картинку посмотри, может, быстрее допрёт...
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531191
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

тебя уже выше спросили: на кой ляд ты сравниваешь число вставленных строк с числом записанных страниц?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531200
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrтебя уже выше спросили: на кой ляд ты сравниваешь число вставленных строк с числом записанных страниц?Если они не должны быть равны, то... они не могут быть и настолько близкими, как тут (310 vs 315 тыс)!
Ибо в 1 страницу базы размером 4096 влезает десятки записей с полями int & varchar(36).
Да, там есть еще два индекса, но и там на 1 страницу влезает десятки ключей.
Если счетчик writes увеличивается только когда страница заполнится, то ввиду вышесказанного первое число скорее должно быть не 310 тысяч, а 31 тысяча.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531207
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

так бы оно и было, если бы ты не выставил кеш в дурацкие 128 страниц и не заставил бы этим кешрайтера писать страницы не дожидаясь их заполнения. О чем DS тебе сказал выше.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531210
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидсравнил статистику SS vs SC для следующего сценария:
1) база создается с нуля, FW = ON, page_size=4K, buffers = 128 ;SS и буфер в 128 страниц ? Выкинь это всё сразу же.повторил для буфера = 16384 (в SC так и в SS; FW вырубил).
Запрос:
Код: sql
1.
insert into t select gen_id(g,1), uuid_to_char(gen_uuid()) from rdb$types,rdb$types,(select 1 i from rdb$types rows 100)

(6.3 млн строк)

Трейс для SuperServer'a:
Код: plaintext
1.
2.
3.
4.
5.
  359886  ms, 3285251 read(s), 314387 write(s), 95597746 fetch(es), 26398164 mark(s)
Table                             Natural     Index    Update    Insert    Delete
**********************************************************************************
RDB$PAGES                                                           148
RDB$TYPES                         6325300
T                                                               6300100

Трейс для SuperClassic'a:
Код: plaintext
1.
2.
3.
4.
5.
  411584  ms, 3283975 read(s), 3689165 write(s), 95613976 fetch(es), 26397700 mark(s)
Table                             Natural     Index    Update    Insert    Delete
***********************************************************************************
RDB$PAGES                                                           148
RDB$TYPES                         6325300
T                                                               6300100
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531221
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrтак бы оно и было, если бы ты не выставил кеш в дурацкие 128 страницИ не сделал бы индекс по guid полю.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531223
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидповторил для буфера = 16384 (в SC так и в SS; FW вырубил).Всё, счастье настало ?
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531229
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тьфу, забыл эксель прилепить к предыдущему посту.
Смотрим аттач.

Там общая статистика по mon$iostats:
1) в SuperServer'e:
THREADTOTAL_DIFF_WRITESCACHE_WRITER3 384 221 SYSDBA330 176 TOTAL 3 714 397 2) в SuperClassic'e разность счетчика page_writes = 3 704 960

Итого: при вставке 6.3 млн строк в таблицу и два её индекса счетчик writes дёргался 3.7 млн раз.
При том, что в 1 страницу базы влезает чуть ли не 60 строк таблицы (и индексных ключей столько же, таков DDL).
Буфер = 16384 страниц, в 8 раз больше дефолтного.

Не вижу в упор проявления алгоритма:DSSC пишет страницу только когда она полностью заполнена
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531233
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladчто ты тестируешь ? Какая у тебя цель ?
Откуда ты взял, что кол-во writes должно совпадать с кол-вом inserts ????Цель одна: понять, откудова взялись такие тупняки при заполнении таблиц в известном тебе тесте. И особенно - откудова они же (тупняки, только ГИГАНТСКИЕ) при выполнении второго теста: delete => select count(*) ==> insert.
Когда ждёшь результаты выполнения скриптов по 18...24 ч, поневоле начнёшь думкать в эту сторону.
hvladТаблоидповторил для буфера = 16384 (в SC так и в SS; FW вырубил).Всё, счастье настало ?неа...увы и ах.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
    #38531241
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЦель одна: понять, откудова взялись такие тупняки при заполнении таблиц в известном тебе тестеВ статистике ФБ ты этого не найдёшь.
Таблоиднеа...увы и ах.Ну значит так и запишем - безнадёжен.
...
Рейтинг: 0 / 0
Вставка в индексир.таблицы: 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
71 сообщений из 71, показаны все 3 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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