powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
21 сообщений из 21, страница 1 из 1
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508613
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

WI-T3.0.0.30802

Дано: пустая база, FW = OFF, в ней запускается скрипт:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
recreate sequence g; commit;
recreate table t( f01 int ); commit;
set term ^;
execute block as
declare n int = 10000000; 
begin
while(n>0) do insert into t(f01) values( mod( gen_id(g,1), 2) ) returning :n-1 into n;
end^ 
set term ;^ 
commit;

По его окончании смотрю на размер файла базы:
Код: plaintext
1.
2.
G:\1INSTALL\FIREBIRD\FB30>dir zero.fdb|findstr /i /c:zero.fdb
21.12.2013  02:03          514 306 048  ZERO.FDB
Размер кажется каким-то дюже огромным для 10 млн int-чисел: каждое по 4 байта + ~16 байт на заголовок записи.
Умножая 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.
Database "G:\1INSTALL\FIREBIRD\FB30\ZERO.FDB"
Database header page information:
 
head info Flags 0 Generation 40 System Change Number 0 Page size 4096 ODS version 12.0 Oldest transaction 33 Oldest active 34 Oldest snapshot 34 Next transaction 35 Sequence number 0 Next attachment ID 12 Implementation HW=Intel/i386 little-endian OS=Windows CC=MSVC Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Dec 21, 2013 1:52:55 Attributes Variable header data: *END* Database file sequence: File G:\1INSTALL\FIREBIRD\FB30\ZERO.FDB is the only file
Analyzing database pages ... T (129) Primary pointer page: 12575, Index root page: 12576 Total formats: 1, used formats: 1 Average record length: 9.00, total records: 10000000 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: 8.00, compression ratio: 0.89 Pointer pages: 137, data page slots: 123457 Data pages: 123457, average fill: 52% Primary pages: 123457, full pages: 123456, swept pages: 0 Fill distribution: 0 - 19% = 0 20 - 39% = 0 40 - 59% = 123457 60 - 79% = 0 80 - 99% = 0

- и вижу, что:
1) средняя длина записи превышает длину int-типа более чем в два раза;
2) среднее заполнение записи всего 52%.

ВОПРОСЫ.
1. Average record length - оно включает в себя заголовок (вроде как 16 байт в "неупакованном" виде) ?
2. Если на предыдущий вопрос ответ "да", то average fill=52% можно объяснить арифметикой, но... всегда ли был такой запас ? Не покидает смутное сомнение, что раньше под запас оставлялось около 25%, а не половина.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508616
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

IBAnalyst Help
Дополнительные вопросы и ответы

3. Почему фрагментированные таблицы появляются после restore?
В некоторых случаях видны "фрагментированные таблицы" сразу после restore. Обычно IB/FB при restore (без параметра -use_all_space) резервирует примерно 25% на страницах данных для будущих вставок, обновлений или удалений (для размещения версий записей). Но, при любом размере страницы вы всегда будете видеть среднее заполнение в 50% для тех таблиц, у которых размер записи составляет 12-20 байт. Например, таблица с двумя столбцами int имеет средний размер записи 12 байт. Если вы наблюдаете такую картину, то считайте ее просто "магическим" числом.


Добавлю, что когда я спросил об этом феномене разработчиков FB, то сказали, что "увы, так работает заполнение страниц данными". (где-то в DPM)
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508628
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv> Добавлю, что когда я спросил об этом феномене разработчиков FB, то сказали,
kdv> что "увы, так работает заполнение страниц данными". (где-то в DPM)

Практической ценности в этом, конечно, нет, но вообще ответ удивителен.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508632
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

я сократил "ответ разработчиков", потому что вопрос задавался лет пять назад как минимум.
Насколько я смог вспомнить, проблема в определении свободного места на странице, там что-то с алгоритмом, в результате возникает такой "магический эффект". Менять смысла нет, т.к. на практике или таких "мелких" таблиц не бывает, или потеря места на такой таблице несущественна по сравнению с остальным. Ну или, изменение может привести к неожиданным последствиям.
Как-то так.

p.s. разумеется, это "историческое наследие самизнаетекого", так работают все версии IB и FB.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508635
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
невольно вспоминается хотелка про счётчик метаданных 7865997 :
NickDeeпрошу рассмотреть увеличение максимального значения счётчика изменения метаданных таблицы с 255 до 65535
и ответ dimitr:
dimitrэто увеличит каждую запись на один байт. Для кого-то это может превратиться в гигабайт абсолютно ненужных ему данных. Кроме того, есть опасение, что любителям изменять метаданные на лету и предела в 64К скоро не хватит. Думаю, эту проблему надо решать другим способом.
В свете открывшихся обстоятельств может это и не так критично (+1 байт к записи) :)
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508640
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee,

покажи в своих базах хоть одну таблицу, в статистике которой видно вот это самое 50% заполнение страниц?
А увеличением счетчика метаданных на 1 байт ты гарантированно увеличишь КАЖДУЮ запись и версию на этот самый 1 байт. Можешь посчитать разницу.

Та же самая фигня, только хуже, с номером транзакции, который 4 байта. В ФБ 3.0 его делают беззнаковым, что увеличивает его предел в 2 раза. Уже плюс тем системам, где Next transaction зашкаливает за 2 миллиарда сейчас месяца за два-три.

А от счетчика метаданных в 1 байт сейчас страдают только системы, в которых пользователям разрешено добавлять и менять столбцы. Ну а такие пользователи обычно b/r не делают.

Собственно, основной вопрос в скорости исчерпания лимитов. Например, лимит в 36.7 гиг на 1 таблицу починили вовремя. С лимитом Next transaction подзатянули. Ну а про лимит счетчика метаданных практически никто и не жалуется (за исключением единичных случаев). Хотя, можно было бы устроить голосование :-)

p.s. а вот лимит длины имен FK (и вообще объектов) можно было бы уже несколько раз исправить. В InterBase его исправили 11 лет назад. Причем этот лимит, по идее, устраняется достаточно прозрачно, и не увеличивает объемы данных.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508646
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDee> В свете открывшихся обстоятельств может это и не так критично (+1 байт к записи) :)

Во-первых, это не связанные вещи. Совсем.
Во-вторых, как мне представляется, дело не
[только] в увеличении записи, сколько, опять
же, в малой практической ценности этого -
загляни в свои БД и посмотри какой в них
счётчик изменения таблиц. И нам доложи.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508649
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvТа же самая фигня, только хуже, с номером транзакции, который 4 байта. В ФБ 3.0 его делают беззнаковым, что увеличивает его предел в 2 раза.
Эффективней знаковый бит сделать флагом. 0 - размер 31 бит. 1 - 63 бита. Тогда можно забыть о проблеме переполнения лет на сто :) И при этом не потерять в эффективности расхода памяти. Жалко что счётчик метаданных не 7 бит, а то с ним можно было бы поступить так же...
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508650
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvА увеличением счетчика метаданных на 1 байт ты гарантированно увеличишь КАЖДУЮ запись и версию на этот самый 1 байт.
Ведь там вроде выравнивание есть. Где-то будет 0, где-то +граница выравнивания. Но в среднем по миру это будет +1 байт :)
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508651
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустамзагляни в свои БД и посмотри какой в них
счётчик изменения таблиц. И нам доложи.
К той БД о которой я писал 4 года назад, в которой в главной таблице >400полей, у меня доступа нет. Они теперь сами по себе живут уже около года...
Но там есть при старте проверка на счётчик > 127. И тогда происходит b/r. Какой там сейчас размер БД и какое значение счётчика - я тоже не знаю, но размер не меньше 500мб. А b/r должен пройти сразу на большом количестве второстепенных серверов. В последний раз их было около 40. Короче вот :) Если b/r поломается, то будет упс... Спасает что бд не очень большая, минут за 10 b/r пройдёт. Но на будущее было бы хорошо иметь возможность не делать его по такому поводу :)
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508653
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При чём тут размер БД и количество серверов?
Почему постоянно редактируется структура этой
злосчастной таблицы? И даже если ограничение
было бы не 127, а 65500 - как раз ты его всё равно
исчерпал бы, в отличие от нормальных людей.

Про 400 полей уже даже не спрашиваю.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508666
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид1) средняя длина записи превышает длину int-типа более чем в два раза;
ибо есть еще NULL-маска, про которую ты забыл. Average unpacked length: 8.00, это 4 байта на маску + 4 байта на поле. Маска сожмется до двух байт, а поле - как получится.

Таблоид1. Average record length - оно включает в себя заголовок (вроде как 16 байт в "неупакованном" виде) ?
заголовок (13 байт) никогда не сжимается, так что в average record length входить не может

Таблоидраньше под запас оставлялось около 25%, а не половина.
25% это мифическое число. На каждую запись резервируется около 20 байт. Так что какая будет фрагментация - 50% или 5%, зависит исключительно от длины записи.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508727
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvДобавлю, что когда я спросил об этом феномене разработчиков FB, то сказали, что "увы, так работает заполнение страниц данными". (где-то в DPM)А мой склероз утверждает, что я тебе полностью рассказал что, как и почему. И после этого ты поправил свой рассчёт в аналисте.

PS до каких пор фрагментацией называть будем то, что к ней совершенно не относится ?
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508737
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladА мой склероз утверждает, что я тебе полностью рассказал что, как и почему. И после этого ты поправил свой рассчёт в аналисте.

знаешь, я помню что поправил вывод предупреждения о заполнении страницы всего на 50%, сообразуясь с размером записи.
А вот как и почему - не запомнил. И если я рассказал (или недорассказал) неправильно, сейчас был бы очень хороший момент меня поправить.

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

dimitrНа каждую запись резервируется около 20 байт. Так что какая будет фрагментация - 50% или 5%, зависит исключительно от длины записи.
наука (gstat -r) утверждает, что мелкие записи (до 23 байт, без заголовка), ведут себя именно таким образом - страницы "недозаполняются" на 25%, в отличие от остальных длин записей.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508833
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 мегов ? Что-то пухло всё и рыхло как-то!
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508847
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЭто минимум или кол-во байт резерва зависит еще от чего-то ? (числа полей, их типа ?)
ни от чего не зависит

Таблоид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 метров.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508892
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

Делаю далеко не первый, но последний раз. Следи за руками:

Для таблицы с одним полем INT:

Сжимаемое
Данные записи - 4 байта
Маска нуллов - 4 байт

Не сжимаемое
Заголовок записи - 13 байт
Указатель в слоте - 2 байта
Размер записи (в слоте) - 2 байта
Резерв (заголовок фрагментированной записи) - 22 байта

Получаем
сжимаемое - 2..9 байт
не сжимаемое - 17 байт
вместе 19..26 байт
из-за выравнивания на границу 4 - 20..28 байт

Добавим резерв, получим 42..50 байт на запись.

Умножай на 10млн сам
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508895
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladДобавим резерв, получим 42..50 байт на запись 2 dimitr & hvlad: занёс в мемориз. Спасибо.
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508927
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамПри чём тут размер БД и количество серверов?
Почему постоянно редактируется структура этой
злосчастной таблицы? И даже если ограничение
было бы не 127, а 65500 - как раз ты его всё равно
исчерпал бы, в отличие от нормальных людей.

Про 400 полей уже даже не спрашиваю.

Структура редактируется по необходимости. И уже не мной. Как часто - не моё дело.
Не вижу проблем в том, чтобы люди хотели иметь много свойств у одной сущности. Люди - техничекие инженеры, там много свойств может быть. И не нам их ограничивать, в их полёте инженерной мысли :)
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508940
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NickDeeневольно вспоминается хотелка про счётчик метаданныхГаджимурадов Рустамты его всё равно исчерпал бы, в отличие от нормальных людей.NickDeeЛюди - техничекие инженеры. . . И не нам их ограничивать, в их полёте инженерной мысли :)да блин!.. вы опять сцепились в экстазном оффтопе...
это уже становится доброй традицией, что ли ?

NickDee! это с тебя всякий раз начинается! У тебя кнопка "Новая тема" - она вообще видна или нет ?
...
Рейтинг: 0 / 0
WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
    #38508953
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидNickDeeневольно вспоминается хотелка про счётчик метаданныхГаджимурадов Рустамты его всё равно исчерпал бы, в отличие от нормальных людей.NickDeeЛюди - техничекие инженеры. . . И не нам их ограничивать, в их полёте инженерной мысли :)да блин!.. вы опять сцепились в экстазном оффтопе...
это уже становится доброй традицией, что ли ?

NickDee! это с тебя всякий раз начинается! У тебя кнопка "Новая тема" - она вообще видна или нет ?
У тебя свои традиции - у нас свои :)
Но в итоге вроде получается конструктивно :)
Но если это тебя прям так раздражает - я готов уважать твоё раздражение, и создавать отдельные темы :) Вроде это не сложно...
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / WI-T3.0.0.30802: 10 млн int-чисел занимают 514 млн бай, avg fill = 52%. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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