Его Величество Миллиард (эксперименты с таблицей в 10E9 строк) / Firebird, InterBase

ReSQL.ru

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

Гость

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

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

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

Цитировать

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

Вложение:

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

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

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

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

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

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

25 сообщений из 189, страница 5 из 8

все

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348053

Dimitry Sibiryakov

Участник

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

Рейтинг: 0 / 0

ТаблоидBuffers = 16384
Какой мазохист такой базе даст такой мизерный кэш?..
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

30.07.2013, 01:42:19

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348057

Таблоид

Участник

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

Рейтинг: 0 / 0

Dimitry SibiryakovТаблоидBuffers = 16384
Какой мазохист такой базе даст такой мизерный кэш?..Он в начале был вообще дефолтным, 2048 :-)
Ну, а сколько бы ты сам назначил ?

...

Рейтинг:

0 / 0

30.07.2013, 01:55:21

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348058

Dimitry Sibiryakov

Участник

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

Рейтинг: 0 / 0

Ясно же говорит:
ТаблоидReads = 26771
Вот эту цифру надо как минимум удвоить.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

30.07.2013, 01:58:44

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348060

Таблоид

Участник

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

Рейтинг: 0 / 0

... не взлетает и при 65535:

Код: plaintext

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

C:\MIX\firebird\fb25>isql.exe 192.168.99.44:test01 -user u25 -pas u25
Database:  192.168.99.44:test01, User: u25
SQL> select current_timestamp from rdb$database; set stat on; select first 1 * from t;

        CURRENT_TIMESTAMP
=========================
2013-07-30 01:53:49.7240
<... здесь ждём 2.5 минуты ...>
Statement failed, SQLSTATE = 28000
no permission for SELECT access to TABLE T

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.
27.
28.
29.
30.
31.
32.
33.
34.

// это мы запросили время и тут же получили его
2013-07-30T 01:53:49 .7330 (1562:0x7f1ca65745b8) FREE_STATEMENT
        test01 (ATT_65, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:940

Statement 17:
-------------------------------------------------------------------------------
select current_timestamp from rdb$database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

// это "отложенный" детач после коннекта, он часто вылезает через 5-10 сек. 
// Игнорируем его.
2013-07-30T01:53:52.5800 (1562:0x7f1ca6573148) DETACH_DATABASE
        /opt/fb30cs/security3.fdb (ATT_610, SYSDBA:NONE, NONE, <internal>)

2013-07-30T01:53:52.5800 (1562:0x7f1ca6573148) TRACE_FINI
        SESSION_1

// и только тут мы получили шваброй по лбу: недостаточно прав.
// И прошло всё те же ~165 сек
2013-07-30T01:56:34.7170 (1562:0x7f1ca65745b8) UNAUTHORIZED PREPARE_STATEMENT
        test01 (ATT_65, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:940
                (TRA_79, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

-------------------------------------------------------------------------------
select first 1 * from t
 164984 ms

2013-07-30T01:56:34.7540 (1562:0x7f1ca65745b8) ERROR AT JStatement::prepare
        test01 (ATT_65, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:940
335544352 : no permission for SELECT access to TABLE T

...

Рейтинг:

0 / 0

30.07.2013, 02:03:12

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348096

Таблоид

Участник

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

Рейтинг: 0 / 0

... и при buf=250'000 результат - тоже печалько (разумеется, я поставил перед этим FileSystemCacheThreshold = 256K и рестартанул всё):

Код: plaintext

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

2013-07-30T 08:03:58 .3520 (1541:0x7f06103155b8) FREE_STATEMENT
        test01 (ATT_74, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1568

Statement 17:
-------------------------------------------------------------------------------
select current_timestamp from rdb$database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

2013-07-30T 08:06:44 .5600 (1541:0x7f06103155b8) UNAUTHORIZED PREPARE_STATEMENT
        test01 (ATT_74, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1568
                (TRA_83, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

-------------------------------------------------------------------------------
select first 1 * from t
 166207 ms

2013-07-30T08:06:44.5960 (1541:0x7f06103155b8) ERROR AT JStatement::prepare
        test01 (ATT_74, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1568
335544352 : no permission for SELECT access to TABLE T

...

Рейтинг:

0 / 0

30.07.2013, 08:13:21

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348183

dimitr

Участник

Откуда: PNZ

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

Рейтинг: 0 / 0

Таблоид,

Ты наивно ждешь эффекта от большого кеша при первом выполнении запроса?

...

Рейтинг:

0 / 0

30.07.2013, 10:10:16

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348194

Таблоид

Участник

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

Рейтинг: 0 / 0

dimitrТы наивно ждешь эффекта от большого кеша при первом выполнении запроса?нет, конечно :-)
я всё к тому, что нерационально тратить время на вычитку PP, когда стало ясно, что у мну вообще нет прав на таблицу.

...

Рейтинг:

0 / 0

30.07.2013, 10:19:33

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348209

Таблоид

Участник

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

Рейтинг: 0 / 0

Увеличение кеша на такой базе вообще не помогает. Видимо, просто мало физической памяти.

На "разогретой" базе (насколько этот термин вообще применим к файлу 115 Гб) с cache=250'000 ввожу запрос:

Код: plaintext

SQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id and t1.id+gen_id(g,1)>=0;

В другом окошке делаю:

Код: 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.

SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-30 10: 21:20 .1510                   2748

SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-30 10: 22:20 .3730                   7216


SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-30 10: 25:45 .8050                  23057

SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-30 10: 26:54 .5050                  28446

Итого: в минуту он обмолачивает только 4500...5000 строк :(

...

Рейтинг:

0 / 0

30.07.2013, 10:30:56

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348548

NickDee

Участник

Сообщения: 1 395

Рейтинг: 0 / 0

ТаблоидSQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id and t1.id+gen_id(g,1)>=0Какой у этого запроса план?

...

Рейтинг:

0 / 0

30.07.2013, 13:01:25

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38348580

Таблоид

Участник

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

Рейтинг: 0 / 0

NickDeeТаблоидSQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id and t1.id+gen_id(g,1)>=0Какой у этого запроса план?

Код: plaintext

PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))

...

Рейтинг:

0 / 0

30.07.2013, 13:11:48

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403422

Таблоид

Участник

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

Рейтинг: 0 / 0

Надо тут было проверить еще раз кое-что, на миллиарднике этом.
И сразу вопрос вылез: запустил я создание индекса по полю varchar(8), ждал минут 40, вижу в top'e: ФБ почти ничего не делает.
Запустил тогда скрипт с запросом к mon$-таблицам каждые 10 сек :

mon$-запрос

Код: 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.

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
      -- 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
    --order by a.mon$attachment_id
;

- и ему поработать так 15 минут.
Затем открываю отчет в экселе, и диву даюсь:
1) счетчик reads снова НЕ меняется (такое уже было вроде!)
2) счетчик fetches меняется просто нищенскими темпами - см аттач, графа diff:fetches.
Кроме того, изменение числа фетчей совершенно неравномерное. Пытаться вычислить среднее тут - бесполезняк, разброс просто сильнейший.

пример

Код: plaintext

FETCHES

diff:fetches20088971602008902284512420089077285444200891586881402008918180231220089186144342008923716510220089335289812200893903855102008939952914200894045850620089478147356200895833510521200896113928042008961229902008961621392200896214352220089722411009820089776935452200898281751242008983859104220089939851012620090041611017620090047515902009010473572220090214091093620090261974788

Понятное дело, что периодические падение числа прочитанных фетчей - из-за тормозов в IO. Но это всё предположения.
2 dimitr: может ли ФБ показывать что-то типа статистики ожиданий, т.е. чтобы точно было видно: вот тут у нас 90 фетчей, но мы ждали ответа от "чего-то там" 100500 миллисекунд.

PS. Индекс в итоге строился почти час (3504 сек):

Код: plaintext

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

Current memory = 1112370312
Delta memory = 2796984
Max memory = 1605942776
Elapsed time= 3504.13 sec
Cpu = 0.00 sec
Buffers = 65000
Reads = 4274804
Writes = 460274
Fetches = 2009736589

...

Рейтинг:

0 / 0

21.09.2013, 12:09:52

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403432

dimitr

Участник

Откуда: PNZ

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

Рейтинг: 0 / 0

Таблоидможет ли ФБ показывать что-то типа статистики ожиданий
сейчас нет, в недалеком будущем - возможно

...

Рейтинг:

0 / 0

21.09.2013, 12:41:48

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403521

Таблоид

Участник

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

Рейтинг: 0 / 0

dimitr,

чек мыл, плз.
(Что-то не врубаюсь: запрос к mon$-таблицам в течение работы пяти DML длится по 3-4 минуты. То ли огромный объём IO и ожидание сбросов на диск так сильно влияет, то ли еще чего. Но в целом стало получше, чем было описано в тикете 4179 )

...

Рейтинг:

0 / 0

21.09.2013, 16:04:11

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403572

Таблоид

Участник

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

Рейтинг: 0 / 0

И всё-таки снова вопрос про откаты после срубания незавершенных DML, в том числе при шатдауне базы.
Нельзя ли подправить консерваторию, чтобы движок начинал записывать в firebird.log два факта:
1) начало обратной перемотки (для каждой таблицы)
2) окончание этой перемотки.

Пусть он делает это хотя бы только при shutdown'e, чтобы на это мог смотреть ДБА, который ввёл шатдаун и собирается базу копировать/паковать и проч.
В идеале - также при delete from mon$attachments / mon$statements.

Ибо запустил я с единственного isql'я запрос на апдейт 1 млрд строк (в 16:03), затем через два часа отправил базу в шатдаун:

Код: plaintext

1.
2.

2013-09-21 18:01:57.3302 starting shutdown. . .
2013-09-21 18:02:01.2628 finish shutdown.
        Attributes              full shutdown

И вижу уже 20 минут , что ФБ до сих пор держит файл базы открытым (lsof показывает так), хотя активность процесса ФБ при этом обманчиво нулевая:

Код: plaintext

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

$ top -b -u firebird | grep $(pgrep firebird)
29443 firebird  20   0 2471m 1.4g 5540 S  0.0  8.9 368:18.12 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.0  8.9 368:18.12 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.7  8.9 368:18.14 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.7  8.9 368:18.16 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.3  8.9 368:18.17 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.0  8.9 368:18.17 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.7  8.9 368:18.19 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.0  8.9 368:18.19 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  1.0  8.9 368:18.22 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  0.8  8.9 368:18.23 firebird
29443 firebird  20   0 2471m 1.4g 5540 S  1.7  8.9 368:18.28 firebird

В трейсе для DML-коннекта - разумеется, тоже тишина. Прочухается только после полной "отмотки взад". Неправильно это!

...

Рейтинг:

0 / 0

21.09.2013, 18:29:53

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403576

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

Участник

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

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

Рейтинг: 0 / 0

Таблоид,

не место этому в firebird.log. Я понимаю если бы ты это в трейсе попросил выводить, да и то для каждой таблицы сомнительно...

...

Рейтинг:

0 / 0

21.09.2013, 18:36:53

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403577

Таблоид

Участник

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

Рейтинг: 0 / 0

Симонов Денисне место этому в firebird.log. Я понимаю если бы ты это в трейсе попросил выводить, да и то для каждой таблицы сомнительно...А что с ним станется, с firebird.логом, опухнет и лопнет ?
Вот я останавливаю базу шатдауном - и что, мне трейс перед/после этого запускать, дабы увидеть сообщение о завершении отмотки ?
(да и много ли персон из почтеннейшей публики запускают у себя трейс-то ?...)

...

Рейтинг:

0 / 0

21.09.2013, 18:45:00

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403582

Таблоид

Участник

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

Рейтинг: 0 / 0

ТаблоидПрочухается только после полной "отмотки взад"Ну-с, встречаем. Через 40 минут:

Код: plaintext

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

2013-09-21T 18:40 :05.1670 (29443:0x7f2e1f68ffb0) FAILED EXECUTE_STATEMENT_FINISH
        t10e9 (ATT_265, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
        C:\1Install\fb30\isql.exe:936
                (TRA_497, CONCURRENCY | WAIT | READ_WRITE)

Statement 66:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01 where id between 1 and 999999999
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
0 records fetched
9381308 ms, 1649780 read(s), 255430 write(s), 12948213 fetch(es), 3005384 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       6                                                           
T                                            296256    296255                        296255                   

2013-09-21T18:40:05.5370 (29443:0x7f2e1f68ffb0) ERROR AT JStatement::execute
        t10e9 (ATT_265, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
        C:\1Install\fb30\isql.exe:936
335544528 : database t10e9 shutdown

Число апдейтов и бекаутов - смешное, 296 тыс. Фетчей - тоже ерунда, 1.3 млн.
Чего он там сопли жевал столько времени - хз.

DDL таблицы:

Код: plaintext

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

SQL> show table t;
ID                              INTEGER Nullable
S01                             VARCHAR(8) Nullable
S02                             VARCHAR(8) Nullable
SQL> show index;
T_ID INDEX ON T(ID)
T_S01 INDEX ON T(S01)
T_S02 INDEX ON T(S02)

gstat -r до начала bulk-DML'ей:

Код: 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.

T (128)
    Primary pointer page: 147, Index root page: 157
    Total formats: 1, used formats: 1
    Average record length: 28.99, total records: 1000000000
    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: 28.00, compression ratio: 0.97
    Pointer pages: 1177, data page slots: 4273505
    Data pages: 4273505, average fill: 66%
    Primary pages: 4273505, full pages: 4273504, swept pages: 0
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 4273504
        80 - 99% = 0

    Index T_ID (0)
        Root page: 4277245, depth: 3, leaf buckets: 431472, nodes: 1000000000
        Average node length: 6.99, total dup: 0, max dup: 0
        Average key length: 3.00, compression ratio: 1.74
        Average prefix length: 4.22, average data length: 1.00
        Clustering factor: 4273505, ratio: 0.00
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 431471

    Index T_S01 (1)
        Root page: 4708932, depth: 3, leaf buckets: 459216, nodes: 1000000000
        Average node length: 7.42, total dup: 107878730, max dup: 7
        Average key length: 3.44, compression ratio: 2.33
        Average prefix length: 6.82, average data length: 1.18
        Clustering factor: 999999768, ratio: 1.00
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 459215

(по второму индексу аналогично всё)

...

Рейтинг:

0 / 0

21.09.2013, 18:51:51

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403585

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

Участник

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

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

Рейтинг: 0 / 0

Таблоид,

одно дело записать в firebird.log что шатдаун был, другое - пытаться туда засунуть информацию о внутренностях. Вот зачем это?

...

Рейтинг:

0 / 0

21.09.2013, 18:58:25

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403592

Таблоид

Участник

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

Рейтинг: 0 / 0

Симонов Денисодно дело записать в firebird.log что шатдаун был, другое - пытаться туда засунуть информацию о внутренностях. Вот зачем это?тогда уж инфу о GC тоже из лога убирать надо. Чем не внутренности ?...
0xFF. А про спам errno=104/110 я уж вообще не говорю - такие важнейшие события отражаются в логе...

...

Рейтинг:

0 / 0

21.09.2013, 19:08:11

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403599

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

Участник

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

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

Рейтинг: 0 / 0

Таблоид,

хорошо представь себе у тебя 250 активных коннектов. Вдруг ты решил сделать полный шатдаун. Что будет содержаться в firebird.log в этом случае? Причём пользователи могут работать с разными таблицами.

По поводу GC, errno=104/110 вроде бы есть тикет по разделению лога на несколько. Правда многим это не нравится.
errno=104/110 не совсем спам они свидетельствуют о наличии проблем в сети.

...

Рейтинг:

0 / 0

21.09.2013, 19:27:15

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403615

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

Участник

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

Рейтинг: 0 / 0

Таблоид> Вот я останавливаю базу шатдауном - и что, мне трейс перед/после
Таблоид> этого запускать, дабы увидеть сообщение о завершении отмотки ?

Ага. А зачем тебе это сообщение-то?

> (да и много ли персон из почтеннейшей публики запускают у себя трейс-то ?...)

Вряд ли. Но запускающих шатдаун да ещё желающих увидеть при этом
какие-то сообщения о каких-то отмотках в логе - на порядок меньше. :)

Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

21.09.2013, 20:05:19

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403659

Таблоид

Участник

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

Рейтинг: 0 / 0

Симонов Денисхорошо представь себе у тебя 250 активных коннектов. Вдруг ты решил сделать полный шатдаун. Что будет содержаться в firebird.log в этом случае? Причём пользователи могут работать с разными таблицами.а не надо путать активный коннект с активным (выполняющимся в момент выдачи шатдауна) стейтментом. Первых - да, полно. Вторых (при которых соб-сно и будет "отмотка взад") - хорошо, если десяток-другой будет. В oltp системах запросов хоть и много, но 99.9% из них - короткие. Дальше юзер тупо смотрит на результат или вводит там что-то в морде приложения.

Симонов ДенисПо поводу GC, errno=104/110 вроде бы есть тикет по разделению лога на несколько. Правда многим это не нравится. errno=104/110 не совсем спам они свидетельствуют о наличии проблем в сети.Это в любом случае проблемы НЕ Firebird'a, а железячников. А про errno=10054 (под виндой, по кр. мере)- вообще песня. Достаточно из isql закрыть "крестиком" снять его pskill'ом, даже просто выйти из него по Ctrl- Break - всё, "произошла проблема, подробности смотрите в логе".

...

Рейтинг:

0 / 0

21.09.2013, 21:34:22

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403662

Таблоид

Участник

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

Рейтинг: 0 / 0

Гаджимурадов РустамАга. А зачем тебе это сообщение-то?Мну давно интересно, что будет с базой, если после шатдауна её тут же начать копировать куда-нить...
Ну, то есть так: ФБ тихо дописывает в неё свои откаты срубленных BULK_DML'ей, а я чихал на это и копирую базу в этот же исторический момент на "внешний носитель"
Жаль, что база с таблицей-миллиардником занимает больше половины диска, скопировать надо было для "домашнего просмотра" :-)

...

Рейтинг:

0 / 0

21.09.2013, 21:38:05

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403675

dimitr

Участник

Откуда: PNZ

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

Рейтинг: 0 / 0

ТаблоидВот я останавливаю базу шатдауном - и что
CORE-3809 можно уже удалять из трекера? А если нет, то какого ляда мы тут видим эти стенания? Ты проси или быстрый шатдаун или трейс медленного шатдауна, но оба вместе это уже шизофрения.

...

Рейтинг:

0 / 0

21.09.2013, 21:52:05

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

Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)

#38403695

Таблоид

Участник

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

Рейтинг: 0 / 0

dimitrТаблоидВот я останавливаю базу шатдауном - и что CORE-3809 можно уже удалять из трекера? А если нет, то какого ляда мы тут видим эти стенания? Ты проси или быстрый шатдаун или трейс медленного шатдауна, но оба вместе это уже шизофрения.Быстрый шатдаун, после которого уже точно нет никакой записи в файл базы - важнее всего.
Если же он недостижим (на сегодняшний день) и в момент шатдауна были срублены bulk_DML'и, то обязательно надо выводить хоть какое-то сообщение об этом. Если такого сообщения не выводить, нужно где-то в официальной доке отметить этот "артефакт" и сказать, следует ли ДБАям следить за ним или нет (попросту говоря: следует ли после шатдауна вводить пару раз lsof, дабы убедиться что база больше не держится ФБ-процессом).

Даже если шатдаун срубит сразу 300 активных стейтментов (это сколько же тогда коннектов должно быть ? 3000 ?), сообщений будет 300*2 = 600 - не страшно, диск не переполнится.
Моё мнение - место таким сообщениям в логе сервера, а не в трейсе.

ЗЫ. И кстати! Этот тикет, 3809, он же не только про роллбаки, но и про невозможность в *линуксе* убить процесс ФБ командой /etc/init.d/firebird stop, которая выдает к тому же бравурное "ОК", а на самом деле процесс живой! И я видел это до самых недавних пор в трёшке, когда срубал 300-400 окон теста на массовые коннекты / ожидание ими вставки строки / принудительный их дисконнект.
Как дело с этим на нынешнем снапшоте - не знаю, еще не проверял.

...

Рейтинг:

0 / 0

21.09.2013, 22:20:48

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

25 сообщений из 189, страница 5 из 8

все

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

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

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

start [/forum/topic.php?fid=40&msg=38403592&tid=1564260]:	0ms
get settings:	8ms
get forum list:	19ms
check forum access:	4ms
check topic access:	4ms
track hit:	49ms
get topic data:	11ms
get forum data:	3ms
get page messages:	89ms
get tp. blocked users:	2ms
others:	219ms

total:	408ms

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