powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
25 сообщений из 189, страница 2 из 8
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033353
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКак хотя бы примерно оценить размер этой PP ?Ты не знаешь р-р страницы ? :)
Кол-во PP можно узнать, зная кол-во DP и р-р страницы:

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

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

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

ТаблоидУже несколько дней всё порываюсь спросить, да всё как-то стеснялся...
isql включает статистику препаре, трейс видимо нет. Или ты опять не туда смотришь. Мне уже надоедает повторять одно и то же.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 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
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033394
Фотография 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
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033399
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ?Раздели 201 на 30000 и сравни с avg seek time своего диска. Вряд ли оно меньше или даже сравнимо с 7 мс...
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033401
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PEAKTOPMON$ATTACHMENTS становиться немного не в курсе последних событий.Не, погодь! У мну как раз mon$ attachments работает как часы, в т.ч. и на этой таблице: срубает заработавшиеся коннекты только так. А вот mon$ statements срубает работающие стейтменты не всегда, а только при mon$state = 1 (см. первый пост)
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033402
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrМне уже надоедает повторять одно и то же.А меня это как достало :'(
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033403
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидИнтересует другое: зачем при каждом прераре, невзирая на характер sql-запроса , перечитываются все 30 тыс PP той таблицы, которая в нём упомянута ?Спроси того, кто писал оптимизатор.
В 3-ке это планируется переделать.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 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
Его Величество Миллиард (эксперименты с таблицей в 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
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033475
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЯ так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments .
естественно. Во-первых, откат изменений прерывать не всегда можно, это чревато. Во-вторых, удаление аттача - это для начала тот же самый откат изменений, так что ты в принципе не можешь увидеть никакого эффекта.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033477
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladВ 3-ке это планируется переделать.
именно это (зависимость от характера запроса) у меня нет никакого желания менять. А вот избежать полного скана PP можно будет, наверное.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033478
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PEAKTOPЯ к чему это все: основная задумка использования MON$ATTACHMENTS была в том, чтобы правоверно и строго по Корану срубить коннект, который че-то не так делает (ну, там запросы кривые, или просто базу вешает). А если оно так сильно от дисков зависит, то смысл в нем ?
я не вижу никаких доказательств, что где-то что-то критично (а не просто сильно) зависит от дисков. Случай "разбитого" рейда не учитываем, это форс-мажор.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033488
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrоткат изменений прерывать не всегда можно, это чревато.А если FW=ON - тоже чревато ?
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033491
Фотография arni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrНо отмечу, что эти 30 тыс равномерно размазаны по 118ГБ.Правильно ли я понимаю, что после b/r фрагментация PP едва ли уменьшится, т.к. очередная PP рождается на каждые n DP в момент заливки, а не вся пачка сразу на таблицу?
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033495
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
arni,

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

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

в общем, как обычно, ты преувеличиваешь серьезность проблемы. Ну и единственное возможное в 2.5 решение тоже имеет свои недостатки.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033547
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrбольшинство из них будет кешировано сервером или осью после первого обращения
Насколько я понимаю это верно для систем с постоянным коннектом. Если же коннект постоянно уничтожается и создаётся заново, то для классика кэш придётся заполнять заново. В частности это будет происходить при использовании PHP. Пока что единственный способ этого избежать использовать пул коннектов.
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033553
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЕсли же коннект постоянно уничтожается и создаётся заново
на каждый запрос? Если да, то оно встанет раком в любом случае. Если нет, то кеш сыграет свою роль. Ну и кроме того, кеш оси будет помогать (если база многопользовательская).
...
Рейтинг: 0 / 0
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38033557
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не на каждый запрос конечно. В случае веб страницы на каждую страницу. Впрочем как я уже сказал там можно применить пул коннектов, ну или использовать суперсервер.
...
Рейтинг: 0 / 0
25 сообщений из 189, страница 2 из 8
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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