|
|
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидКак хотя бы примерно оценить размер этой PP ?Ты не знаешь р-р страницы ? :) Кол-во PP можно узнать, зная кол-во DP и р-р страницы: cntPP ~ cntDP / ((pageSize - 16) / 5) В твоём случае 28567997 / (4080 / 5) = 35010 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:12:56 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
hvladcntPP ~ cntDP / ((pageSize - 16) / 5) В твоём случае 28567997 / (4080 / 5) = 35010Промахнулся немного. Правильнее будет cntPP ~ cntDP / ((pageSize - 16) * 8 / 34), и 28567997 / (4080 *8 / 34) = 29759 (как и сказал dimitr) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:17:22 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
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. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:42:20 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ? Даже если они там "размазаны" внутри базы, их смещения от начала .fdb - они известны или нет ? все смещения, разумеется, известны. А в целом это вопрос исключительно к твоей дисковой (и, возможно, файловому кешу). Не все меряется байтами. Перемещение головки (особенно сильно далеко) - намного медленнее, чем чтение страницы. ТаблоидУже несколько дней всё порываюсь спросить, да всё как-то стеснялся... isql включает статистику препаре, трейс видимо нет. Или ты опять не туда смотришь. Мне уже надоедает повторять одно и то же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 00:50:00 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrisql включает статистику препаре, трейс видимо нет.Это понятно. Интересует другое: зачем при каждом прераре, невзирая на характер sql-запроса , перечитываются все 30 тыс PP той таблицы, которая в нём упомянута ? Вот, например, здесь даже таблица не нужна, не то что индекс, - а всё равно будут перекопаны "все грядки": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:00:17 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидВыключил использование кеша операционки (поставил 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 ненужного процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:01:23 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидНу, и ?! 30 тыс страниц, по 4 Кб каждая, читаются 201 секунду. Это как объяснить-то ?Раздели 201 на 30000 и сравни с avg seek time своего диска. Вряд ли оно меньше или даже сравнимо с 7 мс... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:06:39 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
PEAKTOPMON$ATTACHMENTS становиться немного не в курсе последних событий.Не, погодь! У мну как раз mon$ attachments работает как часы, в т.ч. и на этой таблице: срубает заработавшиеся коннекты только так. А вот mon$ statements срубает работающие стейтменты не всегда, а только при mon$state = 1 (см. первый пост) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:07:32 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrМне уже надоедает повторять одно и то же.А меня это как достало :'( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:07:33 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидИнтересует другое: зачем при каждом прераре, невзирая на характер sql-запроса , перечитываются все 30 тыс PP той таблицы, которая в нём упомянута ?Спроси того, кто писал оптимизатор. В 3-ке это планируется переделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:08:53 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
hvladРаздели 201 на 30000 и сравни с avg seek time своего диска. Вряд ли оно меньше или даже сравнимо с 7 мс...Еще бы понять, чем мерять это avg seek time... :-/ lshw показывает, что у нас в этом серваке установлен IBM ServeRAID M5015. Кто-нить в курсе, какие у него ТТХ ? ЗЫ. А встроенная мерялка скорости чтения с диска показывает какую-то очень уж оптимистичную картину: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:30:04 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
Таблоид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. Я так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments . Пока набирал этот текст, число коннектов стало меньше на 26, но на команду удаления они (оставшиеся) всё равно не реагируют: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 01:40:44 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЯ так понимаю, пока ФБ делает откаты изменений, произведённых этими окнами, "светлые образы" их коннектов всё равно торчат в mon$ attachments . естественно. Во-первых, откат изменений прерывать не всегда можно, это чревато. Во-вторых, удаление аттача - это для начала тот же самый откат изменений, так что ты в принципе не можешь увидеть никакого эффекта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 10:44:27 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
hvladВ 3-ке это планируется переделать. именно это (зависимость от характера запроса) у меня нет никакого желания менять. А вот избежать полного скана PP можно будет, наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 10:47:16 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
PEAKTOPЯ к чему это все: основная задумка использования MON$ATTACHMENTS была в том, чтобы правоверно и строго по Корану срубить коннект, который че-то не так делает (ну, там запросы кривые, или просто базу вешает). А если оно так сильно от дисков зависит, то смысл в нем ? я не вижу никаких доказательств, что где-то что-то критично (а не просто сильно) зависит от дисков. Случай "разбитого" рейда не учитываем, это форс-мажор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 10:49:08 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrоткат изменений прерывать не всегда можно, это чревато.А если FW=ON - тоже чревато ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 11:09:09 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrНо отмечу, что эти 30 тыс равномерно размазаны по 118ГБ.Правильно ли я понимаю, что после b/r фрагментация PP едва ли уменьшится, т.к. очередная PP рождается на каждые n DP в момент заливки, а не вся пачка сразу на таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 11:10:20 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
arni, правильно, ибо размера таблицы никто не знает. Можно попробовать выделять некоторыми фиксированными пачками, мы это обсуждали. Но именно проблема препаре решается и другими способами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 11:18:02 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
ТаблоидА если FW=ON - тоже чревато ? могу тебе в стопицотый раз сказать, что никто не будет менять поведение сервера относительно настройки FW ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 11:20:11 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrhvladВ 3-ке это планируется переделать. именно это (зависимость от характера запроса) у меня нет никакого желания менять. А вот избежать полного скана PP можно будет, наверноеЯ именно это имел в виду, просто в неудачном месте ответил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 11:58:58 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrА вот избежать полного скана PP можно будет, наверноеА это в 2.5.x можно как-то вкрячить ? или только трёшку ждать ? Я к тому, что таблицы в 1 млрд записей сейчас может и редки, но вот 10-20 таблиц по 50-100 млн строк запросто могут быть в системах, которые работают 5 лет и больше. И запрос, в котором упомянуты 3-4 такие таблицы, будет при каждом prepare будет сканировать эти самые PP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 12:06:47 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
Таблоид, 1) 100 млн строк - это 3000 маленьких страниц или 1500 средних или 750 больших, т.е. время их чтения будет 20 сек в худшем случае и 5 сек в лучшем 2) большинство из них будет кешировано сервером или осью после первого обращения в общем, как обычно, ты преувеличиваешь серьезность проблемы. Ну и единственное возможное в 2.5 решение тоже имеет свои недостатки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 12:45:52 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
dimitrбольшинство из них будет кешировано сервером или осью после первого обращения Насколько я понимаю это верно для систем с постоянным коннектом. Если же коннект постоянно уничтожается и создаётся заново, то для классика кэш придётся заполнять заново. В частности это будет происходить при использовании PHP. Пока что единственный способ этого избежать использовать пул коннектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 13:04:19 |
|
||
|
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЕсли же коннект постоянно уничтожается и создаётся заново на каждый запрос? Если да, то оно встанет раком в любом случае. Если нет, то кеш сыграет свою роль. Ну и кроме того, кеш оси будет помогать (если база многопользовательская). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2012, 13:15:52 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38033390&tid=1564260]: |
0ms |
get settings: |
10ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
229ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
87ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 606ms |

| 0 / 0 |
