|
|
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
hi all WI-T3.0.0.30802 Дано: пустая база, FW = OFF, в ней запускается скрипт: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. По его окончании смотрю на размер файла базы: Код: plaintext 1. 2. Умножая 20 байт на 10 млн, получаем размер примерно 200 млн байт. Делаю 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. - и вижу, что: 1) средняя длина записи превышает длину int-типа более чем в два раза; 2) среднее заполнение записи всего 52%. ВОПРОСЫ. 1. Average record length - оно включает в себя заголовок (вроде как 16 байт в "неупакованном" виде) ? 2. Если на предыдущий вопрос ответ "да", то average fill=52% можно объяснить арифметикой, но... всегда ли был такой запас ? Не покидает смутное сомнение, что раньше под запас оставлялось около 25%, а не половина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 02:28:11 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, IBAnalyst Help Дополнительные вопросы и ответы 3. Почему фрагментированные таблицы появляются после restore? В некоторых случаях видны "фрагментированные таблицы" сразу после restore. Обычно IB/FB при restore (без параметра -use_all_space) резервирует примерно 25% на страницах данных для будущих вставок, обновлений или удалений (для размещения версий записей). Но, при любом размере страницы вы всегда будете видеть среднее заполнение в 50% для тех таблиц, у которых размер записи составляет 12-20 байт. Например, таблица с двумя столбцами int имеет средний размер записи 12 байт. Если вы наблюдаете такую картину, то считайте ее просто "магическим" числом. Добавлю, что когда я спросил об этом феномене разработчиков FB, то сказали, что "увы, так работает заполнение страниц данными". (где-то в DPM) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 02:39:20 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
kdv> Добавлю, что когда я спросил об этом феномене разработчиков FB, то сказали, kdv> что "увы, так работает заполнение страниц данными". (где-то в DPM) Практической ценности в этом, конечно, нет, но вообще ответ удивителен. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 03:18:08 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, я сократил "ответ разработчиков", потому что вопрос задавался лет пять назад как минимум. Насколько я смог вспомнить, проблема в определении свободного места на странице, там что-то с алгоритмом, в результате возникает такой "магический эффект". Менять смысла нет, т.к. на практике или таких "мелких" таблиц не бывает, или потеря места на такой таблице несущественна по сравнению с остальным. Ну или, изменение может привести к неожиданным последствиям. Как-то так. p.s. разумеется, это "историческое наследие самизнаетекого", так работают все версии IB и FB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 03:28:03 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
невольно вспоминается хотелка про счётчик метаданных 7865997 : NickDeeпрошу рассмотреть увеличение максимального значения счётчика изменения метаданных таблицы с 255 до 65535 и ответ dimitr: dimitrэто увеличит каждую запись на один байт. Для кого-то это может превратиться в гигабайт абсолютно ненужных ему данных. Кроме того, есть опасение, что любителям изменять метаданные на лету и предела в 64К скоро не хватит. Думаю, эту проблему надо решать другим способом. В свете открывшихся обстоятельств может это и не так критично (+1 байт к записи) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 03:43:38 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
NickDee, покажи в своих базах хоть одну таблицу, в статистике которой видно вот это самое 50% заполнение страниц? А увеличением счетчика метаданных на 1 байт ты гарантированно увеличишь КАЖДУЮ запись и версию на этот самый 1 байт. Можешь посчитать разницу. Та же самая фигня, только хуже, с номером транзакции, который 4 байта. В ФБ 3.0 его делают беззнаковым, что увеличивает его предел в 2 раза. Уже плюс тем системам, где Next transaction зашкаливает за 2 миллиарда сейчас месяца за два-три. А от счетчика метаданных в 1 байт сейчас страдают только системы, в которых пользователям разрешено добавлять и менять столбцы. Ну а такие пользователи обычно b/r не делают. Собственно, основной вопрос в скорости исчерпания лимитов. Например, лимит в 36.7 гиг на 1 таблицу починили вовремя. С лимитом Next transaction подзатянули. Ну а про лимит счетчика метаданных практически никто и не жалуется (за исключением единичных случаев). Хотя, можно было бы устроить голосование :-) p.s. а вот лимит длины имен FK (и вообще объектов) можно было бы уже несколько раз исправить. В InterBase его исправили 11 лет назад. Причем этот лимит, по идее, устраняется достаточно прозрачно, и не увеличивает объемы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 03:58:25 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
NickDee> В свете открывшихся обстоятельств может это и не так критично (+1 байт к записи) :) Во-первых, это не связанные вещи. Совсем. Во-вторых, как мне представляется, дело не [только] в увеличении записи, сколько, опять же, в малой практической ценности этого - загляни в свои БД и посмотри какой в них счётчик изменения таблиц. И нам доложи. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 04:26:31 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
kdvТа же самая фигня, только хуже, с номером транзакции, который 4 байта. В ФБ 3.0 его делают беззнаковым, что увеличивает его предел в 2 раза. Эффективней знаковый бит сделать флагом. 0 - размер 31 бит. 1 - 63 бита. Тогда можно забыть о проблеме переполнения лет на сто :) И при этом не потерять в эффективности расхода памяти. Жалко что счётчик метаданных не 7 бит, а то с ним можно было бы поступить так же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 05:05:10 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
kdvА увеличением счетчика метаданных на 1 байт ты гарантированно увеличишь КАЖДУЮ запись и версию на этот самый 1 байт. Ведь там вроде выравнивание есть. Где-то будет 0, где-то +граница выравнивания. Но в среднем по миру это будет +1 байт :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 05:09:21 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустамзагляни в свои БД и посмотри какой в них счётчик изменения таблиц. И нам доложи. К той БД о которой я писал 4 года назад, в которой в главной таблице >400полей, у меня доступа нет. Они теперь сами по себе живут уже около года... Но там есть при старте проверка на счётчик > 127. И тогда происходит b/r. Какой там сейчас размер БД и какое значение счётчика - я тоже не знаю, но размер не меньше 500мб. А b/r должен пройти сразу на большом количестве второстепенных серверов. В последний раз их было около 40. Короче вот :) Если b/r поломается, то будет упс... Спасает что бд не очень большая, минут за 10 b/r пройдёт. Но на будущее было бы хорошо иметь возможность не делать его по такому поводу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 05:32:02 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
При чём тут размер БД и количество серверов? Почему постоянно редактируется структура этой злосчастной таблицы? И даже если ограничение было бы не 127, а 65500 - как раз ты его всё равно исчерпал бы, в отличие от нормальных людей. Про 400 полей уже даже не спрашиваю. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 05:54:47 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид1) средняя длина записи превышает длину int-типа более чем в два раза; ибо есть еще NULL-маска, про которую ты забыл. Average unpacked length: 8.00, это 4 байта на маску + 4 байта на поле. Маска сожмется до двух байт, а поле - как получится. Таблоид1. Average record length - оно включает в себя заголовок (вроде как 16 байт в "неупакованном" виде) ? заголовок (13 байт) никогда не сжимается, так что в average record length входить не может Таблоидраньше под запас оставлялось около 25%, а не половина. 25% это мифическое число. На каждую запись резервируется около 20 байт. Так что какая будет фрагментация - 50% или 5%, зависит исключительно от длины записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 09:09:12 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
kdvДобавлю, что когда я спросил об этом феномене разработчиков FB, то сказали, что "увы, так работает заполнение страниц данными". (где-то в DPM)А мой склероз утверждает, что я тебе полностью рассказал что, как и почему. И после этого ты поправил свой рассчёт в аналисте. PS до каких пор фрагментацией называть будем то, что к ней совершенно не относится ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 12:06:24 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
hvladА мой склероз утверждает, что я тебе полностью рассказал что, как и почему. И после этого ты поправил свой рассчёт в аналисте. знаешь, я помню что поправил вывод предупреждения о заполнении страницы всего на 50%, сообразуясь с размером записи. А вот как и почему - не запомнил. И если я рассказал (или недорассказал) неправильно, сейчас был бы очень хороший момент меня поправить. hvladдо каких пор фрагментацией называть будем то, что к ней совершенно не относится ? Да, это не фрагментация, это заполнение. поменяю. dimitrНа каждую запись резервируется около 20 байт. Так что какая будет фрагментация - 50% или 5%, зависит исключительно от длины записи. наука (gstat -r) утверждает, что мелкие записи (до 23 байт, без заголовка), ведут себя именно таким образом - страницы "недозаполняются" на 25%, в отличие от остальных длин записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 12:23:28 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrНа каждую запись резервируется около 20 байт.Это минимум или кол-во байт резерва зависит еще от чего-то ? (числа полей, их типа ?) Непонятно всё равно, как получились 514 млн байтов. 13 = несжимаемый заголовок 2 = сжатая маска 4 = несжимаемое (представим худший случай) integer-число - например, 2^31-1, там все 4 байта заняты 20 = несжимаемый резерв для каждой записи Итого получаем: (13+2+4+20)*10000000 = 390 000 000 Дифферент равен 514 306 048 - 390 000 000 = 124 306 048 байт. На что потрачены 100 мегов ? Что-то пухло всё и рыхло как-то! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 15:38:39 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЭто минимум или кол-во байт резерва зависит еще от чего-то ? (числа полей, их типа ?) ни от чего не зависит Таблоид2 = сжатая маска 4 = несжимаемое (представим худший случай) integer-число - например, 2^31-1, там все 4 байта заняты не надо что-то там предполагать, gstat тебе четко пишет среднюю длину записи = 9 байт, ее и учитывай ТаблоидИтого получаем: (13+2+4+20)*10000000 = 390 000 000 Дифферент равен 514 306 048 - 390 000 000 = 124 306 048 байт. На что потрачены 100 мегов ? Что-то пухло всё и рыхло как-то! во-первых, реальный размер данных = 123457 страниц = 505МБ во-вторых, (17 + 9 + 20) * 10000000 = 460МБ (правильнее считать оверхед на запись равной 17 байт = 13 байт заголовок записи + 4 байта дескриптор слота на странице данных) Осталось найти, что еще я забыл посчитать :-) Но дифферент уже далеко не 100 метров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 15:52:36 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, Делаю далеко не первый, но последний раз. Следи за руками: Для таблицы с одним полем INT: Сжимаемое Данные записи - 4 байта Маска нуллов - 4 байт Не сжимаемое Заголовок записи - 13 байт Указатель в слоте - 2 байта Размер записи (в слоте) - 2 байта Резерв (заголовок фрагментированной записи) - 22 байта Получаем сжимаемое - 2..9 байт не сжимаемое - 17 байт вместе 19..26 байт из-за выравнивания на границу 4 - 20..28 байт Добавим резерв, получим 42..50 байт на запись. Умножай на 10млн сам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 18:07:08 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
hvladДобавим резерв, получим 42..50 байт на запись 2 dimitr & hvlad: занёс в мемориз. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 18:18:47 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов РустамПри чём тут размер БД и количество серверов? Почему постоянно редактируется структура этой злосчастной таблицы? И даже если ограничение было бы не 127, а 65500 - как раз ты его всё равно исчерпал бы, в отличие от нормальных людей. Про 400 полей уже даже не спрашиваю. Структура редактируется по необходимости. И уже не мной. Как часто - не моё дело. Не вижу проблем в том, чтобы люди хотели иметь много свойств у одной сущности. Люди - техничекие инженеры, там много свойств может быть. И не нам их ограничивать, в их полёте инженерной мысли :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 19:34:44 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
NickDeeневольно вспоминается хотелка про счётчик метаданныхГаджимурадов Рустамты его всё равно исчерпал бы, в отличие от нормальных людей.NickDeeЛюди - техничекие инженеры. . . И не нам их ограничивать, в их полёте инженерной мысли :)да блин!.. вы опять сцепились в экстазном оффтопе... это уже становится доброй традицией, что ли ? NickDee! это с тебя всякий раз начинается! У тебя кнопка "Новая тема" - она вообще видна или нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 20:01:08 |
|
||
|
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидNickDeeневольно вспоминается хотелка про счётчик метаданныхГаджимурадов Рустамты его всё равно исчерпал бы, в отличие от нормальных людей.NickDeeЛюди - техничекие инженеры. . . И не нам их ограничивать, в их полёте инженерной мысли :)да блин!.. вы опять сцепились в экстазном оффтопе... это уже становится доброй традицией, что ли ? NickDee! это с тебя всякий раз начинается! У тебя кнопка "Новая тема" - она вообще видна или нет ? У тебя свои традиции - у нас свои :) Но в итоге вроде получается конструктивно :) Но если это тебя прям так раздражает - я готов уважать твоё раздражение, и создавать отдельные темы :) Вроде это не сложно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2013, 20:29:00 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38508666&tid=1564040]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
229ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 571ms |

| 0 / 0 |
