powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
45 сообщений из 45, показаны все 2 страниц
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522475
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

Есть ФБ, собран из сегодняшних сырцов.
Есть пустая база с FW = OFF, page_size=4096.
И есть вот такой скрипт, который сечас выполняется:
(создаёт SP, таблицы + индексы, затем стартует select * from SP for update)
Код: sql
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.
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 transaction read write read committed record_version no wait;
--*/
set term ^;
create or alter procedure sp_huge_ext returns(msg varchar(90)) 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
  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)||'  curr_ms='||elapsed_ms_now||'  '||msg4min||'  '||msg4max;
    suspend;

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

select * from sp_huge_ext for update;
commit;

Скрипт выдает число добавленных записей, но главное - максимальную длительность ввода "пачки" из 10'000 строк в таблицу TDETL, а также момент времени, когда это случилось.

Пример вывода этого скрипта:

Код: plaintext
1.
2.
3.
4.
19:17:37: gdetl=024130000  curr_ms=841  min_ms=484 at 18:40:59  max_ms=10083 at 19:05:50
19:17:38: gdetl=024140000  curr_ms=862  min_ms=484 at 18:40:59  max_ms=10083 at 19:05:50
19:17:39: gdetl=024150000  curr_ms=852  min_ms=484 at 18:40:59  max_ms=10083 at 19:05:50
19:17:40: gdetl=024160000  curr_ms=824  min_ms=484 at 18:40:59  max_ms=10083 at 19:05:50
. . .

Параллельно с этим, в отдельном окне пляшет iostat с логированием своего вывода в файлик. Данные в iostat'e обновляются каждую секунду.

Скачок в 10 сек, как видим, был в 19:05:50.
Значит, можно глянуть в лог iostat'a за период с 19:05:20 по 19:06:20 и попытаться понять, чем был вызван этот тупняк.
Фрагмент этого лога - в аттаче.

Поможыте понять, кто в линухе силён: на что обратить внимание ? В упор не вижу, чем период 19:05:40...19:05:50 отличается от остальных: %iowait везде примерно одинаковый, на уровне 6...8%.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522806
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Продолжаем разговор" (С) :)
Через 12 ч после начала теста вывод execute block'a состоит сплошняком из "перлов":
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
09:55:12: gdetl=178470000  min_ms=488 at 21:44:17  curr_ms=53565  max_ms=345901 at 07:31:51
09:55:21: gdetl=178480000  min_ms=488 at 21:44:17  curr_ms=9169  max_ms=345901 at 07:31:51
09:56:04: gdetl=178490000  min_ms=488 at 21:44:17  curr_ms=43324  max_ms=345901 at 07:31:51
09:56:13: gdetl=178500000  min_ms=488 at 21:44:17  curr_ms=8872  max_ms=345901 at 07:31:51
09:56:22: gdetl=178510000  min_ms=488 at 21:44:17  curr_ms=8731  max_ms=345901 at 07:31:51
09:57:43: gdetl=178520000  min_ms=488 at 21:44:17  curr_ms=81193  max_ms=345901 at 07:31:51
09:57:51: gdetl=178530000  min_ms=488 at 21:44:17  curr_ms=8288  max_ms=345901 at 07:31:51
09:58:00: gdetl=178540000  min_ms=488 at 21:44:17  curr_ms=8310  max_ms=345901 at 07:31:51
09:59:19: gdetl=178550000  min_ms=488 at 21:44:17  curr_ms=79741  max_ms=345901 at 07:31:51
09:59:30: gdetl=178560000  min_ms=488 at 21:44:17  curr_ms=10530  max_ms=345901 at 07:31:51
09:59:38: gdetl=178570000  min_ms=488 at 21:44:17  curr_ms=8459  max_ms=345901 at 07:31:51
10:00:58: gdetl=178580000  min_ms=488 at 21:44:17  curr_ms=79635  max_ms=345901 at 07:31:51

То есть, 10'000 строк в TDETL + 1 строка в TMAIN добавляются то 8, а то и 80 сек.
Пик был (пока что) в 07:31:51 и составил 6 минут 46 сек %-)

Чем его объяснить - то тайна велика есмь

Ибо логи iostat и vmstat за этот временн о й отрезок (почти 7 минут) - ничего выдающегося не содержат, если сравнивать их показатели с другим временем.
Кому интересно - посмотрите в аттач, там два фрагмента этих логов, с 07:24:43 по 07:32:00. Насколько могу понять, IO "пишет себе и пишет", не больше и не меньше.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522812
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FW-OFF?

P.S. Топик не читал.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522813
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЕсть ФБ, собран из сегодняшних сырцов.
Есть пустая база с FW = OFF , page_size=4096.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522814
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

что мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522819
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще-то говоря, состояние базы в момент, когда тест закончится, у мну есть, т.к. сейчас идёт второй "забег". Вот оно:
gstat -r
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
Database header page information:
	Flags			0
	Generation		3324
	System Change Number	0
	Page size		4096
	ODS version		12.0
	Oldest transaction	36
	Oldest active		3140
	Oldest snapshot		3140
	Next transaction	3314
	Sequence number		0
	Next attachment ID	1560
	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 8, 2014 17:56:18
	Attributes		

    Variable header data:
	Sweep interval:		0
	*END*


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

Analyzing database pages ...
TDETL (137)
    Primary pointer page: 236, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 93.86, total records: 200000000
    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: 100.00, compression ratio: 1.07
    Pointer pages: 8252, data page slots: 6666568
    Data pages: 6666568, average fill: 82%
    Primary pages: 6666568, secondary pages: 0, swept pages: 0
    Empty pages: 0, full pages: 6666567
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 0
	40 - 59% = 1
	60 - 79% = 33
	80 - 99% = 6666534

    Index TDETL_FK_IDX (1)
	Root page: 2597850, depth: 4, leaf buckets: 303784, nodes: 200000000
	Average node length: 6.04, total dup: 198000000, max dup: 99
	Average key length: 2.08, compression ratio: 4.32
	Average prefix length: 8.93, average data length: 0.07
	Clustering factor: 6666568, ratio: 0.03
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 1
	    60 - 79% = 0
	    80 - 99% = 303783

    Index TDETL_PK_IDX (0)
	Root page: 1357262, depth: 4, leaf buckets: 600139, nodes: 200000000
	Average node length: 12.01, total dup: 0, max dup: 0
	Average key length: 8.05, compression ratio: 1.12
	Average prefix length: 3.94, average data length: 5.06
	Clustering factor: 6666568, ratio: 0.03
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 0
	    60 - 79% = 0
	    80 - 99% = 600139

    Index TDETL_S01 (2)
	Root page: 1741908, depth: 5, leaf buckets: 2814455, nodes: 200000000
	Average node length: 36.79, total dup: 0, max dup: 0
	Average key length: 32.82, compression ratio: 1.10
	Average prefix length: 6.16, average data length: 29.84
	Clustering factor: 199999977, ratio: 1.00
	Fill distribution:
	     0 - 19% = 53464
	    20 - 39% = 58441
	    40 - 59% = 898588
	    60 - 79% = 1106109
	    80 - 99% = 697853

    Index TDETL_S02 (3)
	Root page: 1783912, depth: 5, leaf buckets: 2815638, nodes: 200000000
	Average node length: 36.79, total dup: 0, max dup: 0
	Average key length: 32.82, compression ratio: 1.10
	Average prefix length: 6.16, average data length: 29.84
	Clustering factor: 199999966, ratio: 1.00
	Fill distribution:
	     0 - 19% = 53977
	    20 - 39% = 58208
	    40 - 59% = 899361
	    60 - 79% = 1106998
	    80 - 99% = 697094

TLOG (139)
    Primary pointer page: 237, Index root page: 238
    Total formats: 1, used formats: 1
    Average record length: 33.80, total records: 20000
    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.24
    Pointer pages: 1, data page slots: 368
    Data pages: 368, average fill: 68%
    Primary pages: 368, secondary pages: 0, swept pages: 0
    Empty pages: 4, full pages: 363
    Fill distribution:
	 0 - 19% = 4
	20 - 39% = 0
	40 - 59% = 1
	60 - 79% = 363
	80 - 99% = 0

TMAIN (138)
    Primary pointer page: 242, Index root page: 243
    Total formats: 1, used formats: 1
    Average record length: 86.95, total records: 2000000
    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: 92.00, compression ratio: 1.06
    Pointer pages: 78, data page slots: 62504
    Data pages: 62504, average fill: 82%
    Primary pages: 62504, secondary pages: 0, swept pages: 0
    Empty pages: 4, full pages: 62500
    Fill distribution:
	 0 - 19% = 4
	20 - 39% = 0
	40 - 59% = 0
	60 - 79% = 0
	80 - 99% = 62500

    Index TMAIN_PK_IDX (0)
	Root page: 607194, depth: 3, leaf buckets: 5954, nodes: 2000000
	Average node length: 11.93, total dup: 0, max dup: 0
	Average key length: 8.96, compression ratio: 1.00
	Average prefix length: 3.04, average data length: 5.96
	Clustering factor: 62500, ratio: 0.03
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 0
	    60 - 79% = 0
	    80 - 99% = 5954

    Index TMAIN_S01 (1)
	Root page: 2828003, depth: 4, leaf buckets: 28644, nodes: 2000000
	Average node length: 37.45, total dup: 0, max dup: 0
	Average key length: 34.47, compression ratio: 1.04
	Average prefix length: 4.51, average data length: 31.49
	Clustering factor: 1999959, ratio: 1.00
	Fill distribution:
	     0 - 19% = 544
	    20 - 39% = 771
	    40 - 59% = 8945
	    60 - 79% = 11488
	    80 - 99% = 6896

    Index TMAIN_S02 (2)
	Root page: 2792356, depth: 4, leaf buckets: 28723, nodes: 2000000
	Average node length: 37.45, total dup: 0, max dup: 0
	Average key length: 34.47, compression ratio: 1.04
	Average prefix length: 4.52, average data length: 31.48
	Clustering factor: 1999971, ratio: 1.00
	Fill distribution:
	     0 - 19% = 583
	    20 - 39% = 826
	    40 - 59% = 8919
	    60 - 79% = 11559
	    80 - 99% = 6836

Когда база пустая, то статистика добавления 100 строк в TMAIN и 10000 строк в TDETL следующая:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
    1017 write(s), 232208 fetch(es), 63181 mark(s)
Table                             Natural     Index    Update    Insert 
************************************************************************
RDB$INDICES                                       9
RDB$RELATION_CONSTRAINTS                          2
TDETL                                                             10000
TMAIN                                                               100
TLOG                                                                  1

Когда же таблица TMAIN содержит 2 млн, а TDETL - 200 млн строк, то коленкор таков:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
69599 read(s), 891 write(s), 363278 fetch(es), 63078 mark(s)
Table                             Natural     Index    Update    Insert 
************************************************************************
RDB$INDICES                                       9
RDB$RELATION_CONSTRAINTS                          2
TDETL                                                             10000
TMAIN                                                               100
TLOG                                                                  1

(время вполнения намеренно выкинул, т.к. оно всё время "скачет" - см пост выше, 15400933 ).

Я понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208).
На что время-то уходит такое (по нескольку минут!) при работе только ОДНОГО аттача ?

ЗЫ. На хосте ничего больше, кроме ФБ, не молотит. Только рядом скрипты с линуховым мониторингом: iostat, vmstat (сейчас вот еще iotop lобавил).
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522822
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrчто мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"?пардон, не увидел этот пост вовремя.
Сейчас уже буду ждать окончания молотьбы, там дошло аж до 180 млн:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
11:08:41: gdetl=179910000  min_ms=488 at 21:44:17  curr_ms=4972  max_ms=345901 at 07:31:51
11:10:36: gdetl=179920000  min_ms=488 at 21:44:17  curr_ms=114756  max_ms=345901 at 07:31:51
11:10:56: gdetl=179930000  min_ms=488 at 21:44:17  curr_ms=19460  max_ms=345901 at 07:31:51
11:11:01: gdetl=179940000  min_ms=488 at 21:44:17  curr_ms=5061  max_ms=345901 at 07:31:51
11:12:03: gdetl=179950000  min_ms=488 at 21:44:17  curr_ms=61871  max_ms=345901 at 07:31:51
11:12:23: gdetl=179960000  min_ms=488 at 21:44:17  curr_ms=19942  max_ms=345901 at 07:31:51
11:12:28: gdetl=179970000  min_ms=488 at 21:44:17  curr_ms=5058  max_ms=345901 at 07:31:51
11:12:33: gdetl=179980000  min_ms=488 at 21:44:17  curr_ms=4935  max_ms=345901 at 07:31:51
11:12:37: gdetl=179990000  min_ms=488 at 21:44:17  curr_ms=4719  max_ms=345901 at 07:31:51

Правильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522823
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208).
а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522826
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M)
боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет...
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522829
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208).а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой?1. Индексы такой глубины - это приговор на "вечные тормоза" ? Если да, то чем это объяснить, почему на глубине 3 всё пучком, а 5 -уже "куку" ? Затратами на расщепление листовых страниц и всех вышележащих уровней или еще чем-то ?
2. Страница 4К - это только первая фаза нашей эстафеты Дальше надо будет на 8 и 16 К проверить. Таково "задание Партии".
Кста! А ведь тут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522833
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M)боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет...Дык не вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl.
Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522852
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидтут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ?
это правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522855
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl.
Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю.
попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522861
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrэто правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии.А что именно там "ахтунгом" является ? Ну, вот есть индекс глубиной = 5 - и что в нём "такого страшного", отчего конкретно идут тормоза при добавлении ключей ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522862
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl.
Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю.
попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).А вот этому:
Код: plaintext
1.
2.
3.
4.
# Number of seconds during which unflushed writes will accumulate
# before they are flushed, at the next transaction commit.
#
#MaxUnflushedWriteTime = 5
- какое значение задать ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38522866
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

MaxUnflushedWriteTime не трогай
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523790
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrпопробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).Ффух... запустил, вобщем. И кажется мну, что очень скоро придется рестартовать с другим значением MaxUnflushedWrites

Вот скрипт:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
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 sequence glog;
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( id int primary key using index tlog_pk_idx,
                    gmain bigint,
                     gdetl bigint, 
                 dt_cur timestamp,
                 ms_cur int,
                 dt_max timestamp,
                 ms_max int,
                 dt_min timestamp,
                 ms_min int,
                 tx int
                );
commit;

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 term ^;
create or alter procedure sp_huge_ext 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 n_insa int = 1000; -- number of rows inserted int tmain in each auton trn
  declare verbose_step int=100; -- step of gdetl for detailed log

  declare v_id bigint;
  declare i int;
  declare j int;
  declare k int;
  declare tx timestamp;
  declare tc timestamp;
  declare ms_cur int;
  declare ms_min int = 999999999;
  declare ms_max int = -1;
  declare v_dt_min timestamp;
  declare v_dt_max timestamp;
  declare v_log_id int = 0;
  declare v_last_id int = 0;
begin
  tx=cast('now' as timestamp);
  while(n_main>0) do begin
    in autonomous transaction do
    begin
      k=n_insa / verbose_step;
      while ( k > 0) do begin
        msg='';
        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 id into 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;

          j=j-1;
        end -- j=verbose_step downto 1

        tc=cast('now' as timestamp);
        ms_cur=datediff(millisecond from :tx to :tc);

        if ( ms_min > ms_cur ) then begin
          ms_min=ms_cur;
          v_dt_min = tc;
        end

        if ( ms_max < ms_cur ) then begin
          ms_max=ms_cur;
          v_dt_max=tc;
        end

        insert into tlog(
                id,
                gmain, gdetl, 
                dt_cur, ms_cur, 
                dt_max, ms_max, 
                dt_min, ms_min, 
                tx)
        values( gen_id(glog, 1),
                gen_id(gmain,0), gen_id(gdetl,0),
                :tc,       :ms_cur,
                :v_dt_max, :ms_max,
                :v_dt_min, :ms_min,
                current_transaction
              )
        returning id into v_log_id;

        tx=cast('now' as timestamp);
        k=k-1;
      end
    end -- in autonomous tran

    for 
      select left(right(dt_cur,13),8)
            ||': gdetl='||right(cast(1000000000+gdetl as varchar(10)),9)
            ||'  min_ms='||ms_min||' at '||left(right(dt_min,13),8)
            ||'  cur_ms='||ms_cur
            ||'  max_ms='||ms_max||' at '||left(right(dt_max,13),8)
            --||'  tx='||tx
      from tlog
      where id>:v_last_id 
      into :msg 
    do suspend;

    v_last_id = v_log_id;

  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;


Этот скрипт делает в одной автономной транзакции n_insa = 1000 вставок в TMAIN и n_insa * n_detl int = 100'000 вставок в TDETL.
Параметр MaxUnflushedWrites установил равным 5.
Число буферов - дефолтное, 2048.

Параллельно в "мониторных" окнах запущены с логированием: iostat -x; iotop; vmstat.
И хотя скрипт только-только начал работать, траблы повторяются (вернее, начались еще раньше, чем прежде):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
00:25:04: gdetl=003270000  min_ms=483 at 00:20:33  cur_ms=721  max_ms=6805 at 00:24:13
00:25:05: gdetl=003280000  min_ms=483 at 00:20:33  cur_ms=720  max_ms=6805 at 00:24:13
00:25:06: gdetl=003290000  min_ms=483 at 00:20:33  cur_ms=1149  max_ms=6805 at 00:24:13
00:25:08: gdetl=003300000  min_ms=483 at 00:20:33  cur_ms=1255  max_ms=6805 at 00:24:13
00:25:18: gdetl=003310000  min_ms=483 at 00:20:33   cur_ms=10426   max_ms=10426 at 00:25:18
00:25:19: gdetl=003320000  min_ms=483 at 00:20:33  cur_ms=719  max_ms=10426 at 00:25:18
00:25:19: gdetl=003330000  min_ms=483 at 00:20:33  cur_ms=714  max_ms=10426 at 00:25:18
00:25:20: gdetl=003340000  min_ms=483 at 00:20:33  cur_ms=715  max_ms=10426 at 00:25:18
. . .
00:31:55: gdetl=006870000  min_ms=483 at 00:20:33  cur_ms=1095  max_ms=19892 at 00:31:03
00:31:56: gdetl=006880000  min_ms=483 at 00:20:33  cur_ms=968  max_ms=19892 at 00:31:03
00:31:57: gdetl=006890000  min_ms=483 at 00:20:33  cur_ms=848  max_ms=19892 at 00:31:03
00:31:58: gdetl=006900000  min_ms=483 at 00:20:33  cur_ms=1017  max_ms=19892 at 00:31:03
00:32:20: gdetl=006910000  min_ms=483 at 00:20:33   cur_ms=21901   max_ms=21901 at 00:32:20
00:32:21: gdetl=006920000  min_ms=483 at 00:20:33  cur_ms=746  max_ms=21901 at 00:32:20
00:32:21: gdetl=006930000  min_ms=483 at 00:20:33  cur_ms=720  max_ms=21901 at 00:32:20
Возможно, я значение MaxUnflushedWrites установлено слишком низким, не знаю.
Метод тыка какой-то идёт %-/

PS.
Хреново, что трейс для такого скрипта вообще ничего не показывает: ХП для него деревянный ящик.
Код: 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.
2014-01-13T00:31:17.0170 (15457:0x7fdfe4121d08) START_TRANSACTION
        /var/db/fb30/huge_noext_at.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:16628
                (TRA_111, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)

2014-01-13T00:31:27.7260 (15457:0x7fdfe4121d08) COMMIT_TRANSACTION
        /var/db/fb30/huge_noext_at.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:16628
                (TRA_111, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
     21 ms, 1 read(s), 1100 write(s), 1 fetch(es), 1 mark(s)

2014-01-13T00:31:27.7280 (15457:0x7fdfe4121d08) START_TRANSACTION
        /var/db/fb30/huge_noext_at.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:16628
                (TRA_112, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)

2014-01-13T00:31:38.3180 (15457:0x7fdfe4121d08) COMMIT_TRANSACTION
        /var/db/fb30/huge_noext_at.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:16628
                (TRA_112, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
      2 ms, 1 read(s), 1103 write(s), 1 fetch(es), 1 mark(s)

2014-01-13T00:31:38.3190 (15457:0x7fdfe4121d08) START_TRANSACTION
        /var/db/fb30/huge_noext_at.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:16628
                (TRA_113, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523856
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

вроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523862
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а что в трейсе в моменты 00:25:18 и 00:32:20?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523879
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем, докладаю.

Затыки идут не только от ожидания сброса файлового кеша на диск (как я понимаю, linux-процессами flush и jdb2).
Они возникают при любом MaxUnfluhedWrites, при передаче данных из кеша ФБ в кеш операционки: так показывает iotop .

Логи iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.

Тест был такой (для maxUnflushedWrites=10):
1. в окнах 1..3 запускаются линух-мониторные утилиты с логированием вывода в соотв. файлы:
iostat, vmstat, iotop
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
supertee -tn iostat_x_huge_fil_muf_010_$(date +'%Y%m%d_%H%M').log  iostat  -x -t 1

supertee -tn vmstat_huge_fil_muf_010_$(date +'%Y%m%d_%H%M').log  vmstat  -t 1

// ключик -o логирует только те потоки процессов, которые создают сейчас IO 
// (вместо вывода всех потоков вообще, что по дефолту);
// ключик -t заставляет выводить штамп времени;
// ключик -d 1 задаёт паузу в выводе =  1 сек;
supertee -tn iotop_o_huge_fil_muf_010_$(date +'%Y%m%d_%H%M').log  iotop  -o -t -d 1 -b

2. В окне 4 запускается скрипт huge_fil_at.sh ( '_at' = 'autonomous transaction': добавляет пачки записей в автономной транзакции), вызывающий isql и натравливающий на него .sql с заполнением данными. Особенность .sh в том, что по окончании работы isql он будет убивать мониторные процессы, запущенные в окнах 1...3.
А сам же isql прекратится по эксепшену, как только время, затраченное на ввод 1'000 записей в TMAIN и 100'000 записей в TDETL, превысит порог = 15'000 ms (переменная 'MS_FOR_STOP'):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
$ cat huge_fil_at.sh
rm -f huge_noext_at.fdb
cp huge_noext.fd0 huge_noext_at.fdb
chown -R firebird:firebird huge_noext_at.fdb
supertee -tn isql_huge_fil_$(date +'%Y%m%d_%H%M').log \
    /opt/fb30trnk/bin/isql localhost/3333:/var/db/fb30/huge_noext_at.fdb \
    -pag 0 -i  huge_fil_at.sql 
killall -9 iostat
killall -9 vmstat
killall -9 iotop

Ну, и собственно .sql-скрипт:
huge_fil_at.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.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
 -- huge_fil_at.sql 
set autoddl on;
show version;
commit;
set term ^;create or alter procedure sp_huge_ext as begin end^set term ;^
commit;
create  exception ex_too_long_time  'too long insert detected, DML was cancelled';
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 sequence glog;
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( id int primary key using index tlog_pk_idx,
                    gmain bigint,
                     gdetl bigint, 
                 dt_cur timestamp,
                 ms_cur int,
                 dt_max timestamp,
                 ms_max int,
                 dt_min timestamp,
                 ms_min int,
                 tx int
                );
commit;

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 term ^;
create or alter procedure sp_huge_ext returns(msg varchar(100)) as 
  declare  MS_FOR_STOP int = 15000 ;
  declare n_main int = 2000000;
  declare n_detl int = 100; -- child records in tdetl per each parent row in tmain
  declare n_insa int = 1000; -- number of rows inserted int tmain in each auton trn
  declare verbose_step int=100; -- step of gdetl for detailed log

  declare v_id bigint;
  declare i int;
  declare j int;
  declare k int;
  declare tx timestamp;
  declare tc timestamp;
  declare ms_cur int;
  declare ms_min int = 999999999;
  declare ms_max int = -1;
  declare v_dt_min timestamp;
  declare v_dt_max timestamp;
  declare v_log_id int = 0;
  declare v_last_id int = 0;
begin
  tx=cast('now' as timestamp);
  while(n_main>0) do begin
    in autonomous transaction do
    begin
      k=n_insa / verbose_step;
      while ( k > 0) do begin
        msg='';
        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 id into 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;

          j=j-1;
        end -- j=verbose_step downto 1

        tc=cast('now' as timestamp);
        ms_cur=datediff(millisecond from :tx to :tc);

        if ( ms_min > ms_cur ) then begin
          ms_min=ms_cur;
          v_dt_min = tc;
        end

        if ( ms_max < ms_cur ) then begin
          ms_max=ms_cur;
          v_dt_max=tc;
        end

        insert into tlog(
                id,
                gmain, gdetl, 
                dt_cur, ms_cur, 
                dt_max, ms_max, 
                dt_min, ms_min, 
                tx)
        values( gen_id(glog, 1),
                gen_id(gmain,0), gen_id(gdetl,0),
                :tc,       :ms_cur,
                :v_dt_max, :ms_max,
                :v_dt_min, :ms_min,
                current_transaction
              )
        returning id into v_log_id;

        if (ms_cur >  MS_FOR_STOP ) then  k=-1 ;  -- ==> exit immediatelly with exception 

        tx=cast('now' as timestamp);
        k=k-1;
      end -- while k>0
    end -- in autonomous tran

    for 
      select left(right(dt_cur,13),8)
            ||': gdetl='||right(cast(1000000000+gdetl as varchar(10)),9)
            ||'  min_ms='||ms_min||' at '||left(right(dt_min,13),8)
            ||'  cur_ms='||ms_cur
            ||'  max_ms='||ms_max||' at '||left(right(dt_max,13),8)
            --||'  tx='||tx
      from tlog
      where id>:v_last_id 
      into :msg 
    do suspend;

    if (k <= -1) then
       exception ex_too_long_time ;

    v_last_id = v_log_id;

  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;


В итоге всех прогонов (при ЛЮБОМ maxUnflushedWrites), всё заканчивалось примерно вот так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
08:43:47: gdetl=005180000  min_ms=476 at 08:36:12  cur_ms=728  max_ms=12216 at 08:42:12
08:43:47: gdetl=005190000  min_ms=476 at 08:36:12  cur_ms=725  max_ms=12216 at 08:42:12
08:43:48: gdetl=005200000  min_ms=476 at 08:36:12  cur_ms=731  max_ms=12216 at 08:42:12
08:44:04: gdetl=005210000  min_ms=476 at 08:36:12  cur_ms=16045  max_ms=16045 at 08:44:04
Statement failed, SQLSTATE = 42000
exception 1
-EX_TOO_LONG_TIME
-too long insert detected, DML was cancelled
-At procedure 'SP_HUGE_EXT' line: 96, col: 7
After line 144 in file huge_fil_at.sql

Как видим, последние два затыка были = 12 и 16 сек.
Для затыка-1 лог iotop'a:
iotop -o, 08:42:00...08:42:12
Код: 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.
08:41:58 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:41:58 2014: 08:41:58 26261 be/4 firebird    0.00 B/s    3.70 M/s  0.00 %  0.00 % firebird
08:41:58 2014: 08:41:58 26263 be/4 firebird    0.00 B/s    5.12 M/s  0.00 %  0.00 % firebird
08:41:59 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 19.68 K/s
08:41:59 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:41:59 2014: 08:41:59   447 be/3 root        0.00 B/s    3.94 K/s  0.00 %  0.02 % [jbd2/sda4-8]
08:41:59 2014: 08:41:59 26261 be/4 firebird    0.00 B/s    3.45 M/s  0.00 %  0.00 % firebird
08:41:59 2014: 08:41:59 26263 be/4 firebird    0.00 B/s    4.06 M/s  0.00 %  0.00 % firebird
08:42:00 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 80.59 M/s
08:42:00 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:00 2014: 08:42:00 26261 be/4 firebird    0.00 B/s    3.32 M/s  0.00 %  6.65 % firebird
08:42:00 2014: 08:42:00 26263 be/4 firebird    0.00 B/s    2.98 M/s  0.00 %  0.00 % firebird
08:42:01 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 55.60 M/s
08:42:01 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:01 2014: 08:42:01 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 95.57 % firebird
08:42:01 2014: 08:42:01 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iostat_x
08:42:02 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.79 M/s
08:42:02 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:02 2014: 08:42:02 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.00 % firebird
08:42:02 2014: 08:42:02 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop_o_
08:42:03 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 30.37 M/s
08:42:03 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:03 2014: 08:42:03 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.58 % firebird
08:42:04 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 31.18 M/s
08:42:04 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:04 2014: 08:42:04 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.96 % firebird
08:42:04 2014: 08:42:04   447 be/3 root        0.00 B/s   11.82 K/s  0.00 %  5.77 % [jbd2/sda4-8]
08:42:04 2014: 08:42:04 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iostat_x
08:42:04 2014: 08:42:04 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop_o_
08:42:05 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 32.35 M/s
08:42:05 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:05 2014: 08:42:05 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.64 % firebird
08:42:05 2014: 08:42:05 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iostat_x
08:42:05 2014: 08:42:05 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop_o_
08:42:06 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 28.74 M/s
08:42:06 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:06 2014: 08:42:06 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.24 % firebird
08:42:06 2014: 08:42:06 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iostat_x
08:42:07 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.20 M/s
08:42:07 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:07 2014: 08:42:07 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.75 % firebird
08:42:08 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 69.09 M/s
08:42:08 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:08 2014: 08:42:08 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 70.70 % firebird
08:42:08 2014: 08:42:08  1639 be/4 root        0.00 B/s    0.00 B/s  0.00 % 33.96 % [flush-8:0]
08:42:09 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 28.05 M/s
08:42:09 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:09 2014: 08:42:09 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.99 % firebird
08:42:09 2014: 08:42:09   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 96.08 % [jbd2/sda4-8]
08:42:10 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 27.42 M/s
08:42:10 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:10 2014: 08:42:10   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.10 % [jbd2/sda4-8]
08:42:10 2014: 08:42:10 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.48 % firebird
08:42:11 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.84 M/s
08:42:11 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:11 2014: 08:42:11   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.78 % [jbd2/sda4-8]
08:42:11 2014: 08:42:11 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.36 % firebird
08:42:11 2014: 08:42:11  1380 be/3 root        0.00 B/s    3.94 K/s  0.00 %  1.02 % [jbd2/sdb1-8]
08:42:11 2014: 08:42:11 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop_o_hu
08:42:12 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 4.71 M/s
08:42:12 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:12 2014: 08:42:12   447 be/3 root        0.00 B/s   19.70 K/s  0.00 % 19.26 % [jbd2/sda4-8]
08:42:12 2014: 08:42:12 26261 be/4 firebird    0.00 B/s    4.18 M/s  0.00 % 18.08 % firebird
08:42:12 2014: 08:42:12 26257 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn isql_huge_
08:42:12 2014: 08:42:12 26263 be/4 firebird    0.00 B/s   78.30 M/s  0.00 %  0.00 % firebird
08:42:13 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 34.91 K/s
08:42:13 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:13 2014: 08:42:13   447 be/3 root        0.00 B/s   11.64 K/s  0.00 %  0.01 % [jbd2/sda4-8]
08:42:13 2014: 08:42:13  2654 be/4 oracle      0.00 B/s    3.88 K/s  0.00 %  0.00 % java -Xmx128M -XX:MaxPe
08:42:13 2014: core/12.1.0.3.0/sysman/jlib/emagentSDK-intg.jar:/u01/app/oracle/oms/core/12.1.0.3.0/sysman/j
08:42:13 2014: 08:42:13 23573 be/4 oracle      0.00 B/s    0.00 B/s  0.00 %  0.00 % java -Xmx128M -XX:MaxPe
08:42:13 2014: core/12.1.0.3.0/sysman/jlib/emagentSDK-intg.jar:/u01/app/oracle/oms/core/12.1.0.3.0/sysman/j
08:42:13 2014: 08:42:13 26261 be/4 firebird    0.00 B/s    4.75 M/s  0.00 %  0.00 % firebird
08:42:13 2014: 08:42:13 26263 be/4 firebird    0.00 B/s   77.70 M/s  0.00 %  0.00 % firebird
08:42:13 2014: 08:42:13 26266 be/4 root        0.00 B/s    3.88 K/s  0.00 %  0.00 % supertee -tn iostat_x_h
08:42:13 2014: 08:42:13  2961 be/4 root        0.00 B/s    7.76 K/s  0.00 %  0.00 % ../jre/bin/java -classp
08:42:14 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
08:42:14 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:42:14 2014: 08:42:14 26261 be/4 firebird    0.00 B/s    4.38 M/s  0.00 %  0.00 % firebird
08:42:14 2014: 08:42:14 26263 be/4 firebird    0.00 B/s   61.16 M/s  0.00 %  0.00 % firebird
08:42:14 2014: 08:42:14 26281 be/4 root        0.00 B/s    3.92 K/s  0.00 %  0.00 % supertee -tn iotop_o_hu
08:42:14 2014: 08:42:14  2639 be/4 oracle      0.00 B/s    3.92 K/s  0.00 %  0.00 % java -Xmx128M -XX:MaxPe
08:42:14 2014: core/12.1.0.3.0/sysman/jlib/emagentSDK-intg.jar:/u01/app/oracle/oms/core/12.1.0.3.0/sysman/j

Для затыка-2 лог iotop'a:
iotop -o, 08:43:48...08:44:04
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
08:43:45 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:45 2014: 08:43:45 26261 be/4 firebird    0.00 B/s    3.71 M/s  0.00 %  0.00 % firebird
08:43:45 2014: 08:43:45 26263 be/4 firebird    0.00 B/s    8.50 M/s  0.00 %  0.00 % firebird
08:43:45 2014: 08:43:45 26281 be/4 root        0.00 B/s    3.93 K/s  0.00 %  0.00 % supertee -tn iotop
08:43:46 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 23.61 K/s
08:43:46 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:46 2014: 08:43:46 26261 be/4 firebird    0.00 B/s    3.70 M/s  0.00 %  0.00 % firebird
08:43:46 2014: 08:43:46 26263 be/4 firebird    0.00 B/s    6.97 M/s  0.00 %  0.00 % firebird
08:43:46 2014: 08:43:46 26266 be/4 root        0.00 B/s    3.93 K/s  0.00 %  0.00 % supertee -tn iosta
08:43:47 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 27.55 K/s
08:43:47 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:47 2014: 08:43:47   447 be/3 root        0.00 B/s    3.94 K/s  0.00 %  0.01 % [jbd2/sda4-8]
08:43:47 2014: 08:43:47 26261 be/4 firebird    0.00 B/s    3.46 M/s  0.00 %  0.00 % firebird
08:43:47 2014: 08:43:47 26263 be/4 firebird    0.00 B/s    6.05 M/s  0.00 %  0.00 % firebird
08:43:47 2014: 08:43:47 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iosta
08:43:48 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
08:43:48 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:48 2014: 08:43:48 26261 be/4 firebird    0.00 B/s    3.70 M/s  0.00 %  0.00 % firebird
08:43:48 2014: 08:43:48 26263 be/4 firebird    0.00 B/s    4.95 M/s  0.00 %  0.00 % firebird
08:43:48 2014: 08:43:48 26276 be/4 root        0.00 B/s    7.87 K/s  0.00 %  0.00 % supertee -tn vmsta
08:43:49 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 127.71 M/s
08:43:49 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:49 2014: 08:43:49 26261 be/4 firebird    0.00 B/s  995.65 K/s  0.00 % 71.22 % firebird
08:43:49 2014: 08:43:49  1380 be/3 root        0.00 B/s    3.94 K/s  0.00 %  0.02 % [jbd2/sdb1-8]
08:43:49 2014: 08:43:49 26263 be/4 firebird    0.00 B/s  787.08 K/s  0.00 %  0.00 % firebird
08:43:49 2014: 08:43:49 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop
08:43:50 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 31.22 M/s
08:43:50 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:50 2014: 08:43:50 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.24 % firebird
08:43:51 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 93.57 M/s
08:43:51 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:51 2014: 08:43:51 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 97.16 % firebird
08:43:51 2014: 08:43:51  1639 be/4 root        0.00 B/s    0.00 B/s  0.00 % 60.82 % [flush-8:0]
08:43:52 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 14.20 M/s
08:43:52 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:52 2014: 08:43:52 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.99 % firebird
08:43:52 2014: 08:43:52   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 54.26 % [jbd2/sda4-8]
08:43:52 2014: 08:43:52 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iosta
08:43:53 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 31.29 M/s
08:43:53 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:53 2014: 08:43:53   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 98.72 % [jbd2/sda4-8]
08:43:53 2014: 08:43:53 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.16 % firebird
08:43:54 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 30.24 M/s
08:43:54 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:54 2014: 08:43:54   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.61 % [jbd2/sda4-8]
08:43:54 2014: 08:43:54 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.88 % firebird
08:43:55 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.70 M/s
08:43:55 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:55 2014: 08:43:55   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.54 % [jbd2/sda4-8]
08:43:55 2014: 08:43:55 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.15 % firebird
08:43:56 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.59 M/s
08:43:56 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:56 2014: 08:43:56   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [jbd2/sda4-8]
08:43:56 2014: 08:43:56 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.00 % firebird
08:43:56 2014: 08:43:56  2961 be/4 root        0.00 B/s    7.88 K/s  0.00 %  1.97 % ../jre/bin/java -class
08:43:56 2014: 08:43:56 28793 be/4 root        0.00 B/s   19.70 K/s  0.00 %  0.00 % mc -P /tmp/mc-root/mc.
08:43:57 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.90 M/s
08:43:57 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:57 2014: 08:43:57 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.17 % firebird
08:43:57 2014: 08:43:57   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.08 % [jbd2/sda4-8]
08:43:57 2014: 08:43:57 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iotop_o_h
08:43:58 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.76 M/s
08:43:58 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:58 2014: 08:43:58   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.05 % [jbd2/sda4-8]
08:43:58 2014: 08:43:58 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.21 % firebird
08:43:59 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 29.71 M/s
08:43:59 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:43:59 2014: 08:43:59   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.98 % [jbd2/sda4-8]
08:43:59 2014: 08:43:59 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.29 % firebird
08:43:59 2014: 08:43:59 26266 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iostat_x_
08:44:00 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 28.51 M/s
08:44:00 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:44:00 2014: 08:44:00   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.94 % [jbd2/sda4-8]
08:44:00 2014: 08:44:00 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.26 % firebird
08:44:00 2014: 08:44:00  1380 be/3 root        0.00 B/s   43.33 K/s  0.00 %  0.94 % [jbd2/sdb1-8]
08:44:01 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 27.21 M/s
08:44:01 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:44:01 2014: 08:44:01   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.10 % [jbd2/sda4-8]
08:44:01 2014: 08:44:01 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 98.63 % firebird
08:44:01 2014: 08:44:01  2662 be/4 oracle      0.00 B/s   11.82 K/s  0.00 %  0.00 % java -Xmx128M -XX:MaxP
08:44:01 2014: core/12.1.0.3.0/sysman/jlib/emagentSDK-intg.jar:/u01/app/oracle/oms/core/12.1.0.3.0/sysman/
08:44:02 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 25.24 M/s
08:44:02 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:44:02 2014: 08:44:02   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.71 % [jbd2/sda4-8]
08:44:02 2014: 08:44:02 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.35 % firebird
08:44:03 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 27.61 M/s
08:44:03 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:44:03 2014: 08:44:03   447 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.87 % [jbd2/sda4-8]
08:44:03 2014: 08:44:03 26261 be/4 firebird    0.00 B/s    0.00 B/s  0.00 % 99.09 % firebird
08:44:03 2014: 08:44:03 26281 be/4 root        0.00 B/s    3.94 K/s  0.00 %  0.00 % supertee -tn iot
08:44:04 2014: Total DISK READ: 0.00 B/s | Total DISK WRITE: 10.33 M/s
08:44:04 2014:     TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
08:44:04 2014: 08:44:04   447 be/3 root        0.00 B/s   55.15 K/s  0.00 % 26.08 % [jbd2/sda4-8]
08:44:04 2014: 08:44:04 26261 be/4 firebird    0.00 B/s    7.27 M/s  0.00 % 25.69 % firebird
08:44:04 2014: 08:44:04 26263 be/4 firebird    0.00 B/s   69.94 M/s  0.00 %  0.00 % firebird


Как видно по логам, при затыках
1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?)
2) иногда включался процесс jbd2/sda4-8.
Для информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче.

ЗЫ. файл базы при последнем затыке имел размер = 1.3 Гб. Его копирование занимает:
1) сразу после теста, когда база торчит в файловом кеше:
Код: plaintext
1.
2.
3.
4.
 time cp huge_noext_at.fdb huge_noext_at.tmp

real    0m1.239s
user    0m0.009s
sys     0m1.227s

2) при очистке файлового кеша:
Код: plaintext
1.
2.
3.
real    0m21.227s
user    0m0.003s
sys     0m1.871s
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523880
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrа что в трейсе в моменты 00:25:18 и 00:32:20?не увидел этот вопрос вовремя, сейчас заново запущу, покажу результат.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523890
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Запустил еще раз этот тест, старушка мучалась около 2 минут.
В аттаче логи:
1) трейса
2) вывода isql
3) iotop -o
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523892
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а это... меня сейчас снова побьют за дурацкий вопрос, конечно, но... можно ли "распараллелить" работу передачи страниц в кеш операционки ? ну, то есть несколько cache_writer'ов запустить ? :-)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523898
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

нафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш).
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523907
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗапустил еще раз этот тест
самые тяжелые случаи явно коррелируют:


2014-01-13T 09:44:32 .5470 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION
/var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
/opt/fb30trnk/bin/isql:27569
(TRA_61, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
3586 ms , 1 read(s), 1390 write(s), 1 fetch(es), 1 mark(s)

2014-01-13T 09:46:05 .9480 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION
/var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
/opt/fb30trnk/bin/isql:27569
(TRA_72, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
7399 ms , 1 read(s), 1176 write(s), 1 fetch(es), 1 mark(s)

2014-01-13T 09:47:48 .0370 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION
/var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
/opt/fb30trnk/bin/isql:27569
(TRA_83, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
11548 ms , 1 read(s), 1142 write(s), 1 fetch(es), 1 mark(s)

2014-01-13T 09:49:39 .2420 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION
/var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
/opt/fb30trnk/bin/isql:27569
(TRA_94, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
16435 ms , 1 read(s), 1126 write(s), 1 fetch(es), 1 mark(s)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523924
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.
я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моменты

ТаблоидКак видно по логам, при затыках
1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?)
26261 - коннект с инсертами, 26263 - кешрайтер

ТаблоидДля информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче.
два раза из трех кешрайтер пишет на диск
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524281
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моментыДа, ты прав; впрочем, значения % времени, пока проц ждал завершения IO, невелики: всего 7%.
Лог isql:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
08:41:56: gdetl=004050000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=10053 at 08:40:16
08:41:57: gdetl=004060000  min_ms=476 at 08:36:12  cur_ms=723  max_ms=10053 at 08:40:16
08:41:58: gdetl=004070000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=10053 at 08:40:16
08:41:59: gdetl=004080000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:41:59: gdetl=004090000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:42:00: gdetl=004100000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:42:12: gdetl=004110000  min_ms=476 at 08:36:12   cur_ms=12216   max_ms=12216 at 08:42:12
08:42:13: gdetl=004120000  min_ms=476 at 08:36:12  cur_ms=739  max_ms=12216 at 08:42:12
08:42:14: gdetl=004130000  min_ms=476 at 08:36:12  cur_ms=732  max_ms=12216 at 08:42:12
08:42:14: gdetl=004140000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=12216 at 08:42:12
08:42:15: gdetl=004150000  min_ms=476 at 08:36:12  cur_ms=723  max_ms=12216 at 08:42:12
08:42:16: gdetl=004160000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=12216 at 08:42:12
И соотв-щий лог vmstat'a:
Код: 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.
08:41:56 2014: procs -----------memory---------- ---swap--      -----io---- --system-- -----cpu------ ---timestamp---
08:41:56 2014:  r  b   swpd   free   buff  cache      si   so    bi     bo    in    cs us sy id  wa  st
08:41:56 2014:  2  0 108252 22336912  61900 9352260    0    0     0      0 10811 19205  6  3 91  0  0	2014-01-13 08:41:56 MSK
08:41:57 2014:  1  0 108252 22332820  61900 9355972    0    0     0      0 10718 19097  6  3 91  0  0	2014-01-13 08:41:57 MSK
08:41:58 2014:  1  0 108252 22329348  61900 9359436    0    0     0      0 10822 19151  6  3 91  0  0	2014-01-13 08:41:58 MSK
08:41:59 2014:  1  0 108252 22325628  61908 9362964    0    0     0     20 10896 19385  7  3 91  0  0	2014-01-13 08:41:59 MSK
08:42:00 2014:  1  0 108252 22321784  61908 9366976    0    0     0      0 10889 19346  6  3 91  0  0	2014-01-13 08:42:00 MSK
08:42:01 2014:  0  1 108252 22321164  61908 9366980    0    0     0 137244 23363  1523  0  1 93   6   0	2014-01-13 08:42:01 MSK
08:42:02 2014:  0  1 108252 22321048  61908 9366980    0    0     0  29888  5222   460  0  0 92   7   0	2014-01-13 08:42:02 MSK
08:42:03 2014:  0  1 108252 22321048  61908 9366988    0    0     0  31244  5543   488  0  0 92   7   0	2014-01-13 08:42:03 MSK
08:42:04 2014:  0  1 108252 22321048  61916 9366980    0    0     0  31652  5577   500  0  0 92   7   0	2014-01-13 08:42:04 MSK
08:42:05 2014:  0  1 108252 22321048  61916 9366988    0    0     0  32944  5764   523  0  0 92   7   0	2014-01-13 08:42:05 MSK
08:42:06 2014:  0  1 108252 22320908  61916 9367084    0    0     0  29716  5327   481  0  0 92   7   0	2014-01-13 08:42:06 MSK
08:42:07 2014:  1  1 108252 22320908  61916 9367084    0    0     0  29892  5380   475  0  0 92   7   0	2014-01-13 08:42:07 MSK
08:42:08 2014:  0  1 108252 22320536  61916 9367088    0    0     0  79812  2581   290  0  0 92   8   0	2014-01-13 08:42:08 MSK
08:42:09 2014:  0  2 108252 22320668  61916 9367088    0    0     0  20632  3908   476  0  0 92   7   0	2014-01-13 08:42:09 MSK
08:42:10 2014:  0  2 108252 22320668  61916 9367088    0    0     0  28632  5376   573  0  0 92   8   0	2014-01-13 08:42:10 MSK
08:42:11 2014:  0  2 108252 22320668  61916 9367088    0    0     0  29624  5396   483  0  0 92   7   0	2014-01-13 08:42:11 MSK
08:42:12 2014:  1  0 108252 22318808  61932 9369260    0    0     0  14696  7361  8371  3  2 91   4   0	2014-01-13 08:42:12 MSK
08:42:13 2014:  1  0 108252 22315088  61932 9372760    0    0     0      8  9902 17417  7  3 90  0  0	2014-01-13 08:42:13 MSK
08:42:14 2014:  1  0 108252 22311616  61940 9376040    0    0     0     28  9540 16655  6  3 90  0  0	2014-01-13 08:42:14 MSK
08:42:15 2014:  1  0 108252 22307772  61940 9380060    0    0     0      4 10026 17724  6  3 91  0  0	2014-01-13 08:42:15 MSK
08:42:16 2014:  1  0 108252 22304300  61940 9383900    0    0     0      0  9941 17693  7  3 91  0  0	2014-01-13 08:42:16 MSK
08:42:17 2014: procs -----------memory---------- ---swap--     -----io---- --system-- -----cpu------ ---timestamp---
08:42:17 2014:  r  b  swpd      free   buff   cache   si   so    bi    bo   in   cs    us sy id wa st
08:42:17 2014:  4  0 108252 22300456  61940 9387740    0    0     0     0 10392 18438  7  3  91  0  0	2014-01-13 08:42:17 MSK
08:42:18 2014:  1  0 108252 22296860  61940 9391324    0    0     0    16 10474 18442  7  3  91  0  0	2014-01-13 08:42:18 MSK
dimitrТаблоидКак видно по логам, при затыках
1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 26261 - коннект с инсертами , 26263 - кешрайтерТогда это еще сильнее интригует! Почему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524308
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениснафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш).Ну, это так, конечно: согласно принципу careful writes, он должен записывать страницы в строго определённом порядке.
Ann Harrison - On disk consistency http://www.ibphoenix.com/resources/documents/design/doc_20 when the system writes a page that references another page, that other page must have been written previously in a state that supports the reference. Before writing a page that has a pointer from a record to its back version on another page, the system must have written that other page. Before writing out a new data page, the system must write out a version of a page information page (PIP) that shows the page is in use. The new data page has to be on disk, formatted and happy, before the table's pointer page that references the new page can be written.

Inter-page relationships are handled in the code through a dependency graph in the cache manager. Before a page is written, the cache manager checks the graph and writes out all pages that page depends on. If a change will create a loop in the graph, the cache manager immediately writes as many pages as necessary to avoid the loop.
Только сутки ждать заполнения базы зело не хочется... %-)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524310
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисвроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались.Жаль, что это так. Неудобно во многих случаях.

BTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524315
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

тогда жди вот этого

Vladyslav Khorsun2. Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on

This feature is implemented for disk reads and i'm looking what can be done for disk writes too. Testing and some platform dependent adaptation is needed. (The implementation was tested briefly on Windows and Linux.)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524323
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?

Начал. Уже Владу отправлял результаты. Пока не совсем однозначно. Где-то выигрываем где то проигрываем. Думаю когда вот это "Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on" сделают преимущество будет значительно заметнее.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524357
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?Пока не совсем однозначно. Где-то выигрываем где то проигрываем.а меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем).
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524379
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИ соотв-щий лог vmstat'a:Только я вижу us = 0 в эти моменты ? И сильно не нулевой bo

насколько я понимаю
us == CPU\user
bo == blocks out


ТаблоидПочему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ?Опять пальцем в небо. Тебе же dimitr показал, что "страдает" коммит...
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524388
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

я тебе позже отправлю свой тест в личку. Возможно причина в том, что ось Windows 7 по умолчанию не оптимизирована под сервисы, да и дисковая подсистема там обычная, никаких RAIDов нету.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524397
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоида меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем).

так и должно быть. По идее выигрыш должен быть везде где есть NATURAL скан
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524992
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вести с полей.

Изменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:
Код: plaintext
1.
2.
3.
4.
5.
grep ext4 /etc/fstab;
#UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19 /                       ext4    defaults        1 1
UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19 /                       ext4     noatime,barrier=0    1 1
UUID=22b8cf00-0227-4e30-8cde-9f985e69bcd4 /boot                   ext4    defaults        1 2
UUID=aadceb5b-668d-4968-80fe-554a8a352ad7 /u01                    ext4    defaults        1 2

Запустил с нуля isql + iotop + vmstat.
Сначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек.
Одинг или два раза, впрочем, был затык на несколько десятков сек (около 20 сек вроде).

Но вот после сотого ляма, кажись, тихо наступает Жо:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
19:58:53: gdetl=106410000  min_ms=483 at 16:47:22  curr_ms=11305  max_ms=231549 at 19:38:13
19:59:04: gdetl=106420000  min_ms=483 at 16:47:22  curr_ms=11438  max_ms=231549 at 19:38:13
19:59:26: gdetl=106430000  min_ms=483 at 16:47:22  curr_ms=21527  max_ms=231549 at 19:38:13
20:00:03: gdetl=106440000  min_ms=483 at 16:47:22  curr_ms=37192  max_ms=231549 at 19:38:13
20:02:14: gdetl=106450000  min_ms=483 at 16:47:22  curr_ms=130718  max_ms=231549 at 19:38:13
20:02:18: gdetl=106460000  min_ms=483 at 16:47:22  curr_ms=4733  max_ms=231549 at 19:38:13
20:02:21: gdetl=106470000  min_ms=483 at 16:47:22  curr_ms=2695  max_ms=231549 at 19:38:13
20:02:24: gdetl=106480000  min_ms=483 at 16:47:22  curr_ms=2784  max_ms=231549 at 19:38:13
20:02:27: gdetl=106490000  min_ms=483 at 16:47:22  curr_ms=2702  max_ms=231549 at 19:38:13
20:02:29: gdetl=106500000  min_ms=483 at 16:47:22  curr_ms=2523  max_ms=231549 at 19:38:13
20:02:32: gdetl=106510000  min_ms=483 at 16:47:22  curr_ms=2627  max_ms=231549 at 19:38:13
20:02:34: gdetl=106520000  min_ms=483 at 16:47:22  curr_ms=2594  max_ms=231549 at 19:38:13
20:02:37: gdetl=106530000  min_ms=483 at 16:47:22  curr_ms=2514  max_ms=231549 at 19:38:13
20:02:39: gdetl=106540000  min_ms=483 at 16:47:22  curr_ms=2407  max_ms=231549 at 19:38:13
20:02:59: gdetl=106550000  min_ms=483 at 16:47:22  curr_ms=19704  max_ms=231549 at 19:38:13
20:04:02: gdetl=106560000  min_ms=483 at 16:47:22  curr_ms=63092  max_ms=231549 at 19:38:13

Однако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWrites (что должны БЫЛО БЫ сбрасывать в кеш операционки фиксированные объёмы строк).
Я дождусь его окончания, конечно, дабы затолкать в свой "лог успехов и поражений". После чего попробую с автономками (скрипт см выше).

Если и там всё упрётся, то последнюю и опасную меру, буду добавлять в /etc/fstab атрибут выключения журнала ext4: data=writeback.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524998
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще одна мысль вслух: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt Write barriers enforce proper on-disk ordering
of journal commits
, making volatile disk write caches
safe to use, at some performance penalty. If
your disks are battery-backed in one way or another,
disabling barriers may safely improve performance.Есть смутное ощущение, что поскольку ФБ сам выдаёт нужный порядок записи страниц (careful writes), при любом FW, то эти барьеры вообще нахрен не нужны, когда на хосте трудится только ФБ (а в бол-ве случаев именно так и происходит). И уж тем более при FW = OFF: раз мы сказали, что можем не ждать, когда ось запишет данные на ДИСК, то тем более по барабану, в какой последовательности она будет их туда записывать.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525005
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпо барабану, в какой последовательности она будет их туда записывать.
Не совсем. Уже давным-давно на эти грабли нарывались все СУБД на NTFS: если уронить комп
во время расширения файла, то в каталоге будет записан его новый размер, а новые страницы
останутся пустыми (или наоборот: NTFS журнал откатывал расширение файла, оставляя ссылки
на несуществующие страницы, уже не помню).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525033
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

про барьеры я уже говорил
http://www.sql.ru/forum/964856/linux-opciya-barrier-i-firebird
и вот
http://www.sql.ru/forum/895986/ext4-barrier-0-ili-1
со слов людей может быть до 3 раз хуже.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525039
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
возвращаясь к старым гипотетическим баранам:

ТаблоидСначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек.пишем в кеш оси

ТаблоидНо вот после сотого ляма, кажись, тихо наступает Жоось начинает сливать свой кеш на диск

ТаблоидОднако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWritesт.е. никаких принудительных сбросов кеша не было до тех пор, пока он не забился

ЗЫ. напомнило копирование фильма на флешку под линухом - первые 4 гига пишем мегашустро, потом с черепашьей скоростью дописываем остатки, потом еще 10 минут отключаем устройство :-)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525052
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно будет на idx_under_load базе проверить произв-сть DML, с и без барьеров. Там нет таких сумасшедших объёмов, всё наоборот как раз. Но зато коннектов будет штук 300.
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525093
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ?
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525124
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано.

В итоге, сейчас:
Код: plaintext
1.
2.
3.
4.
[root@oel64 01:49:47 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             243G  144G   88G  63%  / 
tmpfs                  16G     0   16G   0% /dev/shm
. . .


Код: plaintext
1.
[root@oel64 01:49:55 ~]$ grep barrier /etc/fstab
UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19  /  ext4     noatime,barrier=0    1 1

Код: plaintext
1.
[root@oel64 01:50:17 ~]$ mount | grep barrier
/dev/sda4 on  /  type ext4 (rw, noatime,barrier=0 )

И для верности глянул сюда:
Код: plaintext
1.
2.
3.
4.
5.
$ grep -i barrier /var/log/messages
Jan 13 16:39:32 oel64 kernel: dracut: Remounting /dev/disk/by-uuid/2f765571-eba5-47f7-96cb-82d85e8f9a19 with -o noatime,barrier=0,ro
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): barriers disabled
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: barrier=0
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): re-mounted. Opts: barrier=0

Вроде бы всё ОК ?

ЗЫ. Скрипт всё равно в итоге стал ползти как черепаха. Сейчас только 171 млн сделано. Быстрее, конечно, чем в прошлый раз (начал его в 16:47), но всё равно не айс так долго ждать
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525138
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидhvladНа всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано.Ну, можно и рестартануть, если просто перемонтировать не получается :)
...
Рейтинг: 0 / 0
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525229
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Досчиталось" наконец. Но скрипело под занавес сильно:
Код: 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.
05:35:32: gdetl=199740000  min_ms=483 at 16:47:22  curr_ms=29180  max_ms=282271 at 22:40:34
05:36:28: gdetl=199750000  min_ms=483 at 16:47:22  curr_ms=55692  max_ms=282271 at 22:40:34
05:37:08: gdetl=199760000  min_ms=483 at 16:47:22  curr_ms=40686  max_ms=282271 at 22:40:34
05:37:48: gdetl=199770000  min_ms=483 at 16:47:22  curr_ms=40080  max_ms=282271 at 22:40:34
05:38:38: gdetl=199780000  min_ms=483 at 16:47:22  curr_ms=49879  max_ms=282271 at 22:40:34
05:39:19: gdetl=199790000  min_ms=483 at 16:47:22  curr_ms=40548  max_ms=282271 at 22:40:34
05:39:49: gdetl=199800000  min_ms=483 at 16:47:22  curr_ms=29969  max_ms=282271 at 22:40:34
05:39:50: gdetl=199810000  min_ms=483 at 16:47:22  curr_ms=992  max_ms=282271 at 22:40:34
05:39:51: gdetl=199820000  min_ms=483 at 16:47:22  curr_ms=959  max_ms=282271 at 22:40:34
05:39:52: gdetl=199830000  min_ms=483 at 16:47:22  curr_ms=927  max_ms=282271 at 22:40:34
05:39:54: gdetl=199840000  min_ms=483 at 16:47:22  curr_ms=2645  max_ms=282271 at 22:40:34
05:39:55: gdetl=199850000  min_ms=483 at 16:47:22  curr_ms=969  max_ms=282271 at 22:40:34
05:39:56: gdetl=199860000  min_ms=483 at 16:47:22  curr_ms=977  max_ms=282271 at 22:40:34
05:39:57: gdetl=199870000  min_ms=483 at 16:47:22  curr_ms=984  max_ms=282271 at 22:40:34
05:39:58: gdetl=199880000  min_ms=483 at 16:47:22  curr_ms=945  max_ms=282271 at 22:40:34
05:39:59: gdetl=199890000  min_ms=483 at 16:47:22  curr_ms=900  max_ms=282271 at 22:40:34
05:40:00: gdetl=199900000  min_ms=483 at 16:47:22  curr_ms=945  max_ms=282271 at 22:40:34
05:40:01: gdetl=199910000  min_ms=483 at 16:47:22  curr_ms=1003  max_ms=282271 at 22:40:34
05:40:02: gdetl=199920000  min_ms=483 at 16:47:22  curr_ms=926  max_ms=282271 at 22:40:34
05:40:03: gdetl=199930000  min_ms=483 at 16:47:22  curr_ms=974  max_ms=282271 at 22:40:34
05:40:04: gdetl=199940000  min_ms=483 at 16:47:22  curr_ms=1015  max_ms=282271 at 22:40:34
05:40:05: gdetl=199950000  min_ms=483 at 16:47:22  curr_ms=953  max_ms=282271 at 22:40:34
05:40:06: gdetl=199960000  min_ms=483 at 16:47:22  curr_ms=968  max_ms=282271 at 22:40:34
05:40:35: gdetl=199970000  min_ms=483 at 16:47:22  curr_ms=28910  max_ms=282271 at 22:40:34
05:41:31: gdetl=199980000  min_ms=483 at 16:47:22  curr_ms=55973  max_ms=282271 at 22:40:34
05:42:17: gdetl=199990000  min_ms=483 at 16:47:22  curr_ms=46764  max_ms=282271 at 22:40:34
05:42:39: gdetl=200000000  min_ms=483 at 16:47:22  curr_ms=21318  max_ms=282271 at 22:40:34

Так что буду таки пробовать с data=writeback.
...
Рейтинг: 0 / 0
45 сообщений из 45, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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