ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
189 сообщений из 189, показаны все 8 страниц
  все  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38032991
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Дано:
1) Из текущих сырцов собран LI-V2.5.3.26554 (никаких патчей от Источников Света к сырцам не применял).
2) Имеется база с единственной таблицей `t` (id int, s varchar(50), h bigint; поле `id` - индексное), в таблице 1 миллиард записей. Размер базы - 118 Гб.
3) Никаких "фрагментов" файла базы в кеше операционки нет.

Вижу на такой базе несколько удивительных эффектов (все коннекты к базе - через TCP).

ЭКСПЕРИМЕНТ-1.
Запускаю трейс, в другом окне - isql.
Ввожу в isql: select * from t where id = 789456123; (такой ID'шник - существует).
Выборка по индексу единственной записи уходит в себя на... 5 минут.
ДЕ мне объяснил, что это время тратится на "вычитку" PP. Но не многовато ли 5 минут читать эту самую "пэ-пэ" ? Я знаю, что скорость копирования файлов на этой машине ~50 Mb/sec ==> за 300 сек можно скопировать ~15 Gb.
Как примерно определить, сколько места занимает PP ?
Далее, в трейсе вышеприведенный запрос появится только после того, как будет завершена эта самая "вычитка" PP. И там будет некоторое микроскопическое время, которое он якобы делался.
Я понимаю, что трейс на сегодня показывает не все "служебные действия" (sweep только) - но нельзя ли расширить его в этом вопросе ?

ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;


Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.
Код: 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.
 session #1 
SQL> out /dev/null; set stat on; set plan on;
SQL> select * from t where id between 123456789 and 456789123;

PLAN (T INDEX (T_ID))
-- ушло в себя --

 session #2 
SQL> commit; select * from mon$statements where mon$state<>0 and mon$attachment_id<>current_connection;

MON$STATEMENT_ID                38
MON$ATTACHMENT_ID               49
MON$TRANSACTION_ID              184
MON$STATE                       2
MON$TIMESTAMP                   2012-11-10 17:21:00.8280
MON$SQL_TEXT                    0:4
select * from t where id between 123456789 and 456789123
MON$STAT_ID                     7


SQL> commit; delete from mon$statements where mon$attachment_id<>current_connection;
SQL> commit; select * from mon$statements where mon$state<>0 and mon$attachment_id<>current_connection;

MON$STATEMENT_ID                38
MON$ATTACHMENT_ID               49
MON$TRANSACTION_ID              184
MON$STATE                       2
MON$TIMESTAMP                   2012-11-10 17:21:00.8280
MON$SQL_TEXT                    0:4
select * from t where id between 123456789 and 456789123
MON$STAT_ID                     7

(и так можно повторять select + delete + select + ... хоть до посинения)

ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).
В подключающемся окне я запускал батник, в котором непосредственно перед isql указано: echo %time%.
Затем посмотрел, в какой момент времени трейс покажет установку соединения от этого второго окна.
Итого:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
C:\MIX\firebird\fb25>echo 17:43:26,11
 17:43:26 ,11

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n
Database:  192.168.0.59:t1

Трейс:
2012-11-10T17:44:19.9100 (3754:0x2aaaab252728) TRACE_INIT
        SESSION_5


2012-11-10T 17:44:19 .9100 (3754:0x2aaaab252728) ATTACH_DATABASE
        t1 (ATT_51, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1780

2012-11-10T17:44:19.9130 (3754:0x2aaaab252728) START_TRANSACTION
        t1 (ATT_51, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1780
                (TRA_209, CONCURRENCY | WAIT | READ_WRITE)
...
Рейтинг: 0 / 0
10.11.2012, 17:53:32
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033004
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. Повторил эксперимент_2 на "разогретой" базе - ноль эмоций: index-выборка из 10Е9-таблицы через mon$statements не срубается (вводил в другом окне commit; delete from mon$statements where ... ; commit; не менее 10 раз - всё бестолку).

Трейс этих лихорадочных попыток срубить запрос см. в аттаче.
...
Рейтинг: 0 / 0
10.11.2012, 18:09:51
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033045
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидВыборка по индексу единственной записи уходит в себя на... 5 минут.
не выборка, а prepare запроса, потому что да, prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей).
и на терабайтной базе было не 5 минут, а 45 секунд, и не на миллиарде записей, а на 3.7 миллиардах.

ТаблоидИ там будет некоторое микроскопическое время, которое он якобы делался.
да, тоже есть такой эффект. Якобы время сканирования pp для сервера пролетело как один миг.
...
Рейтинг: 0 / 0
10.11.2012, 19:01:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033061
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvи на терабайтной базе было не 5 минут, а 45 секунд, и не на миллиарде записей, а на 3.7 миллиардах.Очень странно. У мну эта база сейчас на нормальном linux-серваке, с вменяемым дисковым массивом. Но время таки не 45 сек, а гораздо больше.
...
Рейтинг: 0 / 0
10.11.2012, 19:21:24
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033065
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvне выборка, а prepare запроса, потому что да, prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей)..А зачем ему оценивать кардинальность, когда нет соединения с другим источником и есть эвристика оптимизатора, при которой индексное поле обязательно будет задействовано в случае указания его в where-предикате ? То есть, зачем ему что-то там оценивать, когда нет альтернативы и всё равно придется "ходить лошадью индексом" ?
...
Рейтинг: 0 / 0
10.11.2012, 19:26:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033073
avp_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avp_
Участник
ТаблоидА зачем ему оценивать кардинальность, когда нет соединения с другим источником и есть эвристика оптимизатора, при которой индексное поле обязательно будет задействовано в случае указания его в where-предикате ? То есть, зачем ему что-то там оценивать, когда нет альтернативы и всё равно придется "ходить лошадью индексом" ?

Кардинальность оценивается всегда - цена универсальности оптимизатора. Он вполне может решить не использовать индекс и пройтись натуралом. Другой вопрос, что нет заточки для частных синтетических случаев, когда например индекс уникальный.
...
Рейтинг: 0 / 0
10.11.2012, 19:36:59
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033080
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
avp_Он вполне может решить не использовать индекс и пройтись натуралом.Не в ФБ. Если по полю создан индекс и это поле указано в предикате, то индекс *будет* задействован, помимо нашей воли и сознания. Даже при выборке всех строк.
...
Рейтинг: 0 / 0
10.11.2012, 19:44:02
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033094
avp_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
avp_
Участник
Таблоидavp_Он вполне может решить не использовать индекс и пройтись натуралом.Не в ФБ. Если по полю создан индекс и это поле указано в предикате, то индекс *будет* задействован, помимо нашей воли и сознания. Даже при выборке всех строк.
Может быть натурал и не заложен, но порядок соединения и используемые индексы однозначно оценивает через умножение кардинальности на селективность.
...
Рейтинг: 0 / 0
10.11.2012, 19:49:39
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033114
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидОчень странно. У мну эта база сейчас на нормальном linux-серваке, с
вменяемым дисковым массивом. Но время таки не 45 сек, а гораздо больше.
Ничего странного: у тебя страница четыре килобайта, а у ДК - 16. Время чтения (как
обнаружил Пол Ривз на конференции) зависит не от объёма, а от количества чтений, коих у
тебя вчетверо больше.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.11.2012, 20:09:30
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033167
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНе в ФБ
не в текущих версиях ФБ, не более того. Это всегда может измениться.
...
Рейтинг: 0 / 0
10.11.2012, 21:13:21
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033173
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovВремя чтения (как
обнаружил Пол Ривз на конференции) зависит не от объёма, а от количества чтений, коих у
тебя вчетверо больше.Поздравляю с открытием
Вот тебе еще одно "откровение" - для SSD это тоже верно, хоть и в меньшей степени.
...
Рейтинг: 0 / 0
10.11.2012, 21:20:54
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033174
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид ЭКСПЕРИМЕНТ-1.
Я понимаю, что трейс на сегодня показывает не все "служебные действия" (sweep только) - но нельзя ли расширить его в этом вопросе ?
трейс должен это время показывать в строке, относящейся к prepare

Таблоид ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;


Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.
особенность текущей реализации, к сожалению. Удалить (сиречь: остановить) можно только активный риквест. А в твоем случае он всегда опознается как неактивный (stalled), мы это уже обсуждали недавно. Я подумаю, что тут можно сделать.

Таблоид ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).
вот это фигня какая-то, не должно такого быть
...
Рейтинг: 0 / 0
10.11.2012, 21:21:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033186
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladПоздравляю с открытием
Да для меня-то это открытием не было, но удивление Пола было так забавно, что я не
преминул встрять.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
10.11.2012, 21:27:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033259
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоид ЭКСПЕРИМЕНТ 3.
Срубил окно, пытавшееся завалить выборку, но саму выборку оставил работать.
Запустил с другой машины isql и попытался подключиться к этой же базе.
Результат: подключение к базе из второго isql-окна длится... МИНУТУ(!).вот это фигня какая-то, не должно такого бытьЭто повторяется уже как минимум в третий раз.
И происходит сиё, когда :
0) во втором isql-окне делаем quit;
1) в "молотильном" isql-окне ждём, когда завершится выборка по диапазону, для верности делаем там commit;
2) даём серверу заняться чем-то, что вытеснит базу или часть её из кеша операционки (увы, но я не сразу вспомнил про FileSystemCacheThreshold, см ниже)
3) в "молотильном окне" запускаем одиночный index-поиск:
Код: sql
1.
select * from t where id=789456123;

При этом в трейсе *НЕ* появится никакого сообщения о prepare stetement. Будет только START_TRANSACTION. Акцентирую на этом особое внимание, т.к. из слов kdv выше следует обратное: что затраты идут именно на prepare.
4) снова пытаемся подключиться вторым isql-окном:
Код: plaintext
1.
echo %time%
isql 192.168.0.59:t1 -n
В моём случае echo-команда сработала в 22:05:21,70 . А в трейсе сообщение об аттаче появилось только в 22:06:31

В итоге, в трейсе на момент завершения одиночного index-поиска, который длился 201 секунду(!), вижу:
 
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.
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.
2012-11-10T22:05:08.3830 (3754:0x2aaaab256b60) FREE_STATEMENT
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249

Statement 40:
-------------------------------------------------------------------------------
select * from t where id between 123456789 and 456789123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))

2012-11-10T22:05:08.4290 (3754:0x2aaaab256b60) COMMIT_TRANSACTION
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_289, CONCURRENCY | WAIT | READ_WRITE)
     17 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2012-11-10T 22:05:18 .9720 (3754:0x2aaaab256b60) START_TRANSACTION /*это запуск одиночного index-поиска*/
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)

2012-11-10T22:06:31.7770 (3754:0x2aaaab256068) TRACE_INIT
        SESSION_9

/* это в базу проломилось второе isql-окно, ожидавшее минуту(!) */
2012-11-10T22:06:31.7770 (3754:0x2aaaab256068) ATTACH_DATABASE
        t1 ( ATT_55 , SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2184

2012-11-10T22:06:31.7790 (3754:0x2aaaab256068) START_TRANSACTION
        t1 (ATT_55, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2184
                (TRA_304, CONCURRENCY | WAIT | READ_WRITE)

2012-11-10T 22:08:40 .0550 (3754:0x2aaaab256b60) PREPARE_STATEMENT /*только здесь наступает prepare одиночного index-поиска! */
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
 201067 ms

2012-11-10T22:08:40.0550 (3754:0x2aaaab256b60) EXECUTE_STATEMENT_START
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_303, CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))

2012-11-10T22:08:40.0980 (3754:0x2aaaab256b60) EXECUTE_STATEMENT_FINISH
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                (TRA_303, CONCURRENCY | WAIT | READ_WRITE)

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
1 records fetched
      42 ms, 7 read(s), 7 fetch(es) 

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                                 1                                                           

2012-11-10T22:08:40.0980 (3754:0x2aaaab256b60) CLOSE_CURSOR
        t1 (ATT_53, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249

Statement 41:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
Прошу обратить внимание на два момента времени:
1) старт транзакции, в которой отдана команда одиночного index-поиска: 2012-11-10T 22:05:18 .9720
2) выполнение prepare этого index-запроса: 2012-11-10T 22:08:40 .0550
Разница между ними равна 3 мин 21 сек, т.е. около 201 секунды.
Можно, конечно, изо всех сил не поверить своим глазам и сказать себе "я ошибся".
Однако, в isql того окна, где был одиночный index-поиск, вижу то же самое - общее время более трёх минут:
 
isql stats
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SQL> select * from t where id=789456123;

PLAN (T INDEX (T_ID))
Current memory = 3939480
Delta memory = 11144
Max memory = 260690296
 Elapsed time= 201.12 sec 
Cpu = 0.00 sec
Buffers = 768
Reads = 29897
Writes = 0
Fetches = 29901
Прошу также обратить внимание на совершенно "удивительные" 42 мс и 7 фетчей , которые якобы потребовались для этого запроса.

PS. Файловый кеш линуха сильно мешает чистоте замеров. Выключу-ка его: поставлю FileSystemCacheThreshold = 75 при кеше коннекта = 768, "пущай полетает"
...
Рейтинг: 0 / 0
10.11.2012, 22:41:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033261
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Пардон муа, опечатался при правке предыдущего поста. Вот эта цитата:вот это фигня какая-то, не должно такого быть- принадлежит не Владу, а Дмитрию.
...
Рейтинг: 0 / 0
10.11.2012, 22:43:12
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033264
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrтрейс должен это время показывать в строке, относящейся к prepareОн там показываает какой-то момент времени, но не длительность этого самого препаре. См. выше, повторю на всякий случай еще раз:Таблоид
Код: plaintext
1.
2.
3.
2012-11-10T 22:08:40 .0550 (3754:0x2aaaab256b60) PREPARE_STATEMENT /*только здесь наступает prepare одиночного index-поиска! */
        t1 ( ATT_53 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/firebird/bin/isql:5249
                ( TRA_303 , CONCURRENCY | WAIT | READ_WRITE)
где тут видно временн ы е затраты ?
...
Рейтинг: 0 / 0
10.11.2012, 22:46:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033276
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидгде тут видно временн ы е затраты ?Отбой, глаза замылены уже. Вижу :-)

Выключил использование кеша операционки (поставил fileSystemCacheThreshold = 0), рестартовал ФБ.
Запустил снова isql с одиночным index-запросом.
В соседнем окне выполнял батник, выводящий время (echo %time%) и натравливающий isql на простенький скрипт: select current_timestamp from rdb$database; commit;
Длительность установки коннектов в этом окне составляет 2-3 сек (причём в первый запуск isql - 10 сек, второй - 7 сек).

Затраты на прераре в окне с одиночным index-поиском составили 121 сек.
...
Рейтинг: 0 / 0
10.11.2012, 22:57:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033287
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Итак, загадочная пауза вызвана затратами на prepare.
Тогда вопрос: что там скрывается, в этих затратах ?

Запрос, который надо выполнить:
Код: sql
1.
select * from t where id = :a_id

- для разбора тривиален и должен ( вроде бы ) привести к мгновенному рождению плана его выполнения. Именно в виду эвристик, которые заложены в нынешний код ФБ.

Тогда что еще включено в "препарирование" ?
...
Рейтинг: 0 / 0
10.11.2012, 23:05:57
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033297
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидИтак, загадочная пауза вызвана затратами на prepare.
я ж сразу сказал...

ТаблоидТогда что еще включено в "препарирование" ?
просчет кардинальности, т.е. скан pp. Он самый долгий на больших базах. Вернее, на больших базах более заметен, чем на мелких.
И, чем больше таблиц в запросе, тем дольше будет просчет, т.к. кардинальность считается для всех таблиц (вроде). Подробнее разве что в

http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/tags/R2_5_2/src/jrd/Optimizer.cpp?revision=57336&view=markup
...
Рейтинг: 0 / 0
10.11.2012, 23:22:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033300
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdv prepare читает PP таблицы для определения ее кардинальности (хочет понять, сколько там записей).Ну так я снова хочу поинтересоваться: сколько можно читать PP единственной таблицы, если база имеет такую статистику:
 
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.
Database "t1.fdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              98
        Page size               4096
        ODS version             11.2
        Oldest transaction      6
        Oldest active           84
        Oldest snapshot         84
        Next transaction        87
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      10
        Implementation ID       24
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Nov 6, 2012 0:38:41
        Attributes              force write

    Variable header data:
        *END*


Database file sequence:
File t1.fdb is the only file

Analyzing database pages ...
T (132)
    Primary pointer page: 169, Index root page: 170
    Average record length: 71.99, total records: 1000000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 28567997, data page slots: 28567997, average fill: 76%
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 28567997
        80 - 99% = 0

    Index T_ID (0)
        Depth: 4, leaf buckets: 1745793, nodes: 1000000000
        Average data length: 1.01, total dup: 0, max dup: 0
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 1745793

Как хотя бы примерно оценить размер этой PP ?
...
Рейтинг: 0 / 0
10.11.2012, 23:23:49
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033301
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидТогда что еще включено в "препарирование" ?
тьфу. кроме кардинальности еще наличие индексов и их селективность. Но с индексами проще, в том смысле, что найти их все и вытащить селективность - это быстро делается.
Хотя, была какая-то штука, при большом количестве таблиц и индексов был долгий перебор вариантов. Но вроде это давно починили.
...
Рейтинг: 0 / 0
10.11.2012, 23:24:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033309
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvросчет кардинальности, т.е. скан pp . <...>
Подробнее разве что в

http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/tags/R2_5_2/src/jrd/Optimizer.cpp?revision=57336&view=markup гы... и где ТАМ искать пресловутый "скан PP" ?
(по словам `pp` и `pointer`, кстати, ничего релевантного там нету!)
...
Рейтинг: 0 / 0
10.11.2012, 23:33:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033323
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНу так я снова хочу поинтересоваться: сколько можно читать PP единственной таблицы, если база имеет такую статистику... Как хотя бы примерно оценить размер этой PP ?
28567997 страниц данных, это примерно 3 млн pointer pages. Столько случайных дисковых чтений нужно для оценки кардинальности таблицы. Ты же специально выбрал самый поганый сценарий, с минимальным размером страницы. Вот и огребай.
...
Рейтинг: 0 / 0
10.11.2012, 23:44:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033327
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
dimitr28567997 страниц данных, это примерно 3 млн pointer pages
пардон, 30 тыс конечно же. Пиво мешает арифметике :-) Но отмечу, что эти 30 тыс равномерно размазаны по 118ГБ.
...
Рейтинг: 0 / 0
10.11.2012, 23:46:45
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033346
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdvкардинальность считается для всех таблиц (вроде)Нет конечно.

А вот при аттаче выполняются некоторые служебные запросы, плюс читается rdb$pages.
...
Рейтинг: 0 / 0
11.11.2012, 00:07:58
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033353
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидКак хотя бы примерно оценить размер этой PP ?Ты не знаешь р-р страницы ? :)
Кол-во PP можно узнать, зная кол-во DP и р-р страницы:

cntPP ~ cntDP / ((pageSize - 16) / 5)

В твоём случае 28567997 / (4080 / 5) = 35010
...
Рейтинг: 0 / 0
11.11.2012, 00:12:56
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033361
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
hvladcntPP ~ cntDP / ((pageSize - 16) / 5)

В твоём случае 28567997 / (4080 / 5) = 35010Промахнулся немного. Правильнее будет
cntPP ~ cntDP / ((pageSize - 16) * 8 / 34), и
28567997 / (4080 *8 / 34) = 29759 (как и сказал dimitr)
...
Рейтинг: 0 / 0
11.11.2012, 00:17:22
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033386
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladПравильнее будет
cntPP ~ cntDP / ((pageSize - 16) * 8 / 34), и
28567997 / (4080 *8 / 34) = 29759 (как и сказал dimitr)Ну, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ? Даже если они там "размазаны" внутри базы, их смещения от начала .fdb - они известны или нет ?

И еще. Уже несколько дней всё порываюсь спросить, да всё как-то стеснялся...
Почему isql показывает для одиночного index-поиска (не "первого с момента коннекта", а любого - хоть сто пятого) удивительно близкие к твоим 29.8 тысячам значения reads & fetches:
 
Код: 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.
SQL> select * from t where id=789456123;

          ID S                                                                      H
============ ================================================== =====================
   789456123 CC5C1DB6-82F3-4939-B90D-AAC06E68503B96BD2309-8C76-    545036015901582493

Current memory = 5212096
Delta memory = -8
Max memory = 5277536
Elapsed time= 0.38 sec
Cpu = 0.00 sec
Buffers = 1024
Reads =  29895 
Writes = 0
Fetches =  29897 

SQL> select * from t where id=1;

          ID S                                                                      H
============ ================================================== =====================
           1 F31D6124-E234-4011-BCDB-4AA6411AC44CA290E395-252B-    563767665119367965

Current memory = 5212040
Delta memory = -56
Max memory = 5277536
Elapsed time= 1.21 sec
Cpu = 0.00 sec
Buffers = 1024
Reads = 29893
Writes = 0
Fetches = 29897
SQL> select * from t where id=999999999;

          ID S                                                                      H
============ ================================================== =====================
   999999999 6113D62D-64D6-4E62-AE80-43CC4745924835EA6410-4F2B-    625889790735929133

Current memory = 5212096
Delta memory = 56
Max memory = 5277536
Elapsed time= 1.53 sec
Cpu = 0.00 sec
Buffers = 1024
Reads = 29894
Writes = 0
Fetches = 29897
- а трейс по этим же запросам - какие-то марсианские 5...7 reads/fetches ?
 
Код: 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.
Statement 39:
-------------------------------------------------------------------------------
select * from t where id=789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
1 records fetched
      0 ms,  7 read(s), 7 fetch(es) 

Table                             Natural     Index    Update    Insert    Delete   Backout
***********************************************************************************************
T                                                 1                                           

<...>
Statement 40:
-------------------------------------------------------------------------------
select * from t where id=1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
1 records fetched
    124 ms, 5 read(s), 7 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                                 1  
<...>

select * from t where id=999999999
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (T_ID))
1 records fetched
   1339 ms, 6 read(s), 7 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                                 1
...
Рейтинг: 0 / 0
11.11.2012, 00:42:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033390
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ? Даже если они там "размазаны" внутри базы, их смещения от начала .fdb - они известны или нет ?
все смещения, разумеется, известны. А в целом это вопрос исключительно к твоей дисковой (и, возможно, файловому кешу). Не все меряется байтами. Перемещение головки (особенно сильно далеко) - намного медленнее, чем чтение страницы.

ТаблоидУже несколько дней всё порываюсь спросить, да всё как-то стеснялся...
isql включает статистику препаре, трейс видимо нет. Или ты опять не туда смотришь. Мне уже надоедает повторять одно и то же.
...
Рейтинг: 0 / 0
11.11.2012, 00:50:00
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033392
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrisql включает статистику препаре, трейс видимо нет.Это понятно. Интересует другое: зачем при каждом прераре, невзирая на характер sql-запроса , перечитываются все 30 тыс PP той таблицы, которая в нём упомянута ?
Вот, например, здесь даже таблица не нужна, не то что индекс, - а всё равно будут перекопаны "все грядки":
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
bash-3.2$ isql localhost:t1 -n
Database:  localhost:t1
SQL> set stat on;
 SQL> select 1 from t rows 1; 

    CONSTANT
============
           1

Current memory = 5205088
Delta memory = 264
Max memory = 5276536
Elapsed time= 0.13 sec
Cpu = 0.00 sec
Buffers = 1024
 Reads = 29884 
Writes = 0
Fetches = 29887
...
Рейтинг: 0 / 0
11.11.2012, 01:00:17
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033394
Фотография PEAKTOP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PEAKTOP
Участник
ТаблоидВыключил использование кеша операционки (поставил fileSystemCacheThreshold = 0), рестартовал ФБ. Запустил снова isql с одиночным index-запросом.
я вот тут, кстати давеча наблюдал "несрабатывание" DELETE FROM MON$ATTACHEMNTS WHERE MON$ATTACHMENT_ID = ...; до тех пор, пока сам процесс fb_inet_server через диспетчер задач не срубишь. Причем ситуация была на аварийном сервере, где из RAID1 винт вывалился и оно летело на трех винтах вместо четырех. Тогда у клиента остановить предприятие нельзя было, ждал выходных.

После пересобирания RAID и переустановки ОСи проблема исчезла сама собой. Правда, FileSystemCache я не пользую, зато у классика кеш в 16000 страниц по 8192 выставлен (а че мелочиться ?), база - маленькая 2Gb.
------------------
Другой пример, полгода назад. У другого клиента начал подыхать винт, причем не предупредив об этом никого (в смысле, нет шоб сразу бэд-секторами пойти, а как-то по-тихоньку помирать начал, глюки были неочевидными). Аналогично было c MON$ATTACMENTS, который стал в тот момент ReadOnly. Заменили винт - MON$ATTACMENTS стал RW.
------------------
Вот и мысли у меня, что может MON$ATTACHMENTS как-то от работы дисковой системы сильно зависит ? И если дисковую подсистему колбасит (хардварно или программно), то MON$ATTACHMENTS переходит в ReadOnly. и примеры Таблоида подтверждают, что даже когда дисковую подсистему не колбасит, а она просто... э-э-э... занята, то MON$ATTACHMENTS становиться немного не в курсе последних событий.

Я к чему это все: основная задумка использования MON$ATTACHMENTS была в том, чтобы правоверно и строго по Корану срубить коннект, который че-то не так делает (ну, там запросы кривые, или просто базу вешает). А если оно так сильно от дисков зависит, то смысл в нем ? проще тогды уже через туннель на сервак зайти и выполнить kill ненужного процесса.
...
Рейтинг: 0 / 0
11.11.2012, 01:01:23
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033399
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ?Раздели 201 на 30000 и сравни с avg seek time своего диска. Вряд ли оно меньше или даже сравнимо с 7 мс...
...
Рейтинг: 0 / 0
11.11.2012, 01:06:39
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033401
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PEAKTOPMON$ATTACHMENTS становиться немного не в курсе последних событий.Не, погодь! У мну как раз mon$ attachments работает как часы, в т.ч. и на этой таблице: срубает заработавшиеся коннекты только так. А вот mon$ statements срубает работающие стейтменты не всегда, а только при mon$state = 1 (см. первый пост)
...
Рейтинг: 0 / 0
11.11.2012, 01:07:32
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033402
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
dimitrМне уже надоедает повторять одно и то же.А меня это как достало :'(
...
Рейтинг: 0 / 0
11.11.2012, 01:07:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033403
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидИнтересует другое: зачем при каждом прераре, невзирая на характер sql-запроса , перечитываются все 30 тыс PP той таблицы, которая в нём упомянута ?Спроси того, кто писал оптимизатор.
В 3-ке это планируется переделать.
...
Рейтинг: 0 / 0
11.11.2012, 01:08:53
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033413
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladРаздели 201 на 30000 и сравни с avg seek time своего диска. Вряд ли оно меньше или даже сравнимо с 7 мс...Еще бы понять, чем мерять это avg seek time... :-/
lshw показывает, что у нас в этом серваке установлен IBM ServeRAID M5015. Кто-нить в курсе, какие у него ТТХ ?

ЗЫ. А встроенная мерялка скорости чтения с диска показывает какую-то очень уж оптимистичную картину:
Код: plaintext
1.
2.
3.
[root@reservdb tmp]# hdparm -t /dev/sda5

/dev/sda5:
 Timing buffered disk reads:  514 MB in  3.11 seconds = 165.02 MB/sec
...
Рейтинг: 0 / 0
11.11.2012, 01:30:04
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033420
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидPEAKTOPMON$ATTACHMENTS становиться немного не в курсе последних событий.Не, погодь! У мну как раз mon$ attachments работает как часы, в т.ч. и на этой таблице: срубает заработавшиеся коннекты только так. А вот mon$ statements срубает работающие стейтменты не всегда, а только при mon$state = 1 (см. первый пост)Наврал я тут, есть один случай - как раз сейчас его вижу: mon$attachments *НЕ* реагирует на просьбы грохнуть все коннекты, если коннекты эти были оборваны на стороне клиента. Например, если все isql-окна и соотв-щие cmd.exe были грохнуты утилитой pskill.exe.
Тогда при подключении к базе непосредственно после этого будем видеть:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
bash-3.2$ isql idx_under_load_test.fdb
Database:  idx_under_load_test.fdb
SQL> select count(*) from mon$attachments;

       COUNT
============
         236

SQL> commit; delete  from mon$attachments where mon$attachment_id<>current_connection; commit;
SQL> select count(*) from mon$attachments;

       COUNT
============
         236

SQL> commit; delete  from mon$attachments where mon$attachment_id<>current_connection; commit;
SQL> select count(*) from mon$attachments;

       COUNT
============
         236

Я так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments . Пока набирал этот текст, число коннектов стало меньше на 26, но на команду удаления они (оставшиеся) всё равно не реагируют:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SQL>  commit; delete from mon$attachments where mon$attachment_id<>current_connection; commit;
SQL>  commit; select count(*) from mon$attachments; commit;                                   
       COUNT
============
         210

SQL>  commit; delete from mon$attachments where mon$attachment_id<>current_connection; commit;
SQL>  commit; select count(*) from mon$attachments; commit;                                   
       COUNT
============
         210
...
Рейтинг: 0 / 0
11.11.2012, 01:40:44
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033475
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидЯ так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments .
естественно. Во-первых, откат изменений прерывать не всегда можно, это чревато. Во-вторых, удаление аттача - это для начала тот же самый откат изменений, так что ты в принципе не можешь увидеть никакого эффекта.
...
Рейтинг: 0 / 0
11.11.2012, 10:44:27
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033477
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
hvladВ 3-ке это планируется переделать.
именно это (зависимость от характера запроса) у меня нет никакого желания менять. А вот избежать полного скана PP можно будет, наверное.
...
Рейтинг: 0 / 0
11.11.2012, 10:47:16
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033478
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
PEAKTOPЯ к чему это все: основная задумка использования MON$ATTACHMENTS была в том, чтобы правоверно и строго по Корану срубить коннект, который че-то не так делает (ну, там запросы кривые, или просто базу вешает). А если оно так сильно от дисков зависит, то смысл в нем ?
я не вижу никаких доказательств, что где-то что-то критично (а не просто сильно) зависит от дисков. Случай "разбитого" рейда не учитываем, это форс-мажор.
...
Рейтинг: 0 / 0
11.11.2012, 10:49:08
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033488
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrоткат изменений прерывать не всегда можно, это чревато.А если FW=ON - тоже чревато ?
...
Рейтинг: 0 / 0
11.11.2012, 11:09:09
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033491
Фотография arni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
arni
Участник
dimitrНо отмечу, что эти 30 тыс равномерно размазаны по 118ГБ.Правильно ли я понимаю, что после b/r фрагментация PP едва ли уменьшится, т.к. очередная PP рождается на каждые n DP в момент заливки, а не вся пачка сразу на таблицу?
...
Рейтинг: 0 / 0
11.11.2012, 11:10:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033495
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
arni,

правильно, ибо размера таблицы никто не знает. Можно попробовать выделять некоторыми фиксированными пачками, мы это обсуждали. Но именно проблема препаре решается и другими способами.
...
Рейтинг: 0 / 0
11.11.2012, 11:18:02
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033497
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидА если FW=ON - тоже чревато ?
могу тебе в стопицотый раз сказать, что никто не будет менять поведение сервера относительно настройки FW
...
Рейтинг: 0 / 0
11.11.2012, 11:20:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033512
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
dimitrhvladВ 3-ке это планируется переделать.
именно это (зависимость от характера запроса) у меня нет никакого желания менять. А вот избежать полного скана PP можно будет, наверноеЯ именно это имел в виду, просто в неудачном месте ответил.
...
Рейтинг: 0 / 0
11.11.2012, 11:58:58
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033513
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrА вот избежать полного скана PP можно будет, наверноеА это в 2.5.x можно как-то вкрячить ? или только трёшку ждать ?
Я к тому, что таблицы в 1 млрд записей сейчас может и редки, но вот 10-20 таблиц по 50-100 млн строк запросто могут быть в системах, которые работают 5 лет и больше. И запрос, в котором упомянуты 3-4 такие таблицы, будет при каждом prepare будет сканировать эти самые PP.
...
Рейтинг: 0 / 0
11.11.2012, 12:06:47
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033539
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

1) 100 млн строк - это 3000 маленьких страниц или 1500 средних или 750 больших, т.е. время их чтения будет 20 сек в худшем случае и 5 сек в лучшем
2) большинство из них будет кешировано сервером или осью после первого обращения

в общем, как обычно, ты преувеличиваешь серьезность проблемы. Ну и единственное возможное в 2.5 решение тоже имеет свои недостатки.
...
Рейтинг: 0 / 0
11.11.2012, 12:45:52
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033547
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
dimitrбольшинство из них будет кешировано сервером или осью после первого обращения
Насколько я понимаю это верно для систем с постоянным коннектом. Если же коннект постоянно уничтожается и создаётся заново, то для классика кэш придётся заполнять заново. В частности это будет происходить при использовании PHP. Пока что единственный способ этого избежать использовать пул коннектов.
...
Рейтинг: 0 / 0
11.11.2012, 13:04:19
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033553
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов ДенисЕсли же коннект постоянно уничтожается и создаётся заново
на каждый запрос? Если да, то оно встанет раком в любом случае. Если нет, то кеш сыграет свою роль. Ну и кроме того, кеш оси будет помогать (если база многопользовательская).
...
Рейтинг: 0 / 0
11.11.2012, 13:15:52
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033557
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Не на каждый запрос конечно. В случае веб страницы на каждую страницу. Впрочем как я уже сказал там можно применить пул коннектов, ну или использовать суперсервер.
...
Рейтинг: 0 / 0
11.11.2012, 13:18:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033641
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Маленькая ремарка, исключительно по железке.
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ?30000/200 = 150 (операций ввода-вывода с диска, то бишь в простонародье "иопсов"). 150 иоспов типичная (даже немного оптимистичная) цифирь для одиночного САТА диска. Лично я не вижу ровно никакого противоречия, если база не "разогрета".

ТаблоидЗЫ. А встроенная мерялка скорости чтения с диска показывает какую-то очень уж оптимистичную картину:
Код: plaintext
1.
2.
3.
[root@reservdb tmp]# hdparm -t /dev/sda5

/dev/sda5:
 Timing buffered disk reads:  514 MB in  3.11 seconds = 165.02 MB/sec
Не меряй потоковое чтение, оно тебе интересно мало, меряй иопсы, можно иометером.

Таблоидlshw показывает, что у нас в этом серваке установлен IBM ServeRAID M5015. Кто-нить в курсе, какие у него ТТХ ?Судя по редбуку ТТХ не самые тухлые, но больше сказать не могу, в руках не держал. Диски какие и сколько? Батарейка е? тип массива?

Примени иометер, чтоб оценить что можно от железки ждать. размер задаешь примерно по размеру базы, кол-во воркеров по кол-ву коннектов к базе, размер блока по размеру странички БД и смотришь полученные чиселки.
...
Рейтинг: 0 / 0
11.11.2012, 16:06:08
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033644
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Таблоид
Код: plaintext
Timing buffered disk reads:  514 MB in  3.11 seconds = 165.02 MB/sec
Да, кстати, 100 мегабайт в секунду я буквально несколько дней назад заливал себе тестовую базу+ образ виртуалки где-то 25+25 гиг на УСБ3 диск с обычного САТА. Это просто мой рабочий десктоп, и нет там никаких рэйдов.

В общем терзают меня смутные сумненья на предмет крутости дисковой ПС твоего сервера.
...
Рейтинг: 0 / 0
11.11.2012, 16:09:43
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033646
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Ivan_PisarevskyДиски какие и сколько? Батарейка е? тип массива?lshw в аттаче
...
Рейтинг: 0 / 0
11.11.2012, 16:10:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033652
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Таблоидlshw в аттаче Маниак, блин. Нет там инфы о дисках. это надо смотреть в утиле управления контроллером, ОСь в принципе не знает о кол-ве дисков за аппартным контроллером рэйд.

Судя по наличии файберного хба есть намек на то, что дисков всего пара, чтоб бутить сервер, а остальное должно браться с файберного сундука с дисками.
...
Рейтинг: 0 / 0
11.11.2012, 16:23:50
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033688
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Ivan_Pisarevskyэто надо смотреть в утиле управления контроллером, ОСь в принципе не знает о кол-ве дисков за аппартным контроллером рэйд.ладно, завтра спрошу у наших железячников (хотя с ними всегда трудно вести диалог, ибо невменяемые они у нас).
...
Рейтинг: 0 / 0
11.11.2012, 17:04:35
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033693
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Таблоидв этом серваке установлен IBM ServeRAID M5015. Кто-нить в курсе, какие у него ТТХ ? Красные книжки .
...
Рейтинг: 0 / 0
11.11.2012, 17:20:09
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033695
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Таблоид,

По первый эксперимент: одна запись по ключу должна подписаться мигом.
Может тормозит оптимизатор?
Не пробовал форсануть этот один нещастный индекс?
...
Рейтинг: 0 / 0
11.11.2012, 17:20:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033700
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
MasterZivПо первый эксперимент: одна запись по ключу должна подписаться мигом.
Может тормозит оптимизатор?
что значит "подписаться"? ты читал первый же ответ 13451906 ?
...
Рейтинг: 0 / 0
11.11.2012, 17:36:55
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033733
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
MasterZivодна запись по ключу должна подписаться мигом.Она и так мигом выхватывается, на собственно поиск в индексе уходит 6 фетчей. Выше уже выяснилось, что все беды от того, что при КАЖДОМ запросе, в котором упоминается большая таблица, ФБ будет искать ВСЕ её PP, коих в данном случае набралось почти 30 тыс и они, к тому же, размазаны по файлу, т.е. последовательной вычиткой тут не получится.
MasterZivНе пробовал форсануть этот один нещастный индекс?Что значит "форсануть" ?
...
Рейтинг: 0 / 0
11.11.2012, 18:35:08
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38038988
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Продолжу стартовый пост.

ЭКСПЕРИМЕНТ 4.

Дано:
1) локальная машина, время которой отстаёт от серверного на 0.343 сек
2) запущенный трейс, отслеживающий активность на этой базе.
3) база не "разогрета", т.е. её "фрагменты" в кеше операционки отсутствуют.

Запускаю на локальной машине батник:
Код: plaintext
1.
2.
echo %time%
isql 192.168.0.59:t1 -i 1.sql
где содержимое скрипта `1.sql` есть:
Код: plaintext
select current_timestamp from rdb$database; commit;

Получаю при первом запуске этого скрипта:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
C:\MIX\firebird\fb25>echo 23:39:03,39
 23:39:03,39  -- время на рабочей станции

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

        CURRENT_TIMESTAMP
=========================
2012-11-14 23:39:07.3000
Трейс при первом запуске:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
Trace session ID 1 started
2012-11-14T 23:39:07.2600  (3769:0x2aaaab258af8) TRACE_INIT
        SESSION_1


2012-11-14T23:39:07.2600 (3769:0x2aaaab258af8) ATTACH_DATABASE
        t1 (ATT_80, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:312

Получаю при втором (вспомогательном) запуске этого скрипта:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo 23:39:52,72
23:39:52,72

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

        CURRENT_TIMESTAMP
=========================
2012-11-14 23:39:53.0630

Второй (вспомогательный) запуск - только для определения разности показаний часов раб. станции и сервера. Вывод времени сервера в isql в этом запуске был практически мгновенным. Это значит, что время установки коннекта было почти 0 и для определения разности показаний часов можно просто сравнить два значения: 23:39:52.72 и 23:39:53.06.
Отставание часов рабочей станции получается примерно 0.34 сек.

Теперь смотрим на время, которое было на рабочей станции при входе в батник в первом запуске: 23:39:03,39 - и на время, которое показал трейс в момент установки коннекта: 23:39:07.26
Если прибавить к 23:39:03,39 дельту 0.34", получим 23:39:03.73 - это время по часам сервера, которое было в момент первого запуска батника.
Тогда время установки коннекта к этой базе составило:
Код: plaintext
datediff(millisecond from  23:39:03.73  to  23:39:07.2600 ) = ~3500 мс

Я не очень понимаю, что может делать ФБ в течение 3.5 сек при попытке установить коннект.
Проверка пароля делается с использованием security2.fdb - это всё очень быстро, да и sec2.fdb на этом серваке всё время закеширована, там тесты идут.
Даже если база `t1` не была в кеше, открытие файла на бездействующем серваке - операция также мгновенная. Метаданные при коннекте от isql вроде бы НЕ вычитываются.

Что тогда занимает время ?

PS. Вижу этот эффект регулярно - каждый раз после того, как память основательно будет "потрясена" другими тестами и от базы `t1` в кеше ничего не останется.
...
Рейтинг: 0 / 0
15.11.2012, 00:11:39
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039007
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидкаждый раз после того, как память основательно будет "потрясена" другими
тестами и от базы `t1` в кеше ничего не останется.
Зато в нём куча прочего дерьма, которое надо куда-то сбросить, прежде чем туда сможет
влезть хоть что-то от этой твоей базы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
15.11.2012, 00:43:19
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039128
Фотография arni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
arni
Участник
Таблоид,

хотя тут не нужно вычитывать огромный объем PP на prepare, но всё же, что если сделать доп.пример и вовсе исключить обращение к таблицам в запросе времени. Например вместо
Код: sql
1.
select current_timestamp from rdb$database

примерно так дернуть
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
execute block
returns(
TS timestamp)
as
begin
  TS = current_timestamp;
  suspend;
end

?
...
Рейтинг: 0 / 0
15.11.2012, 08:19:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039164
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидЯ не очень понимаю, что может делать ФБ в течение 3.5 сек при попытке установить коннект.
Проверка пароля делается с использованием security2.fdb - это всё очень быстро, да и sec2.fdb на этом серваке всё время закеширована, там тесты идут .
Даже если база `t1` не была в кеше, открытие файла на бездействующем серваке - операция также мгновенная. Метаданные при коннекте от isql вроде бы НЕ вычитываются.
ты бы определился, что-ли
...
Рейтинг: 0 / 0
15.11.2012, 09:12:13
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039196
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
arniпримерно так дернутья попробовал это, только предварительно вырубил использование кеша FS: поставил FileSystemCacheThreshold = 0 и рестартовал ФБ.
Результат 10 запусков:
 
Код: 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.
C:\MIX\firebird\fb25>type i.sql
set term ^;
execute block returns(TS timestamp) as
begin
  TS = current_timestamp;
  suspend;
end
^set term ;^

C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:08:55,32
 9:08:55,32

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:08:59.0830


C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:14:24,07
 9:14:24,07

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:14:26.2050

C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:15:15,78
 9:15:15,78

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:15:17.8790


C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:15:29,16
 9:15:29,16

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:15:30.7290


C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:19:36,61
 9:19:36,61

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:19:38.7290


C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:19:41,47
 9:19:41,47

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:19:43.0440


C:\MIX\firebird\fb25>i.bat

C:\MIX\firebird\fb25>echo  9:19:46,24
 9:19:46,24

C:\MIX\firebird\fb25>isql 192.168.0.59:t1 -n -i i.sql

                       TS
=========================
2012-11-15 09:19:47.8140
Те же результаты, но в виде таблицы:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
                       T1                        T2              DATEDIFF
========================= ========================= =====================
2012-11-15 09:08:55.3200  2012-11-15 09:08:59.0830                    3763
 2012-11-15 09:14:24.0700  2012-11-15 09:14:26.2050                   2135
2012-11-15 09:15:15.7800  2012-11-15 09:15:17.8790                   2099
2012-11-15 09:15:29.1600  2012-11-15 09:15:30.7290                   1569
2012-11-15 09:19:36.6100  2012-11-15 09:19:38.7290                   2119
2012-11-15 09:19:41.4700  2012-11-15 09:19:43.0440                   1574
2012-11-15 09:19:46.2400  2012-11-15 09:19:47.8140                   1574
2012-11-15 09:22:44.8300  2012-11-15 09:22:47.0050                   2175
2012-11-15 09:22:49.8200  2012-11-15 09:22:51.4100                   1590
2012-11-15 09:22:59.0000  2012-11-15 09:23:00.6020                   1602

PS. я затем еще раз перегрузил ФБ и заметил: первый с момента рестарта коннект идёт дольше остальных (примерно на 1-2 секунды). Чем это объяснить при FileSystemCacheThreshold = 0 - не знаю.
...
Рейтинг: 0 / 0
15.11.2012, 09:40:48
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039200
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrты бы определился, что-ли"там тесты идут" - это значит, что ИМЕЮТ ОБЫКНОВЕНИЕ быть запущенными
То есть, я стартовал там утром / днём известный тебе idx_under_load_test, по нескольку раз, а затем остановил.
...
Рейтинг: 0 / 0
15.11.2012, 09:42:58
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38039955
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидЯ так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments .
естественно. Во-первых, о ткат изменений прерывать не всегда можно , это чреватоЧто-то сильно затормозил я тогда с встречным вопросом.
Если откат изменений иногда "чреват", то как же тогда быть с gfix -shut full -force 0 ? Ведь этой команде чихать на откаты изменений, она просто останавливает базу, не дожидаясь завершения откатов.
Да, я знаю, что валидация затем покажет тучу нестрашных orphan pages, а для индексов - такую же тучу нестрашных "Index N is corrupt on page X level Y at offset Z...., validation.cpp, line: 2050 или 2060" (насчет нестрашности последних - см тут ).
По такой логике, после каждого шатдауна базы на работавших коннектах требуется b/r делать (ввиду "чреватости" незавершенных откатов) ?
...
Рейтинг: 0 / 0
15.11.2012, 15:38:55
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040255
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид Ведь этой команде чихать на откаты изменений, она просто останавливает базу, не дожидаясь завершения откатов.
Да, я знаю, что валидация затем покажет тучу нестрашных orphan pages,
шо-шо??? shut force отрубает коннекты, и им делается rollback. никаких orphan pages при этом быть не может. orphan pages образуются тольки при срубании коннекта, который пилил базу.
...
Рейтинг: 0 / 0
15.11.2012, 18:00:15
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040290
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

при шатдауне все откаты штатные и полноценные, не надо наводить панику на пустом месте
...
Рейтинг: 0 / 0
15.11.2012, 18:13:56
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040502
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
kdvпри срубании коннекта, который пилил базу.
мнэ, при срубании сервака (или процесса классика).
...
Рейтинг: 0 / 0
15.11.2012, 21:09:12
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040894
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrпри шатдауне все откаты штатные и полноценные, не надо наводить панику на пустом местеПри gfix -shut full -force 0 -- да, отрубает ОК и делает откаты (вижу в трейсе).
А теперь попробуем останавливать базу и службу ФБ (у мну её имя = "fb25_3050") вот так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
@rem file = "shut_all.bat"
@echo off
gfix -shut full -force  5  t1.fdb
ping 127.0.0.1 > nul
gstat -h t1.fdb > tmp_gstat.tmp

find /i /c "full shutdown" tmp_gstat.tmp > nul
if %errorlevel% GTR 0 (
  echo database is NOT in shutdown mode!
  exit
) 
gstat -h t1.fdb|findstr /i /c:"attributes"
net stop "Firebird Server - fb25_3050"
del tmp_gstat.tmp
pause

Тест:
окно #1
// Запускаем трейс

окно #2
// в нём будет введён батник, показанный выше

окно #3
// создаём новую базу, делаем к ней коннект via TCP и напихиваем 2 млн строк:
 
Код: 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.
C:\1INSTALL\FIREBIRD\Data>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 't1.fdb'; commit;
SQL> quit;

C:\1INSTALL\FIREBIRD\Data>isql localhost/3050:C:\1INSTALL\FIREBIRD\Data\t1.fdb -n
Database:  localhost/3050:C:\1INSTALL\FIREBIRD\Data\t1.fdb
set term ^;
execute block as
begin
execute statement 'drop sequence g;'; when any do begin end
end^
set term ;^
commit;

create sequence g;
recreate table t(id int, s varchar(36));
commit;

set stat on;
set term ^;
execute block as 
declare n int = 2000000;
begin
  while (n>0) do insert into t(id,s) values( gen_id(g,1), uuid_to_char(gen_uuid()) ) returning :n-1 into n;
end
^set term ;^
commit;


окно #2
Код: plaintext
1.
2.
3.
4.
5.
6.
C:\1INSTALL\FIREBIRD\Data>shut_all.bat -- ждём 5 секунд
connection lost to database -- это сам gfix вякнул, при детаче от базы
        Attributes              force write, full shutdown -- это мы проверили наличие ключевых слов `full shutdown`
Служба "Firebird Server - fb25_3050" останавливается.... -- в этот момент завершился трейс
Не удалось остановить службу "Firebird Server - fb25_3050". -- обычное сообщение, когда ФБ делает массовые откаты

Для продолжения нажмите любую клавишу . . .

окно #1
Трейс в "хвосте" своего лога будет иметь текст без каких-либо упоминаний о ROLLBACK'e:
 
Код: 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.
2012-11-16T08:43:17.9680 (1416:0233DEB0) EXECUTE_STATEMENT_START

	C:\1INSTALL\FIREBIRD\DATA\T1.FDB (ATT_2, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)

	C:\1INSTALL\FIREBIRD\FB25HEAD\bin\isql.exe:848

		(TRA_6, CONCURRENCY | WAIT | READ_WRITE)


Statement 89:

-------------------------------------------------------------------------------

execute block as 
declare n int = 2000000;
begin
  while (n>0) do insert into t(id,s) values( gen_id(g,1), uuid_to_char(gen_uuid()) ) returning :n-1 into n;
end


2012-11-16T08:43:37.0620 (1416:0233C928) TRACE_INIT

	SESSION_1  



2012-11-16T08:43:37.0620 (1416:0233C928) FAILED ATTACH_DATABASE

	t1.fdb (ATT_0, SYSDBA, NONE, XNET:BALAHA)

	C:\1INSTALL\FIREBIRD\FB25HEAD\bin\gfix.exe:1052


2012-11-16T08:43:37.0620 (1416:0233C928) ERROR AT jrd8_attach_database

	t1.fdb (ATT_0, SYSDBA, NONE, XNET:BALAHA)

	C:\1INSTALL\FIREBIRD\FB25HEAD\bin\gfix.exe:1052

335544528 : database t1.fdb shutdown


2012-11-16T08:43:37.0620 (1416:0233C928) TRACE_FINI

	SESSION_1


окно #3
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Statement failed, SQLSTATE = HY008
operation was cancelled
After line 14 in file filtab
Current memory = 0
Delta memory = -4920748
Max memory = 0
Elapsed time= 32.63 sec
Buffers = 0
-- (забавные цифирки, ну да ладно, сейчас не о них)
Reads = -111
Writes -33
Fetches = -1587
Statement failed, SQLSTATE = 08003
connection shutdown
After line 20 in file filtab

окно #1
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
C:\1INSTALL\FIREBIRD\Data>gfix -online t1.fdb

C:\1INSTALL\FIREBIRD\Data>gfix -v -full T1.FDB
Summary of validation errors
        Number of database page errors  : 9657

C:\1INSTALL\FIREBIRD\FB25HEAD>find /i /c "an orphan" firebird.log -- подсчитаем число строк в логе, содержащих "an orphan"

---------- FIREBIRD.LOG:  9657

В аттаче - firebird.log после проведения валидации.
...
Рейтинг: 0 / 0
16.11.2012, 09:05:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040898
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. И это еще не всё. Оказывается, если ФБ-службу не останавливать, а всего лишь зашатдаунить базу:
Код: plaintext
gfix -shut full -force N t1.fdb
где N>0 , то:
1) база получит атрибут `full shutdown` (gstat -h выведет его);
2) коннект, который в это время что-то там писал в эту базу, ... будет спокойно продолжать туда дописывать! И более того, если он не выполнит детач, то и дальше сможет трудиться "на благо родины": делать commit'ы, запускать новые DML / DDL...
...
Рейтинг: 0 / 0
16.11.2012, 09:10:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040907
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

а мужики-то и не знали...
...
Рейтинг: 0 / 0
16.11.2012, 09:20:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040942
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr а мужики-то и не знали... я видел этот тикет, однако ночером уже не было сил его искать :/
ну, а что про orphan'ы, когда служба ФБ останавливается после лже-шатдауна, недовыполнив откаты, - это бага или нет ?
...
Рейтинг: 0 / 0
16.11.2012, 09:49:22
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38040965
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

когда останавливается служба, ядру дается 10 сек на "чистый" откат. Если он не успел, то селяви - тогда будут орфаны.
...
Рейтинг: 0 / 0
16.11.2012, 10:08:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38042850
cwev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cwev
Гость
авторМожет быть натурал и не заложен, но порядок соединения и используемые индексы однозначно оценивает через умножение кардинальности на селективность.

Ага, надо только правильно запрос, то бишь... как его... вопрос, во, вопрос сформулировать, что бы при оценке оптимизатора кардинально поменялся индекс were-предиктора, иначе заточка будет другая и лаги только возрастут. При этом на селективность можно не обращать внимания, она всегда нулевая. Ок, да?
...
Рейтинг: 0 / 0
17.11.2012, 23:20:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346519
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
up.

Проверяю подключение клиента WI-2.5 к серверу LI-3.0, на котором пересоздана эта таблица (1 млрд строк).
Машина сервера после этого была перезагружена (shutdown -r now).

Таблица была создана под sysdba, в embedded-подключении (дабы быстрее) при этом не привилегированному юзеру с именем `u25` никаких прав на неё выдано не было - забыл про это.
Затем подключился к базе по tcp, с виндовой машины, под юзером `u25`. Само подключение (появление подсказки в isql) выполнилось практически мгновенно, т.е. как и в обычных случаях.

Далее ввёл запрос:
Код: plaintext
1.
SQL> set stat on;
SQL> select * from t where id = 789456123;

Сразу после этого в логе трейса появилось:
Код: plaintext
1.
2013-07-28T01: 02:37 .9650 (2211:0x7ff34c096148) TRACE_INIT
        SESSION_1
- но ТОЛЬКО это сообщение там и оставалось видимым в течение следующих 3 минут .


И только через 3 минуты в трейсе вылезло:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
2013-07-28T01: 05:34 .2520 (2211:0x7ff34c096148) UNAUTHORIZED PREPARE_STATEMENT
        test01 (ATT_43, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1896
                (TRA_46, CONCURRENCY | WAIT | READ_WRITE)

-------------------------------------------------------------------------------
select * from t where id = 789456123
 176287 ms

2013-07-28T01:05:34.2520 (2211:0x7ff34c096148) ERROR AT JStatement::prepare
        test01 (ATT_43, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1896
335544352 : no permission for SELECT access to TABLE T

А isql выплюнул соотв-щий облом:
Код: plaintext
1.
Statement failed, SQLSTATE = 28000
no permission for SELECT access to TABLE T

Как говорилось выше в этом топике, на "холодной базе" первый запрос (даже по индексу PK) будет выполняться долго из-за вычитки PP.
Но ведь ДО начала этой вычитки FB проверяет мои права на запрашиваемый объект - не так ли ?
А права эти живут в крохотных RDB$-таблицах. Проверка этих RDB$таблиц должна выполняться мгновенно.

Тогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
...
Рейтинг: 0 / 0
28.07.2013, 01:24:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346524
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоид ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;



Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.особенность текущей реализации, к сожалению. Удалить (сиречь: остановить) можно только активный риквест. А в твоем случае он всегда опознается как неактивный (stalled), мы это уже обсуждали недавно. Я подумаю, что тут можно сделать .Кое-что действительно сделано. Но хотелось бы решить вопрос со скоростью реакции на delete from mon$statements "радикально и навсегда".

Повторил этот эксперимент на "разогретой" базе.

Запустил сначала isql в первом окне и ввёл там:
Код: plaintext
1.
2.
C:\MIX\firebird\fb25>isql.exe 192.168.99.44:test01 -user sysdba -pas masterke -n
Database:  192.168.99.44:test01, User: sysdba
SQL> select * from t where id between 123456789 and 789456123;

ФБ занялся сканированием индекса в поисках записи с id >= 123456789. Он делает это настолько медленно, что никакого вывода строк на экран не происходит даже в течение 10-15 секунд.
Поэтому во втором cmd-окне можно неспешно:
1) запустить isql
2) ввести там:
Код: plaintext
SQL> commit; delete from mon$statements where mon$attachment_id<>current_connection; commit;

Повторил эти действия 4 раза.
Результат: окно-1 реагирует на delete from mon$statements (от окна-2) не сразу, а только через 20-30 секунд, а в последний раз - почти 4 минуты(!)
 
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.
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.
2013-07-28T 01:39:32 .3280 (2296:0x7f6f2781e018) EXECUTE_STATEMENT_START
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-07-28T01:39:34.3480 (2296:0x7f6f2781d1f8) DETACH_DATABASE
        /opt/fb30cs/security3.fdb (ATT_495, SYSDBA:NONE, NONE, <internal>)

2013-07-28T01:39:34.3480 (2296:0x7f6f2781d1f8) TRACE_FINI
        SESSION_2


2013-07-28T 01:43:11 .4380 (2296:0x7f6f2781e018) EXECUTE_STATEMENT_FINISH
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)
0 records fetched
 219109 ms, 33 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$RELATIONS                                     8                                                           

2013-07-28T01:43:11.4380 (2296:0x7f6f2781b148) FAILED EXECUTE_STATEMENT_FINISH
        test01 (ATT_66, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1588
                (TRA_73, CONCURRENCY | WAIT | READ_WRITE)

Statement 22:
-------------------------------------------------------------------------------
select * from t where id between 123456789 and 789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (RDB$PRIMARY1))
0 records fetched
 233700 ms, 406624 read(s)

2013-07-28T01:43:11.4380 (2296:0x7f6f2781b148) ERROR AT JStatement::openCursor
        test01 (ATT_66, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1588
335544794 : operation was cancelled

2013-07-28T01:43:11.4390 (2296:0x7f6f2781e018) FREE_STATEMENT
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-07-28T01:43:11.4400 (2296:0x7f6f2781e018) COMMIT_TRANSACTION
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 1 read(s), 1 write(s), 1 mark(s)

Кажется, это как-то связано с тем, сколько времени прошло от момента старта select'a в окне-1 до момента ввода delete from mon$statements в окне-2. Есть подозрение, что чем дольше давать поискать окну-1 первую запись, тем дольше у него будет "отходняк" при получении команды обруба.

В общем, таблица-миллиардник и на ФБ-3 продолжает оставаться "серьёзным игроком" :-)
...
Рейтинг: 0 / 0
28.07.2013, 01:48:56
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346538
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Да, и еще.

Среди 1 млрд строк есть 12, у которых в поле `h`, заполнявшемся как hash(s), записаны дубли.
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
Database:  test01.fdb
SQL> show table t;
ID                              INTEGER Not Null
S                               VARCHAR(36) Nullable
H                               BIGINT Nullable
CONSTRAINT INTEG_2:
  Primary key (ID)

SQL> set stat on; set explain on; select h,count(*) h_cnt from t group by h having count(*)>1;

Select Expression
    -> Filter
        -> Aggregate
            -> Sort
                -> Table "T" Full Scan

                    H                 H_CNT
===================== =====================
    23892282818693425                     2
    26121068392037974                     2
    39144859051103730                     2
    42731417555628722                     2
   116515253492760935                     2
   907260062758124950                     2
   916797897021246051                     2
   960976570354906997                     2
   969133800131399768                     2
   971045795196823170                     2
  1037847731177921477                     2
  1124736694581280582                     2

Current memory = 1428584
Delta memory = 364776
Max memory = 686304024
Elapsed time= 5695.44 sec
Cpu = 0.15 sec
Buffers = 8192
Reads = 24444277
Writes = 0
Fetches = 2024398059
SQL>
То есть, либо uuid_to_char(gen_uuid()) способен сгенерить 12 дублей на 1 млрд, либо хэши от этих 36-символьных строк могут совпадать ввиду коллизий (что странно на такой длине текста).
Точнее сказать пока не могу - надо вытряхнуть данные. Пытался создать индекс по `h` - умерло: top показывал, что процесс firebird вообще ни хрена не делает, а isql что-то там пытается грузить, но как-то вяло.
Сейчас просто натравлю запрос на извлечение по natural'у.
...
Рейтинг: 0 / 0
28.07.2013, 09:26:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346542
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидлибо uuid_to_char(gen_uuid()) способен сгенерить 12 дублей на 1 млрд, либо хэши от этих 36-символьных строк могут совпадать ввиду коллизий (что странно на такой длине текста).Второй вариант. Коллизии, и только они.
Вот список 12*2 uuid-строк, по которым hash выдает одинаковые значения:HS1037847731177921477EA00D44E-64C9-48C0-8438-FA04AA662E051037847731177921477F3EDA604-DD22-449D-A5F2-6DB4204082F5112473669458128058212DB8574-AADC-45FA-A24B-CC4911CDC00F112473669458128058250F6FD32-7FEB-4E2A-A61C-5519467248A6116515253492760935BC4BB00D-8EA6-437F-B7EC-EBF25DF7D4F7116515253492760935D4DDAEA1-8E0A-4B5E-9D6C-E3874B83EB272389228281869342534585795-70B6-40F3-8859-B15851B2540A23892282818693425511DAF0B-FC44-4AB9-A8B3-CC6165897A0A261210683920379748E4622FF-9264-4285-8934-5B525CF2F9062612106839203797499CC7926-045F-40F2-A464-0AEFF07B52CF39144859051103730143AD095-6FEF-44E9-87D7-A135D24BC9E23914485905110373064BE5888-AE20-4218-A3A6-F492ACFAD28B4273141755562872243BF4105-5234-4662-903E-2EE9429E56A242731417555628722E5F4CCC6-4CE3-4301-BABE-14C83A58C8DB90726006275812495038D18A5B-46E5-4C1D-8D36-3180A280E75690726006275812495070979264-2CC6-4BBE-8D0F-A7213B07CA5691679789702124605138285431-2C6F-468B-B7CA-4A83F8666E1391679789702124605194BF2544-F47A-4209-B410-326597F1E5639609765703549069971D24B10E-EBE3-44EB-AA78-4A57167CD645960976570354906997736DA53E-4335-40E6-B879-D23218825FA5969133800131399768D4D0DAAF-0074-42F8-9487-08573F84EBD8969133800131399768FE7BF9D2-0755-425D-8554-234B26BDCBB8971045795196823170B115F1BB-6176-47AA-A7CE-60322918C472971045795196823170E7254E81-3D9B-48C2-9A65-AA27475B303BСтранно как-то это, на длине в 36 знаков.
...
Рейтинг: 0 / 0
28.07.2013, 10:08:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346780
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидТогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
насколько я помню - запрос сначала полностью препарится, потом проверяются права. А препарирование включает в себя скан всех PP.
...
Рейтинг: 0 / 0
28.07.2013, 21:13:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346781
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
dimitrА препарирование включает в себя скан всех PP.
(я и то помню это по тесту терабайтной БД).
а вроде предполагались какие-то улучшения в этом плане? Я именно про скорость prepare.
...
Рейтинг: 0 / 0
28.07.2013, 21:16:05
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346788
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
kdv,

предполагались, но пока есть по ним некоторые сомнения
...
Рейтинг: 0 / 0
28.07.2013, 21:22:50
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346807
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидТогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
насколько я помню - запрос сначала полностью препарится, потом проверяются права. А препарирование включает в себя скан всех PP.Погоди-ка... вот есть запрос: select ляляля from тратата1 join тратата2 on ...
Разве нельзя на стадии prepare сразу же вытряхнуть имена объектов (тратата1, тратата2), к которым хотят лезть, и тут же, до всяких там PP-вычиток, проверить права на них ?
...
Рейтинг: 0 / 0
28.07.2013, 21:45:26
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346826
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

это все делается на стадии препаре, просто в разные фазы. Простого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому.
...
Рейтинг: 0 / 0
28.07.2013, 21:55:51
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346833
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrэто все делается на стадии препаре, просто в разные фазы. Простого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому.А просвяти, плз: если запрос содержит обращения к 10 объектам БД, то что будет происходить при prepare:
1) парсер будет сначала вытряхивать одно имя за другим, НЕ проверяя права на них, до тех пор, пока не "распознает" 10-е имя; и только после получения 10-го имени начнётся проверка прав
либо
2) парсер вытряхнет имя_1, затем тут же будут проверены права на него; дальше, если права есть, парсер вытащит имя_2 итут же будут проверены права на имя_2, и т.п.
- ?
...
Рейтинг: 0 / 0
28.07.2013, 21:59:54
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346837
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

составляется весь список и потом проверяется оптом
...
Рейтинг: 0 / 0
28.07.2013, 22:01:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346845
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrсоставляется весь список и потом проверяется оптомОК, с этим понятно.
Но вернусь к первому вопросу: вот когда в запросе есть только 1 объект - почему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
...
Рейтинг: 0 / 0
28.07.2013, 22:06:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346848
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоидпочему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
склероз у тебя, хотя dataaccesspaths ты вроде неоднократно читал. по PP сервер вычисляет кардинальность таблицы, т.е. сколько там может быть записей (теоретически).
...
Рейтинг: 0 / 0
28.07.2013, 22:09:07
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346851
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТаблоидпочему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
склероз у тебя, хотя dataaccesspaths ты вроде неоднократно читал. по PP сервер вычисляет кардинальность таблицы, т.е. сколько там может быть записей (теоретически).не-е, это я помню!
У мну вопрос простой: зачем он начинает считать "скока вешать граммов" до того, как поймёт, имеет ли он право вообще трогать сей товар! Почему нельзя сначала в rdb$-таблицы полезть и проверить, есть ли права на соотв-щую таблицу у того, кто её "хочет" ?
...
Рейтинг: 0 / 0
28.07.2013, 22:13:22
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346855
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидУ мну вопрос простой: зачем он начинает считать "скока вешать граммов" до того, как поймёт, имеет ли он право вообще трогать сей товар! Почему нельзя сначала в rdb$-таблицы полезть и проверить, есть ли права на соотв-щую таблицу у того, кто её "хочет" ?
нет, ты перескакиваешь с вопроса на вопрос. Prepare строит план и проверяет права.
Зачем Prepare считывает PP? Чтобы узнать кардинальность таблиц и построить план запроса.
Можно отделить в Prepare построение плана от проверки прав? Ответ тут 14629558
Увы.
...
Рейтинг: 0 / 0
28.07.2013, 22:15:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346859
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvМожно отделить в Prepare построение плана от проверки прав?

Да фиг с ним, отделением. Таблоид-то спрашивает про очерёдность. Права проверяются на все
объекты, задействованные во всех возможных ветках всех возможных планов. Если права на
операцию нет, то проверка на это, произведённая чуть раньше (при добавлении объекта в
список и граф) и выкинувшая исключение, сэкономит кучу времени.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.07.2013, 22:20:29
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346861
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvPrepare строит план и проверяет права.Если сначала строится план, и только после проверяются права, то выглядит это как-то... странно! Будешь ли ты оценивать время движения по платной дороге, не выяснив, есть ли у тебя хотя достаточно бабла в кармане для оплаты ?
kdvЗачем Prepare считывает PP? Чтобы узнать кардинальность таблиц и построить план запроса.Да понимаю я это, разумеется.
kdvМожно отделить в Prepare построение плана от проверки прав? Ответ тут 14629558
Увы.к сож-ю, ответ ДЕ не прояснил мне моцк:dimitrПростого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому. Ну, подняли граф зависимостей, там 10 объектов.
Что мешает сначала выяснить права на них, немедленно выдавая отказ в работе при отсутствии хотя бы одного из прав, а затем вычитывать PP ??
...
Рейтинг: 0 / 0
28.07.2013, 22:27:26
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346902
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Тут еще один таракан на тему скорости вылез.
Пересоздал базу с нуля, поставил в ней FW = OFF, добавил кеш до 16384.
Создал таблицу t(id int, s char(36));
Добавил в эту таблицу свой любимый млрд строк, поле `s` генерил через uuid_to_char(), в поле id записывал gen_id(g, 1).
Добавил индекс: create index t_s on t(s); commit;

А теперь хочу всё таки еще раз выяснить: нет ли сдублированных значений в `s`.
И делаю запрос:
Код: sql
1.
2.
3.
SQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id;

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

Он молотил два часа и было нгепонятно, закончится это когда-нить или нет. Я срубил его и увидел по трейсу, что правильно сделал (см статистику!):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
2013-07-28T21:56:12.6930 (4467:0x7fe8418d35b8) EXECUTE_STATEMENT_START
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
                (TRA_52, CONCURRENCY | WAIT | READ_WRITE)

Statement 259:
-------------------------------------------------------------------------------
select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))

2013-07-28T23:51:49.8400 (4467:0x7fe8418d35b8) FAILED EXECUTE_STATEMENT_FINISH
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
                (TRA_52, CONCURRENCY | WAIT | READ_WRITE)

Statement 259:
-------------------------------------------------------------------------------
select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))
0 records fetched
 6937146 ms , 1264903 read(s), 5397222 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                   632066    632066                                                           

2013-07-28T23:51:49.8940 (4467:0x7fe8418d35b8) ERROR AT JStatement::fetch
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
335544794 : operation was cancelled

Товарищи! "Чё-то не того!" 632 тыс записей обмолочено за 6900 сек - это что же получается-то ?!
...
Рейтинг: 0 / 0
29.07.2013, 00:24:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346903
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. Добавил в условие join'a предыдущего запроса "дёргание" генератора, чтобы в другом окне хотя бы видеть скорость изменений:
Код: plaintext
1.
2.
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;

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

Результат: ужасный кошмар. За полчаса обмолочено менее 180 тыс строк:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-28 23:53:41.7730             1000004160


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

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-29 00:23:23.6460             1000182007

И типичная картина из top'a в это время (да, я понимаю, что 4 Гб памяти мало - но пока это всё, что есть; но с серваком работаю я один):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
top - 00:27:28 up 23:55,  2 users,  load average: 1.27, 1.38, 1.40
Tasks: 122 total,   1 running, 121 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.7%us,  1.5%sy,  0.0%ni, 88.6%id,  6.1%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  3.2%us,  1.6%sy,  0.0%ni, 88.7%id,  6.4%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  1.9%us,  0.8%sy,  0.0%ni, 92.8%id,  4.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.3%us,  0.7%sy,  0.0%ni, 95.3%id,  2.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  2.3%us,  1.0%sy,  0.0%ni, 92.7%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  1.5%us,  1.0%sy,  0.0%ni, 91.7%id,  5.8%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  1.8%us,  1.1%sy,  0.0%ni, 86.7%id, 10.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  1.3%us,  0.5%sy,  0.0%ni, 94.4%id,  3.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4056652k total,  3945504k used,   111148k free,     4300k buffers
Swap: 16383996k total,    27412k used, 16356584k free,  3506812k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4467 firebird  20   0  603m  90m 3424 S  2.7  2.3  99:21.21 firebird
...
Рейтинг: 0 / 0
29.07.2013, 00:31:13
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346930
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

индекс T_S какого размера, в страницах?
1264903 read(s)
как бы намекает, что он тупо не влезает в кэш, а значит читается каждый раз, с диска.
...
Рейтинг: 0 / 0
29.07.2013, 01:59:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346980
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvиндекс T_S какого размера, в страницах?
1264903 read(s)
как бы намекает, что он тупо не влезает в кэш, а значит читается каждый раз, с диска.Индекс весит 9.1 млн страниц.
Не понимаю, что тут фатального: "не влезает в кеш". В пром. системах полно таблиц-монстров, индексы которых не влезают в кеш - но ворочаются же.
 
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.
Analyzing database pages ...
T (129)
    Primary pointer page: 183, Index root page: 187
    Total formats: 2, used formats: 1
    Average record length: 43.20, total records: 1000000000
    Average version length: 9.00, total versions: 1000000000, max versions: 1
    Average fragment length: 5.00, total fragments: 224006938, max fragments: 1
    Average unpacked length: 44.00, compression ratio: 1.02
    Pointer pages: 26742, data page slots: 24147141
    Data pages: 24147141, average fill: 96%
    Primary pages: 20407914, full pages: 24147139, swept pages: 0
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 1
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 24147140

    Index T_S (0)
        Root page: 21213781, depth: 5, leaf buckets: 9108033, nodes: 1000000000
        Average node length: 36.11, total dup: 0, max dup: 0
        Average key length: 32.11, compression ratio: 1.12
        Average prefix length: 6.88, average data length: 29.12
        Clustering factor: 999999950, ratio: 1.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 1
            80 - 99% = 9108032
PS. тьфу... забыл я, что гстат показывает total dup... надо было сразу сюда посмотреть.
...
Рейтинг: 0 / 0
29.07.2013, 09:10:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38347035
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Таблоид,

Ребята, миллиарды записей -- это не для таких СУБД. Не для традиционных. Только columnstore.
...
Рейтинг: 0 / 0
29.07.2013, 10:07:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348006
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
ТаблоидЧто мешает сначала выяснить права на них, немедленно выдавая отказ в работе при отсутствии хотя бы одного из прав, а затем вычитывать PP ??Попытка выполнить запрос не обладая привилегиями почти наверняка "криминал", встречается относительно легитимных запросов крайне редко, ну допустим 1%, ради одного процента шулеров будешь перетряхивать всю проверку? Хотя с другой стороны очень легкий способ вызвать отказ в обслуживании. Вот ради превентивных мер против DOS может и стОит перетряхнуть?

MasterZivРебята, миллиарды записей -- это не для таких СУБД. Не для традиционных. Только columnstore.Для или не для, но многие проблемы можно поймать только нагрузочным тестом превышающим рабочую нагрузку. Спрашивается нахрена котлы проверять давлением превышающим рабочее? вот и миллиард примерно для того же самого.
...
Рейтинг: 0 / 0
29.07.2013, 23:48:49
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348025
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
 
0xFFIvan_PisarevskyСпрашивается нахрена котлы проверять давлением превышающим рабочее? вот и миллиард примерно для того же самого.
Нам в институте читали курс ТММ ("Теория машин и механизмов"), так вот: силовые тросы лифтов в жилых домах рассчитаны на нагрузку, в 12 (двенадцать) раз превышающую ту, что написана на куске жести, привинченной в кабине лифта.
...
Рейтинг: 0 / 0
30.07.2013, 00:37:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348047
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Ivan_PisarevskyХотя с другой стороны очень легкий способ вызвать отказ в обслуживании.я пока вижу одно: таблица в 1 млрд записей очень трудно ворочается. Она постоянно вытесняется на диск и "вычитка" PP становится явно узким местом. И даже select first 1 из неё запросто может стать гемором для бедного сервера.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
[root@vmoel63 fb30]# /opt/fb30cs/bin/isql -n test01.fdb
sDatabase:  test01.fdb
SQL> select current_timestamp from rdb$database; set stat on;  select first 1 * from t; 

        CURRENT_TIMESTAMP
=========================
2013-07-30 01:25:53.0380 // это в логе трейса появилось сразу, а дальше - более двух минут тишина


S                                              ID
==================================== ============
7B090244-F381-4640-8E41-B59201027A52            1

Current memory = 1223456
Delta memory = 278592
Max memory = 1292504
 Elapsed time= 164.79 sec 
Cpu = 0.00 sec
Buffers = 16384
Reads = 26771
Writes = 0
Fetches = 16135
SQL>

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.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
2013-07-30T01:25:53.0380 (1813:0x7f0b05226148) FREE_STATEMENT
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)

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

2013-07-30T01:28:37.8080 (1813:0x7f0b05226148)  PREPARE_STATEMENT 
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
  164769 ms 


2013-07-30T01:28:37.8080 (1813:0x7f0b05226148) EXECUTE_STATEMENT_START
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)

2013-07-30T01:28:37.8200 (1813:0x7f0b05226148) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
1 records fetched
     11 ms, 2 read(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                       1
...
Рейтинг: 0 / 0
30.07.2013, 01:36:29
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348053
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидBuffers = 16384
Какой мазохист такой базе даст такой мизерный кэш?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
30.07.2013, 01:42:19
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348057
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидBuffers = 16384
Какой мазохист такой базе даст такой мизерный кэш?..Он в начале был вообще дефолтным, 2048 :-)
Ну, а сколько бы ты сам назначил ?
...
Рейтинг: 0 / 0
30.07.2013, 01:55:21
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348058
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ясно же говорит:
ТаблоидReads = 26771
Вот эту цифру надо как минимум удвоить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
30.07.2013, 01:58:44
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348060
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
... не взлетает и при 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
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
... и при 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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

Ты наивно ждешь эффекта от большого кеша при первом выполнении запроса?
...
Рейтинг: 0 / 0
30.07.2013, 10:10:16
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348194
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТы наивно ждешь эффекта от большого кеша при первом выполнении запроса?нет, конечно :-)
я всё к тому, что нерационально тратить время на вычитку PP, когда стало ясно, что у мну вообще нет прав на таблицу.
...
Рейтинг: 0 / 0
30.07.2013, 10:19:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348209
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Увеличение кеша на такой базе вообще не помогает. Видимо, просто мало физической памяти.

На "разогретой" базе (насколько этот термин вообще применим к файлу 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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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Какой у этого запроса план?
...
Рейтинг: 0 / 0
30.07.2013, 13:01:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348580
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
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
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Надо тут было проверить еще раз кое-что, на миллиарднике этом.
И сразу вопрос вылез: запустил я создание индекса по полю 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
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидможет ли ФБ показывать что-то типа статистики ожиданий
сейчас нет, в недалеком будущем - возможно
...
Рейтинг: 0 / 0
21.09.2013, 12:41:48
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403521
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr,

чек мыл, плз.
(Что-то не врубаюсь: запрос к mon$-таблицам в течение работы пяти DML длится по 3-4 минуты. То ли огромный объём IO и ожидание сбросов на диск так сильно влияет, то ли еще чего. Но в целом стало получше, чем было описано в тикете 4179 )
...
Рейтинг: 0 / 0
21.09.2013, 16:04:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403572
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
И всё-таки снова вопрос про откаты после срубания незавершенных 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
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

не место этому в firebird.log. Я понимаю если бы ты это в трейсе попросил выводить, да и то для каждой таблицы сомнительно...
...
Рейтинг: 0 / 0
21.09.2013, 18:36:53
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403577
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисне место этому в firebird.log. Я понимаю если бы ты это в трейсе попросил выводить, да и то для каждой таблицы сомнительно...А что с ним станется, с firebird.логом, опухнет и лопнет ?
Вот я останавливаю базу шатдауном - и что, мне трейс перед/после этого запускать, дабы увидеть сообщение о завершении отмотки ?
(да и много ли персон из почтеннейшей публики запускают у себя трейс-то ?...)
...
Рейтинг: 0 / 0
21.09.2013, 18:45:00
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403582
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидПрочухается только после полной "отмотки взад"Ну-с, встречаем. Через 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
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

одно дело записать в firebird.log что шатдаун был, другое - пытаться туда засунуть информацию о внутренностях. Вот зачем это?
...
Рейтинг: 0 / 0
21.09.2013, 18:58:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403592
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисодно дело записать в firebird.log что шатдаун был, другое - пытаться туда засунуть информацию о внутренностях. Вот зачем это?тогда уж инфу о GC тоже из лога убирать надо. Чем не внутренности ?...
0xFF. А про спам errno=104/110 я уж вообще не говорю - такие важнейшие события отражаются в логе...
...
Рейтинг: 0 / 0
21.09.2013, 19:08:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403599
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

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

По поводу GC, errno=104/110 вроде бы есть тикет по разделению лога на несколько. Правда многим это не нравится.
errno=104/110 не совсем спам они свидетельствуют о наличии проблем в сети.
...
Рейтинг: 0 / 0
21.09.2013, 19:27:15
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403615
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Вот я останавливаю базу шатдауном - и что, мне трейс перед/после
Таблоид> этого запускать, дабы увидеть сообщение о завершении отмотки ?

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

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

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

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.09.2013, 20:05:19
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403659
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисхорошо представь себе у тебя 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
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамАга. А зачем тебе это сообщение-то?Мну давно интересно, что будет с базой, если после шатдауна её тут же начать копировать куда-нить...
Ну, то есть так: ФБ тихо дописывает в неё свои откаты срубленных BULK_DML'ей, а я чихал на это и копирую базу в этот же исторический момент на "внешний носитель"
Жаль, что база с таблицей-миллиардником занимает больше половины диска, скопировать надо было для "домашнего просмотра" :-)
...
Рейтинг: 0 / 0
21.09.2013, 21:38:05
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403675
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидВот я останавливаю базу шатдауном - и что
CORE-3809 можно уже удалять из трекера? А если нет, то какого ляда мы тут видим эти стенания? Ты проси или быстрый шатдаун или трейс медленного шатдауна, но оба вместе это уже шизофрения.
...
Рейтинг: 0 / 0
21.09.2013, 21:52:05
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403695
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
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
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403721
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

ты можешь сформулировать пользу этих сообщений в логе. Я вот например не вижу никакой. Вот что мне с того факта что при шатдауне было модифицировано такое то количество страниц в такой то таблице, началось это тогда то, закончилось тогда то. Как это вообще планируется использовать?
...
Рейтинг: 0 / 0
21.09.2013, 23:40:24
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403725
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисты можешь сформулировать пользу этих сообщений в логе. Я вот например не вижу никакой. Вот что мне с того факта что при шатдауне было модифицировано такое то количество страниц в такой то таблице, началось это тогда то, закончилось тогда то.Если кто-то из Источников Света скажет, что базу Firebird после шатдауна всегда можно "упаковывать в чемодан", копировать куда-то и проч., несмотря на идущие ней откаты DML'ей - всё, вопрос закрываем.

Если же шанс получения битой копии остается - польза от сообщений в логе будет как минимум при разборе полётов.

Симонов ДенисКак это вообще планируется использовать?Я бы просто делал скриптом:
1) шатдаун базы:
Код: plaintext
1.
2.
3.
4.
5.
#run: supertee -n -t db_shutdown_$(date +'%Y%m%d_%H%M%S').log ./db_shutdown.sh
dbname=localhost/3330:t10e9
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) starting shutdown. . .
gfix -shut full -force 0 $dbname -user sysdba -pas masterke
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) finish shutdown.
gstat -h $dbname -user sysdba -pas masterke | grep -i attributes

- и далее в этом же скрипте:
2) tail -f firebird.log - и смотрел бы, ЧТО ТАМ появляется.

Если шатдаун пришелся именно на активные DML'и, то сообщение об откатах появится в логе сразу же .
Если это сообщение будет типа такого: "<timestamp> start rollback changes on table T1, ip=192.168.12.34, connect # 2345, statement: <тут первые 300...500 букаф этого стейтмента>" - то ждём дальше "симметричного" ему сообщения об окончании по коннекту 2345.
Базу можно считать действительно закрытой, только когда число сообщений с фразами "start rollback chanes" будет равно "finish tollback changes".

ЗЫ. Ты вроде пытался поиграться DML'ями с табличкой-"миллиардершей" ? У тебя, ЕМНИП, диска тогда не хватило. Рекомендую-таки найти 100 Гб хотя бы. Сразу увидишь, что это за зверюга :-)
...
Рейтинг: 0 / 0
22.09.2013, 00:09:23
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403729
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
"600 сообщений в логе", "не страшно", "диск не переполнится". Проникся.


Таблоид> базу Firebird после шатдауна всегда можно "упаковывать в чемодан", копировать
Таблоид> куда-то и проч., несмотря на идущие ней откаты DML'ей - всё, вопрос закрываем.

При чём тут можно или нет и сообщения в логе?
Автоматом ты их всё равно не сможешь анализировать.
А если нужно тупо увидеть глазами "готово или нет",
то нужно см. результат (output и err) самого gfix-а.


Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 00:40:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403731
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Мну давно интересно

Т.е. интерес чисто теоретический и синтетический
(не говоря уже о том, что крайне редкий на практике).
Кстати, "закулисье" должно, наверное, воркэраундиться
шатдауном сервера (не проверял). Для надежности.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 00:44:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403733
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов Рустам"600 сообщений в логе", "не страшно", "диск не переполнится". Проникся.В смысле ? Что так "пробрало" ? :-)

Гаджимурадов РустамТаблоид> базу Firebird после шатдауна всегда можно "упаковывать в чемодан", копировать
Таблоид> куда-то и проч., несмотря на идущие ней откаты DML'ей - всё, вопрос закрываем.

При чём тут можно или нет и сообщения в логе?Если базу СТОПУДОВО МОЖНО копировать сразу после того, как gfix -shut вернул управление и я увидел в атрибутах гстата 'full shutdown' - то на сообщения о незавершенных откатах действительно можно покласть. Или я не прав ?

Гаджимурадов РустамАвтоматом ты их всё равно не сможешь анализировать. А если нужно тупо увидеть глазами "готово или нет", то нужно см. результат (output и err) самого gfix-а.Это почему же ? Сделать цикл с интервалом 2-3 сек, который будет подсчитывать число "открывающих" и "закрывающих" (N1, N2) мессаг в логе и вякнет "Готово, копируй!" при обнаружении N1 == N2 - что, нереально сложно что ле ?
...
Рейтинг: 0 / 0
22.09.2013, 00:49:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403735
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамТаблоид> Мну давно интересно

Т.е. интерес чисто теоретический и синтетический
(не говоря уже о том, что крайне редкий на практике).Да как же "теоретический", когда я на нашем продуктиве видел ЭТО: gfix зашатдаунил базу, а lsof продолжал еще секунд 10 показывать, что её файл открыт. Раза два или три это было, но точно - видел.
И если бы перед этим не изгалялся с нагрузочным тестом на развал индексов (а дело было в 2010, когда у нас missing entries попёрли, не к ночи будь помянуты!) - никогда бы и не узнал об этом "эффекте".

Гаджимурадов РустамКстати, "закулисье" должно, наверное, воркэраундиться
шатдауном сервера То есть, тупо вводом /etc/init.d/firebird stop ?
Гаджимурадов Рустам(не проверял). Для надежности.В чём преграда, проверь! Если есть линух - запусти нагрузочный тест с DML'ями, окон 150-200. Дай ему помолотить полчаса-час и затем зашатдауни базу. И попробуй далее ввести:
Код: plaintext
1.
/etc/init.d/firebird stop
ps -e | grep firebird

Результат, скорее всего, слегка удивит.
...
Рейтинг: 0 / 0
22.09.2013, 00:56:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403737
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

1. зачем тебе её копировать ?
2. даже если копировать - есть nbackup
3. вот на это посмотреть Таблоидlsof продолжал еще секунд 10 показывать, что её файл открыт сложнее, чем писать какие-то парсеры каких-то логов ?

Ты опять устраиваешь бурю в стакане воды. Займись чем-нить реально полезным, полно же дел вокруг...
...
Рейтинг: 0 / 0
22.09.2013, 01:04:04
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403738
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Да как же "теоретический"

Да вот так. Во-первых, на практике такое если и встречается, то редко.
Во-вторых, ну молотит - тебе-то что? Перебьёшься 10 секунд.

> В чём преграда, проверь!

Шутник. Во-первых, фб на линуксе у меня под рукой сейчас нет,
а ставить лень. Во-вторых, никаких нагрузочных тестов на 150-200
окон длительностью полчаса-час ради такой фигни я в принципе
не стал бы запускать.

> Результат, скорее всего, слегка удивит.

Так если ты его уже проверил - просто напиши, что получилось.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 01:04:43
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403739
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> В смысле ? Что так "пробрало" ? :-)

600 любых сообщений в логе. Любых.

> Или я не прав ?

А ХЗ, не уверен. Допустим, не можешь. Дальше что?

> нереально сложно что ле ?

Я знаю, что у тебя энергии и времени немеряно,
но не проще ли тупо поставить паузу на минуту
и проверить этот самый lsof ?

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 01:07:12
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403741
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvlad1. зачем тебе её копировать ?потому что несколько раз возникали ситуации, когда надо поиметь максимально актуальную копию продуктива, причём быстро (=> b/r не катит). Ночная копия - да, была, но косяк вылез именно на данных, вбитых сегодня.

hvlad2. даже если копировать - есть nbackupЭто я попозже стал делать. Хороший способ, но... там главное всё время быть рядом с экраном и следить, чтобы скрипт обязательно дошёл до строки с 'nbackup -N', а не то "снег башка упадёт" :-)

hvlad3. вот на это посмотреть Таблоидlsof продолжал еще секунд 10 показывать, что её файл открыт сложнее, чем писать какие-то парсеры каких-то логов ?парсер тем и хорош, что "смотрит" за меня и "глаз" у него не замыливается. Один раз помучился, отладил - дальше спи спокойно.

hvladТы опять устраиваешь бурю в стакане воды. Займись чем-нить реально полезным, полно же дел вокруг...я веду непримиримую борьбу за ликвидацию записи в файл базы после шатдауна!
Разве это не реально полезнейшая задача ?! :-)
...
Рейтинг: 0 / 0
22.09.2013, 01:28:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403742
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидя веду непримиримую борьбу за ликвидацию записи в файл базы после шатдауна!А при чём тут спам в логе ?
И разве тебе не сказали много раз, что откаты при шатдауне будут оптимизированны ?
Или тебе нравится бесконечно ковырять эту тему ?

ТаблоидРазве это не реально полезнейшая задача ?! :-)Я бы её даже в первый десяток актуальных не ставил...
...
Рейтинг: 0 / 0
22.09.2013, 01:32:37
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403743
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамТаблоид> Да как же "теоретический"

Да вот так. Во-первых, на практике такое если и встречается, то редко.Редко, не спорю. Только мне последствия интересны, а не "частота встреч" :-)

Гаджимурадов РустамВо-вторых, ну молотит - тебе-то что? Перебьёшься 10 секунд.Кхе! это на нашем продакшене было 10 сек, и то - по памяти говорю, могу и ошибаться.
А если бы кто запустил что-то "могучеее", то и несколько минут могло бы быть. Посмотри выше - и 40 минут можно при желании "сбацать" :-)

Гаджимурадов РустамВо-вторых, никаких нагрузочных тестов на 150-200
окон длительностью полчаса-час ради такой фигни я в принципе
не стал бы запускать.То есть, ты ТОЧНО уверен, что запись в базу после шатдауна ничем не грозит базе, которую в этот же момент куда-то там "откладывают" в виде backup'а. Я правильно тебя понял ?

Гаджимурадов Рустам> Результат, скорее всего, слегка удивит.

Так если ты его уже проверил - просто напиши, что получилось.Дык вот же , полтора года уже как.
...
Рейтинг: 0 / 0
22.09.2013, 01:36:14
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403746
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидя веду непримиримую борьбу за ликвидацию записи в файл базы после шатдауна!А при чём тут спам в логе ?Спам - это как раз нынешние errno=104/110.

hvladИ разве тебе не сказали много раз, что откаты при шатдауне будут оптимизированны ?
Или тебе нравится бесконечно ковырять эту тему ?Я прекрасно понимаю, что если они и будут оптимизированы, то еще не скоро. И потому спросил: до того, как состоится эта оптимизация, - нельзя ли сделать вот эту фичу ? Насколько это сложно вообще: добавить вывод в лог таких сообщений ?

hvladТаблоидРазве это не реально полезнейшая задача ?! :-)Я бы её даже в первый десяток актуальных не ставил...Да пускай себе торчит в разряде миноров, раз это от Царя Гороха так. Но хотя бы вывод в лог ФБ добавь(те), ну ?..
...
Рейтинг: 0 / 0
22.09.2013, 01:43:38
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403747
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамТаблоидЕсли базу СТОПУДОВО МОЖНО копировать сразу после того, как gfix -shut вернул управление и я увидел в атрибутах гстата 'full shutdown' - то на сообщения о незавершенных откатах действительно можно покласть. Или я не прав ?А ХЗ, не уверен. Допустим, не можешь. Дальше что?Если НЕ могу покласть на такие сообщения ?? сам понимаешь: тогда они точно ДОЛЖНЫ быть в логе, а не только в трезвом мозгу ДБАя. Ибо если он забил на них и начал копировать базу, а дальше продакшен слетел и актуальной копией является "та самая", и она оказалась битой, то... телефон kdv на у него сайте вроде всегда висит

Гаджимурадов РустамЯ знаю, что у тебя энергии и времени немеряно, но не проще ли тупо поставить паузу на минуту и проверить этот самый lsof ?ну так я и делал именно это! Но разве ты не видишь, что тут "чел. фактор" ? Ну забыл бы я однажды про это, или кто другой вместо мну стал бы шатдаунить...
...
Рейтинг: 0 / 0
22.09.2013, 01:51:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403765
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Только мне последствия интересны, а не "частота встреч" :-)

Последствия чего? Ну выстрели себе в ногу -
тоже редко, тоже интересны последствия будут.

> Кхе! это на нашем продакшене было 10 сек, и то - по памяти говорю, могу и ошибаться.
> А если бы кто запустил что-то "могучеее", то и несколько минут могло бы быть.
> Посмотри выше - и 40 минут можно при желании "сбацать" :-)

При желании можно и буй шар проглотить, да.
Могучего можно пересчитать по пальцам, да и те
живут на репликаторах да на nbackup-ах и живую
БД посреди дня шатдаунить не собираются. А если
вдруг почему-то и соберутся - будут делать это
ручками, а не никакой не автоматикой/парсером.
И да, обождут 10 секунд, минуту, если надо - две.

> Я правильно тебя понял ?

Нет, неправильно. Я сказал то, что сказал.
Кому надо - подождёт. Кому чешется - тот ССЗБ.
Кстати, с оригиналом ничего и не будет, скорее
всего, в отличие от копии. Но зуб никто не даст.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 03:25:45
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403766
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> сам понимаешь: тогда они точно ДОЛЖНЫ быть в логе

Нет, не понимаю. В логе этому не место.
Повторюсь, если нужна развернутая
статистика (любая) - место ей в output
и err gfix-а, а не в логе сервера.

> Ибо если он забил на них и начал копировать базу

А смысл о чём-то дальше говорить, если
он на них забил? Ну он точно так же на
сообщения в логе может забить?

Дело не только в том, что ты пытаешься
бурю в стакане замутить, как сказал Влад,
мало того - и буря-то толком не получается.

> Но разве ты не видишь, что тут "чел. фактор" ?

Нет, не вижу. Чем отличается человеческий фактор
"посмотрел lsof" или "посмотрел gfix output" от
"посмотрел лог" (при том, что лог не твой) ?
Как по мне, так второе и даже первое много
лучше и удобнее третьего, которое ты просишь.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 03:31:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403804
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамДело не только в том, что ты пытаешься
бурю в стакане замутить, как сказал Влад,
мало того - и буря-то толком не получается.Ладно. Раз все спокойны на этот счет, значит проблема действительно была только в моей голове.
Оставим эту тему, но надеюсь, что тот тикет когда-нить перейдёт в resolved.
...
Рейтинг: 0 / 0
22.09.2013, 10:54:47
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403821
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
ТаблоидЕсли кто-то из Источников Света скажет, что базу Firebird после шатдауна всегда можно "упаковывать в чемодан", копировать куда-то и проч., несмотря на идущие ней откаты DML'ей - всё, вопрос закрываем.

Лучше бы тогда попросил что бы

Код: plaintext
gfix -shut full -force 0 $dbname -user sysdba -pas masterke

возвращало управление только по окончанию всех откатов. Уж куда проще для твоих скриптов.
...
Рейтинг: 0 / 0
22.09.2013, 12:09:37
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403827
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Симонов ДенисЛучше бы тогда попросил что бы

Код: plaintext
gfix -shut full -force 0 $dbname -user sysdba -pas masterke

возвращало управление только по окончанию всех откатов.
вообще-то, в свежих билдах так оно и должно быть. И я несколько удивлен, что это не так. Так что предлагаю Таблоиду вынести доказательства этого вопроса в отдельный топик. А то "кони, люди" в этой теме начинают утомлять.
...
Рейтинг: 0 / 0
22.09.2013, 12:21:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403831
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrСимонов ДенисЛучше бы тогда попросил что бы

Код: plaintext
gfix -shut full -force 0 $dbname -user sysdba -pas masterke

возвращало управление только по окончанию всех откатов.
вообще-то, в свежих билдах так оно и должно быть. И я несколько удивлен, что это не так. Так что предлагаю Таблоиду вынести доказательства этого вопроса в отдельный топик.Дык вот же, вчерась ещё. И ниже чуток, когда я дождался таки через 40 минут.
ЗЫ. А я - наоборот, сильно бы удивился, если gfix -shut стал бы синхронным и не вертал управление в ось до полного завершения откатов. Это наверняка было бы записано в моей любимой утренней газете , но там тишина пока что.
...
Рейтинг: 0 / 0
22.09.2013, 12:32:19
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403836
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

попрошу на кошках вменяемого размера пример, твой миллиард никто в здравом уме заливать не будет
...
Рейтинг: 0 / 0
22.09.2013, 12:48:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403859
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrпопрошу на кошках вменяемого размера пример, твой миллиард никто в здравом уме заливать не будетну так там не миллиард апдейтов было, а гораздо меньше. Просто ему тяжко было обновлять два индекса, КМК, вот он и застрял с откатами на такое время.

Кому интересно - залейте у себя 200-300 млн записей в такую же таблицу:
 
Код: 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)
- это не 80 Гб будет, а всего лишь 20. Время заливки будет 1-2 часа, вряд ли больше.

Затем делаем следующее (с предварительно запущенным трейсом):

session #1
isql 192.168.99.44/3330:t10e9 -n | mtee /t isql_log.txt
12:34:43.311 Database: 192.168.99.44/3330:t10e9
12:34:43.311 SQL> set plan on; set stat on; update t set s01=s02, s02=s01;

12:36:12.592 PLAN (T NATURAL)

session #2
запускаем shell-скрипт, который в цикле будет запрашивать мон-таблицы, с интервалом 10 сек. Запрос этот приведен выше в этом топеге, впрочем - вот, еще раз:
 
askmon.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.
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
;
 
askmon.sh
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
# askmon.sh
delay=10

fdb=t10e9
#/var/db/fb30/t3e8.fdb
fbport=3330
fbhome=/opt/fb30/bin
log=./logs/mon30_$(date +'%Y%m%d_%H%M%S').log
rm -f $log
while :
do
  echo -----------------------------------------------------------------------------------
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - starting quering mon tables
  $fbhome/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n -m -i askmon30.sql | sed -e "s/ \{1,\}$//" >>$log
  # -o askmon.log
  # cat askmon.tmp | sed -e "s/ \{1,\}$//" >>askmon.log
  ls -la $log
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - done. Now take some sleep. . .
  #ls -la /tmp/core.*
  sleep $delay
done



Дальше даём поработать минут 10, больше не нужно.

session #3
шатдауним базу, с логированием моментов времени:
 
db_shutdown.sh
Код: plaintext
1.
2.
3.
4.
dbname=localhost/3330:t10e9
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) starting shutdown. . .
gfix -shut full -force 0 $dbname -user sysdba -pas masterke
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) finish shutdown.
gstat -h $dbname -user sysdba -pas masterke | grep -i attributes
Код: plaintext
1.
2.
2013-09-22 12:43:23.4028 starting shutdown. . .
2013-09-22  12:43:32 .0325 finish shutdown.
        Attributes              full shutdown

Итак, управление в ось из gfix -shut вернулось через 32-23 = 9 секунд.

А теперь смотрим в isql-окно. У мну в нём показано вот это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Statement failed, SQLSTATE = HY000
database t10e9 shutdown
 12:48:56 .889 Current memory = 1154286256236196432
12:48:56.889 Delta memory = 1154286255133019200
12:48:56.889 Max memory = 19364495713684464
12:48:56.889 Elapsed time= 764.32 sec
12:48:56.889 Buffers = 4510032
12:48:56.889 Reads = 1154047425988526046
12:48:56.889 Writes -4216675458143171601
12:48:56.889 Fetches = 50392920015175064
12:48:56.889 SQL>

А еще смотрим в лог скрипта, запрашивавшего мон-таблицы, и обращаем внимание на моменты времени, когда он запускал isql и возвращался из него. Но только на те моменты, которые уже после шатдауна ( 12:43:32 ) были:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
2013-09-22 12:43:32.9232 - starting quering mon tables
-rw-r--r--. 1 root root 52164 Sep 22 12:43 ./logs/mon30_20130922_123440.log
2013-09-22 12:43:59.0390 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:44:09.0683 - starting quering mon tables
-rw-r--r--. 1 root root 52416 Sep 22 12:44 ./logs/mon30_20130922_123440.log
2013-09-22 12:44:34.4666 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:44:44.4707 - starting quering mon tables
-rw-r--r--. 1 root root 52668 Sep 22 12:45 ./logs/mon30_20130922_123440.log
2013-09-22 12:45:02.5571 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:45:12.5611 - starting quering mon tables
-rw-r--r--. 1 root root 52920 Sep 22 12:45 ./logs/mon30_20130922_123440.log
2013-09-22 12:45:30.5999 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:45:40.6045 - starting quering mon tables
-rw-r--r--. 1 root root 53172 Sep 22 12:46 ./logs/mon30_20130922_123440.log
2013-09-22 12:46:09.7788 - done. Now take some sleep. . .
(т.е. видим, что облом на тему 'database shutdown' isql получает почему-то не сразу, а через 15-20 секунд, а то и больше).

Ну, и наконец - данные трейса.
Вот старт DMl-стейтмента:
 
12:33:12
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2013-09-22T 12:33:12 .1680 (29443:0x7f2e1f68ffb0) EXECUTE_STATEMENT_START
	t10e9 (ATT_550, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:12616
		(TRA_1044, CONCURRENCY | WAIT | READ_WRITE)

Statement 21:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
(время отличается от isql'ного потому, что isql был запущен с виндовой машины, а она с этим сервером не синхронизирована)

Вот я gfix'ом сказал базе "спать!":
 
12:43:25
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) TRACE_INIT
	SESSION_8  
	

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) FAILED ATTACH_DATABASE
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:12685

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) ERROR AT JProvider::attachDatabase
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:12685
335544528 : database t10e9 shutdown

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) TRACE_FINI
	SESSION_8

А вот завершение DML-откатов:
 
12:45:56
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
2013-09-22T12:45:56.4850 (29443:0x7f2e1f68ffb0) FAILED EXECUTE_STATEMENT_FINISH
	t10e9 (ATT_550, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:12616
		(TRA_1044, CONCURRENCY | WAIT | READ_WRITE)

Statement 21:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
0 records fetched
 764316 ms, 449133 read(s), 5051 write(s), 4766218 fetch(es), 1046385 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       6                                                            
T                                  115812              115811                        115811


ИТОГО: gfix -shut вернул управление, но движок после этого еще 2.5 минуты продолжал запись откатов.

И еще раз повторю. Для воспроизведения сего не надо иметь таблицу в 1 млрд записей. Сделайте 200-300 млн, навесьте 2-3 индекса и запустите апдейт, включающий эти индексные поля. Дайте ему промолотить 10 минут.

ЗЫ. Делал на LI-T3.0.0.30661
...
Рейтинг: 0 / 0
22.09.2013, 13:26:23
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403864
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоид
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
PLAN (T NATURAL)
0 records fetched
 764316 ms, 449133 read(s), 5051 write(s), 4766218 fetch(es), 1046385 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       6                                                            
T                                  115812              115811                        115811
м-нда... (115811+115811) / 764 = ~300 апдейтов в секунду.
При pagesize = 16384, двух индексах и глубине каждого = 3.
Жесть, короче!..
...
Рейтинг: 0 / 0
22.09.2013, 13:32:23
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403866
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

ну на 3.0 понятно. Туда некоторые вещи могли забыть портировать. Ты проверь на последнем 2.5
...
Рейтинг: 0 / 0
22.09.2013, 13:34:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403869
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

я для кого просил делать это в отдельной теме?
...
Рейтинг: 0 / 0
22.09.2013, 13:35:54
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403879
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидgfix -shut вернул управление, но движок после этого еще 2.5 минуты продолжал запись откатов
движок ли? FW ON или OFF?
...
Рейтинг: 0 / 0
22.09.2013, 14:03:46
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403888
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидgfix -shut вернул управление, но движок после этого еще 2.5 минуты продолжал запись откатов
движок ли? FW ON или OFF?FW=OFF (а я же высылал тебе эту базейку вчера...).
Но если надо, могу и на ON проверить.
...
Рейтинг: 0 / 0
22.09.2013, 14:28:46
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403890
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

проверь, оно может тебя удивить...
...
Рейтинг: 0 / 0
22.09.2013, 14:31:14
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403894
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrпроверь, оно может тебя удивить...Хорошо, проверю.
Сделал новый топег на эту тему, как ты сказал. Результаты выложу там.
...
Рейтинг: 0 / 0
22.09.2013, 14:36:36
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403897
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисТы проверь на последнем 2.5ну проверь сам-то, на 2.5. Ты же грозился вроде с большой таблицей поиграться, не ?
...
Рейтинг: 0 / 0
22.09.2013, 14:40:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403950
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

дык игрался уже со 10E8. И таки да откаты не очень быстры, но их же обещали ускорить.

Про миллиард записей в таблице во время подготовки запроса вроде Дмитрий говорил, что в этом направлении ещё ничего не сделано. Вот сделает Влад экстенты, асинхронный IO и мультиблочное чтение тогда можно будет посмотреть, а пока и без того есть много мест для тестирования. Хотя экстенты обещались только для DP, может и PP будут выделятся группами. а это теоретически позволит ускорить первую подготовку запроса.

P.S. Если я ересь написал просьба меня поправить.
...
Рейтинг: 0 / 0
22.09.2013, 15:33:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403956
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисПро миллиард записей в таблице во время подготовки запроса вроде Дмитрий говорил, что в этом направлении ещё ничего не сделано. Вот сделает Влад экстенты, асинхронный IO и мультиблочное чтение тогда можно будет посмотреть, а пока и без того есть много мест для тестирования. Хотя экстенты обещались только для DP, может и PP будут выделятся группами. а это теоретически позволит ускорить первую подготовку запроса.Но я не про подготовку запроса говорю. Она тут вообще мало интересна, да и на разогретой базе-миллиарднице выполняется за 2-3 секунды.
...
Рейтинг: 0 / 0
22.09.2013, 15:40:05
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403960
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

вообще-то в начале темы разговор был именно об этом. Но ты как всегда перевёл её в другое русло.
...
Рейтинг: 0 / 0
22.09.2013, 15:43:26
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403969
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисвообще-то в начале темы разговор был именно об этом. Но ты как всегда перевёл её в другое русло.В этом топеге, начатом в ноябре 2012, вскрылось много чего. Задержки в препарировании из-за большого числа PP - это только одна из тем.
Я возобновил разговор вчера с вопросом об отражении в статистике времени ожидания IO, а затем уже спросил про "отмотки назад".
Все эти артефакты объединены общим: таблицей большого размера. Выносить в отдельный топег каждый под вопрос, возникающий в ЭТОЙ базе, смысла не вижу никакого.
...
Рейтинг: 0 / 0
22.09.2013, 15:56:17
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403971
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
ТаблоидВыносить в отдельный топег каждый под вопрос, возникающий в ЭТОЙ базе, смысла не вижу никакого.Даже я, когда общаюсь с "нашим" разработчиком, периодически дроблю единую (для нас) проблему на несколько. И это - платная поддержка.
А здесь - форум, которому не очень интересно отслеживать "внутреннее состояние объекта Таблоид".
Поэтому разумным является или личное общение или, всё-таки, дробление тем с предварительным обдумыванием на тему "а надо ли вообще спрашивать публично?".
...
Рейтинг: 0 / 0
22.09.2013, 16:01:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403994
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Basil A. SidorovДаже я, когда общаюсь с "нашим" разработчиком, периодически дроблю единую (для нас) проблему на несколько. И это - платная поддержка.
А здесь - форум, которому не очень интересно отслеживать "внутреннее состояние объекта Таблоид".
Поэтому разумным является или личное общение или, всё-таки, дробление тем с предварительным обдумыванием на тему "а надо ли вообще спрашивать публично?".А ты тут за весь форум вещаешь, что ле ? я и не знал, что коллективный разум теперь в твоей персоне воплощен :-)
Прежде, чем спрашивать, я всегда делаю проверку. Дважды. А затем стараюсь писать вопрос так, чтобы не нужно было лезть за предысторией куда-то вверх в этом же топике. Либо же тынц на пост добавляю - но в любом случае делаю так, чтобы не нужно было долго вспоминать "контекст беседы".
В упор не понимаю, для чего плодить новый топег, если старый не утонул и отклонение от его темы незначительное.

ЗЫ. Да, и насчет публичности. Тебе, наверное, платный саппорт помогает, либо в ФБ всё давно ясно и понятно. Оттого тебя с вопросами тут и не видно (5 топиков за 5 лет :)).
У нас такого саппорта никогда не было, а база продакшена оказалась сразу сильно нагруженной, плюс сумасшедшие огрехи разрабов клиентской части приложения, плюс идиотизм проектировщика схемы (его я бы лично убил об стенку). В то время 2.5 еще только как RC-2 был, а на 2.1 всё просто помирало (семафоры, кажись, проблемы вызывали - не помню уже). Перешли мы на этот 2.5 RC - и оказалось, что поддержку по нему можно спрашивать только тут, у Влада или ДЕ.
ЗЗЫ. Не было бы Влада и ДЕ на этом форуме - соскочили бы с ФБ очень многие. ИМХО.
...
Рейтинг: 0 / 0
22.09.2013, 16:34:22
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403997
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Basil A. Sidorov,

да нет как раз многие вещи надо публично обсуждать. И Таблоид правильно делает. Правда иногда слишком увлекается...
...
Рейтинг: 0 / 0
22.09.2013, 16:38:18
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38403999
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидВыносить в отдельный топег каждый под вопрос, возникающий в ЭТОЙ базе, смысла не вижу никакого.Вот тебе смыслы:
1. невозможно перечитывать эти 7 страниц (а ведь их будет больше), в поисках деталей теста или проблемы, перескакивая с пятого на тридцать пятое
2. элементарно забыть\потерять какую-то из проблем, рассыпанных по этим страницам и закопанным в потоке флуда и других проблем

Достаточно ?
...
Рейтинг: 0 / 0
22.09.2013, 16:43:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38404000
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов Денис,

+1
...
Рейтинг: 0 / 0
22.09.2013, 16:43:16
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38404004
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидВыносить в отдельный топег каждый под вопрос, возникающий в ЭТОЙ базе, смысла не вижу никакого.Вот тебе смыслы:
1. невозможно перечитывать эти 7 страниц (а ведь их будет больше), в поисках деталей теста или проблемы, перескакивая с пятого на тридцать пятое
2. элементарно забыть\потерять какую-то из проблем, рассыпанных по этим страницам и закопанным в потоке флуда и других проблем

Достаточно ?А чем поиск ВНЕ топика, т.е. в оглавлении тем, лучше ?! в заголовок темы часто не затолкаешь всего, что надо! я по-максимуму стараюсь тему сделать информативной, но с течением времени всё равно забываю даже обрывки её формулировки. Искать в итоге приходится "нырянием" в каждый "подозрительно похожий" топик - т.е. опять ВНУТРЬ заходить надо.

Впрочем, как хотите, джентльмены. Желаете "фрагментацию" - будет пять топиков с перекрестными ссылками друг на друга, и все - вокруг одного и того же миллиарда записей (например).
...
Рейтинг: 0 / 0
22.09.2013, 16:52:02
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38404005
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Симонов ДенисИ Таблоид правильно делает. Правда иногда слишком увлекается..."Тост должен быть кратким, как выстрел".
...
Рейтинг: 0 / 0
22.09.2013, 16:52:30
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38404006
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
"Желаю, чтобы все!" - ?
...
Рейтинг: 0 / 0
22.09.2013, 16:57:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38404022
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Симонов Денис> да нет как раз многие вещи надо публично обсуждать

+ много

Симонов Денис> И Таблоид правильно делает

Смотря что. Много чего и неправильно, о многом уже и говорилось.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
22.09.2013, 17:35:20
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406476
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Болтик
Участник
kdvТаблоидпочему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
склероз у тебя, хотя dataaccesspaths ты вроде неоднократно читал. по PP сервер вычисляет кардинальность таблицы, т.е. сколько там может быть записей (теоретически).

Во наконец то. Ему надо теоретическое значение, тогда почему не прилепите в таблице поле в котором для сервера теоритически будут добавляться и удаляться количества записей и не надо будет бегать чего то пересчитывать каждый раз.
...
Рейтинг: 0 / 0
24.09.2013, 18:32:42
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406482
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Евгений Болтикпочему не прилепите
Увеличение ввода-вывода - тормоза.
Горячая точка - большие тормоза.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
24.09.2013, 18:38:18
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406490
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Болтик
Участник
ТаблоидdimitrПростого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому. Ну, подняли граф зависимостей, там 10 объектов.
Что мешает сначала выяснить права на них, немедленно выдавая отказ в работе при отсутствии хотя бы одного из прав, а затем вычитывать PP ??

Я так понимаю можно это сделать, но это не надо т.к. таких ситуаций 1 на миллион, а переделок куча. Обычно когда кто то ломится получить от сервера у него есть на это права. Хотя тоже согласен нафига чет делать если нет доступа.

Есть единственная засада накладные расходы на дерганье по отдельности 10 объектов по сравнению с 1 дерганьем но всех данных. Я с таким сталкивался. Понимаешь когда система слабенькая и видно как тормозят отдельно идущие запросы. Связал в один пучек и обалдел просто раньше лень было писать и нужды не было. 10 это все равно что 10 раз препаре если я и понимаю только помноженное на дополнительные запросы со своими препаре. От суда 1 боооольшой препар, но относительно быстрый. Я прав ГУРУ?
...
Рейтинг: 0 / 0
24.09.2013, 18:46:09
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406519
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Болтик
Участник
Dimitry SibiryakovЕвгений Болтикпочему не прилепите
Увеличение ввода-вывода - тормоза.
Горячая точка - большие тормоза.


А вот тут поподробней с чего бы это тормоза. Пусть даже будет 65000 таблиц в базе это настолько мало по сравнению с данными. Дергаться та будут одни и те же строки. Я понимаю что мам блокировки и т.п. но это можно решить теми же способами что ты с агрегатами предлагал мне почитать. Зато оценка на порядки будет быстрей, не надо будет IO лишние делать. Или может мы друг друга не поняли ;)
...
Рейтинг: 0 / 0
24.09.2013, 19:10:44
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406530
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Евгений Болтик10 это все равно что 10 раз препаре если я и понимаю только помноженное на дополнительные запросы со своими препаре. От суда 1 боооольшой препар, но относительно быстрый.В firebird'e затраты на prepare - ничтожные .

ЗЫ. А kdv в том топике оказался прав , но я это оценил только после знакомства с миллиардершей
...
Рейтинг: 0 / 0
24.09.2013, 19:20:09
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406535
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovУвеличение ввода-вывода - тормоза.
Горячая точка - большие тормоза. 2 DS : возможно, он говорит о периодически обновляемых (встроенным планировщиком ?) оценках:
1) кардинальности таблиц
2) гистограмм распределения данных.
Такие обновления (например, раз в сутки ночером) не могут быть "горячей точкой".

Но это в ФБ-3 если и будет, то очень нескоро, КМК.
...
Рейтинг: 0 / 0
24.09.2013, 19:25:04
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406539
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидвозможно, он говорит о периодически обновляемых (встроенным планировщиком ?)
оценках
Пока он не сформулирует своё предложение точно и не изложит его полными
предложениями, ни ты, ни я это не узнаем.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
24.09.2013, 19:30:43
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406543
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Болтик
Участник
ТаблоидЕвгений Болтик10 это все равно что 10 раз препаре если я и понимаю только помноженное на дополнительные запросы со своими препаре. От суда 1 боооольшой препар, но относительно быстрый.В firebird'e затраты на prepare - ничтожные .

ЗЫ. А kdv в том топике оказался прав , но я это оценил только после знакомства с миллиардершей

Я не полную картину тогда раскрыл. Каждый препар+данные 9 таких были препаре и получение данных о доступе, а 10 получили а доступа нет.
То есть получается дерганье по 1 строке данных накладней чем за раз вернуться все 10 и их проверят на доступ.
...
Рейтинг: 0 / 0
24.09.2013, 19:35:14
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406552
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Евгений БолтикЯ не полную картину тогда раскрыл. Каждый препар+данные 9 таких были препаре и получение данных о доступе, а 10 получили а доступа нет.
То есть получается дерганье по 1 строке данных накладней чем за раз вернуться все 10 и их проверят на доступ.Мне ничего не понятно. Нельзя ли хотя бы знаки препинания расставить, да просто не торопиться при печати и перечитывать своё сообщение в предпросмотре, т.е. _до_ публикации ? (без обид, плз)

ЗЫ. Лично я убедился на таблице в 10Е9 строк, что когда PP отсутствуют в кеше, то затраты на их "вычитку" могут длиться 20-30 сек. Но дальше этих затрат нет, там миллисекунды. До тех пор, ес-сно, пока таблицу из кеша кто-то не вытолкнет.
...
Рейтинг: 0 / 0
24.09.2013, 19:45:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406553
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоиддальше этих затрат нет, там миллисекунды.
А, случайно так, не потому, что полученное значение кэшируется где-нибудь в кэше метаданных?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
24.09.2013, 19:51:21
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406562
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоиддальше этих затрат нет, там миллисекунды.
А, случайно так, не потому, что полученное значение кэшируется где-нибудь в кэше метаданных?..Нет, это кеш операционки. Можно выйти из isql'я, мучительно читавшего PP (и дочитавшего таки), рестартовать ФБ, затем войти опять - и вычитка уже будет быстрой, без тормозов.
...
Рейтинг: 0 / 0
24.09.2013, 20:01:49
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406590
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
ТаблоидDimitry SibiryakovУвеличение ввода-вывода - тормоза.
Горячая точка - большие тормоза. 2 DS : возможно, он говорит о периодически обновляемых (встроенным планировщиком ?) оценках:
1) кардинальности таблиц
2) гистограмм распределения данных.
Такие обновления (например, раз в сутки ночером) не могут быть "горячей точкой".

Но это в ФБ-3 если и будет, то очень нескоро, КМК.

Вроде на бету тройки запланировано CORE-1082
...
Рейтинг: 0 / 0
24.09.2013, 20:32:18
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406594
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисВроде на бету тройки запланировано CORE-1082 псип! ("голосуем, а то проиграем!")
...
Рейтинг: 0 / 0
24.09.2013, 20:44:55
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406597
Евгений Болтик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Евгений Болтик
Участник
ТаблоидЕвгений БолтикЯ не полную картину тогда раскрыл. Каждый препар+данные 9 таких были препаре и получение данных о доступе, а 10 получили а доступа нет.
То есть получается дерганье по 1 строке данных накладней чем за раз вернуться все 10 и их проверят на доступ.Мне ничего не понятно. Нельзя ли хотя бы знаки препинания расставить, да просто не торопиться при печати и перечитывать своё сообщение в предпросмотре, т.е. _до_ публикации ? (без обид, плз)

ЗЫ. Лично я убедился на таблице в 10Е9 строк, что когда PP отсутствуют в кеше, то затраты на их "вычитку" могут длиться 20-30 сек. Но дальше этих затрат нет, там миллисекунды. До тех пор, ес-сно, пока таблицу из кеша кто-то не вытолкнет.

без обид перечитываю ;). Сразу скажу чтобы не запутался речи про РР не было.

Я не полную картину тогда раскрыл. Каждый препар+данные.

Предположим прошли 9 таких препаре и получение данных о доступе, а 10-й получили в доступе отказано.
То есть получается, дерганье даже по 1 строке данных о доступе накладней, чем за раз вернуться все 10 и их проверят на доступ.
Но как ты понимаешь там не только доступ там еще и данные об индексах и т.п.

Эту модель я понимаю, по той причине, что столкнулся с слабым VPN подключением и были запросы проверки доступа по объектно. В обычной сети все летало. Теперь получаю доступ сразу для всех объектов к которым будет доступ и + доп информацию которую дергал когда проверил доступ. Оказалось намного быстрей чем просто проверить доступ, а потом продолжить дальше дополнительные запросы. В более чем 18 раз быстрей стала загружаться программа. Опять же в обычной сети я этого прироста не вижу. Получается лопатил только для одного клиента. Зато он рад от 10 сек до 30 сек у него наточках подключаются.

Если переложить это на сервер, то там сделано было так как сейчас сделано, по той причине, что тормозило раньше на том железе прошлого века. А сейчас мы спорим, что зачем так сделали. Единственное я не понимаю зачем все же РР туда так воткнули и почему так сделали подсчет РР. Харды же были медленные и можно было этот провал заметить.
...
Рейтинг: 0 / 0
24.09.2013, 20:58:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38406603
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Евгений БолтикХарды же были медленные и можно было этот провал заметить.Провал виден на среднем (по сегодняшним меркам) диске при числе записей, которое в прошлом веке казалось нереальным. В том числе - из-за ёмкости большинства тогдашних хардов.
Первый тест "большегрузной базы" сделал kdv в 2009 (а не в прошлом веке). Таблица у него была еще больше: 3.2 млрд записей, 359 Гб (см тут , таблица ORDER_LINE).
На вот это: kdv После открытия БД prepare занимает около 20 секунд . Правда, повторная операция prepare происходит мгновенно. Это понятно – серверу в первый раз после соединения к БД необходимо загрузить метаданные, а они для таблиц и индексов находятся в очень отдаленных уголках файла БД.- я не обратил тогда никакого внимания, пока сам не упёрся в этот "артефакт".

Однако есть подозрение, что в тесте kdv всё идет "от SYSDBA", т.к. никакого упоминания про недоступные объекты и время, потраченное на "осознание" этой недоступности, нету.
...
Рейтинг: 0 / 0
24.09.2013, 21:20:47
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417633
ArtDen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ArtDen
Гость
Грустно как-то. Почитал топик и решил провести подобные эксперименты с SQLite. SQLite конечно не версионник и не многопользовательская СУБД, но всё равно было интересно, насколько быстро оттуда будут работать запросы, при условии, что они себя позиционируют как СУБД для маленьких объёмов данных.

Сделал в базе одну таблицу
Код: sql
1.
2.
3.
4.
5.
create table test (
  id integer not null primary key,
  value1 integer not null,
  value2 integer not null
);


value1 и value2 заполнил рандомно, id - по автоинкременту. Всего 3 миллиарда записей. База получилась 45 Гб. Больше не стал пихать, т.к. на диске кончилось место.

Перезагружаю комп. Первый запрос:
Код: sql
1.
select * from test t where t = 2000000000


время выполнения 1.3 мс O_o
Повторно этот же запрос выполняется менее чем за 0.2 мс
...
Рейтинг: 0 / 0
05.10.2013, 12:46:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417639
Йонас Сусанис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Йонас Сусанис
Гость
ArtDenSQLite конечно не версионник и не многопользовательская СУБДСравнение тёплого с липким.
Тогда бы уж лучше на Cache` попробовали (только не в режиме прямой работы с глобалами, когда 100500 млн строк за 1 сек вставляются; этот фокус тут не прокатит :)). Они хотя бы утверждают, что многопользовательские (правда, не версионник, а блокировочник).
...
Рейтинг: 0 / 0
05.10.2013, 13:01:11
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417654
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
ArtDenid - по автоинкременту. Всего 3 миллиарда записей.
А какое значение стало у Id сразу после 2 147 483 647? :)
...
Рейтинг: 0 / 0
05.10.2013, 13:23:02
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417658
ArtDen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ArtDen
Гость
NickDeeА какое значение стало у Id сразу после 2 147 483 647? :)
Правильное стало :) Для кого-то это будет открытием, но SQLite хранит целые числа полем переменной длины от 1 до 8 байт в зависимости от значения поля: http://sqlite.org/datatype3.html
авторINTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value.
...
Рейтинг: 0 / 0
05.10.2013, 13:33:07
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417861
Sheez
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sheez
Участник
ArtDen Всего 3 миллиарда записей. База получилась 45 Гб. Больше не стал пихать, т.к. на диске кончилось место.


По поводу объемов, я перегнал свою экспериментальную базу из FB в SQlite обьем базы меньше в 2 раза при той-же структуре.
Сейчас база SQLite весит более 350 ГБ, глюков и сбоев не замечено.
...
Рейтинг: 0 / 0
05.10.2013, 22:44:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38417865
Вано Сусанишвили
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вано Сусанишвили
Гость
Sheezя перегнал свою экспериментальную базу из FB в SQlite обьем базы меньше в 2 раза при той-же структуре.
Сейчас база SQLite весит более 350 ГБ, глюков и сбоев не замечено....при одновременной работе 300 пользователей, правильно ведь ? ;-)
...
Рейтинг: 0 / 0
05.10.2013, 22:58:21
| Ответить | Цитировать | Написать  
189 сообщений из 189, показаны все 8 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1564260]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 177ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 255ms
get tp. blocked users:
 1ms
others: 193ms
total:  661ms
созд. / загр.: 661ms
x
x
Закрыть


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