iBase.ru Forum

Есть такая статистика по таблице:

CONN (130)
    Primary pointer page: 155, Index root page: 156
    Average record length: 25.36, total records: 127993974
    Average version length: 58.92, total versions: 928418, max versions: 1
    Data pages: 2462138, data page slots: 2462138, average fill: 12%
    Fill distribution:
         0 - 19% = 762
        20 - 39% = 2
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 2461374

Почему, если большинство записей лежит в области 80-99%, average fill равен 12%?

Блобы есть ?

ibanalyst скачай, и посмотри на avg fill и real fill.
www.ibase.ru/download/ibanalyst_r.zip

вообще я с таким сталкивался вроде бы один раз, когда статистика (gstat, serv api) в этом смысле явно врала не в свою пользу. Обычно avg fill показывается больше, чем может быть на самом деле.

hvlad писал(а):Блобы есть ?

Нет:

Код: Выделить всё

create domain dur as integer not null;
create domain datetime as timestamp not null;
create domain amafile_id as integer not null;
create domain tgrp as char(6);
create domain lno as integer;
create domain cause integer default 16 not null;

create table conn (
  amafile_id	amafile_id,
  datetime	datetime,
  anum		conn_num,
  bnum		conn_num,
  dur		dur,
  itgrp		tgrp,
  ilno		lno,
  otgrp		tgrp,
  olno		lno,
  cause		cause
);

версия сервера какая? в любом случае - хочешь узнать правду, смотри в IBAnalyst

kdv писал(а):версия сервера какая?

FB 1.5.2, Win32

kdv писал(а):в любом случае - хочешь узнать правду, смотри в IBAnalyst

Я так и понял.

Тут с этими страницами, оказывается, не всё так просто, как я думал.

Обновлённая статистика (после backup/restore):

Код: Выделить всё

Database header page information:
	Flags			0
	Checksum		12345
	Generation		38
	Page size		8192
	ODS version		10.1
	Oldest transaction	28
	Oldest active		29
	Oldest snapshot		29
	Next transaction	30
	Bumped transaction	1
	Sequence number		0
	Next attachment ID	0
	Implementation ID	16
	Shadow count		0
	Page buffers		20480
	Next header page	0
	Database dialect	3
	Creation date		May 16, 2005 14:05:13
	Attributes		no reserve

no reserve - потому, что по базе никогда не делается update - только delete <устаревшие данные> и insert <новенькое>. (Или может не стоило экономить? Хотя 20% - это всё-таки 2 лишних Гига...)

Теперь статистика по таблице CONN (она самая большая и занимает большую часть БД):

Код: Выделить всё

CONN (130)
    Primary pointer page: 138, Index root page: 139
    Average record length: 25.92, total records: 127461506
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1223251, data page slots: 1223251, average fill: 12%
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 0
	40 - 59% = 1
	60 - 79% = 0
	80 - 99% = 1223250

Получается, что в результате упаковки (?) средняя длина записи равна 25.92. Помноженное на количество записей это даёт 3,3 Гб. Реально таблица занимает 1223251 страниц или 9556.65 Гб. Получается, что реально используется где-то треть от занятых страниц, однако IBAnalyst показывает AvgFill=12%, а RealFill=55%.
Если честно, от такого количества небьющихся между собой цифр у меня голова кругом пошла.

Во второй по величине таблице (~1.4 млн записей, 121 Мб) всё выглядит более ожидаемо: AvgFill=RealFill=98%.
Я так подозреваю, что это как-то связано с большим количеством записей с пустыми полями в таблице CONN, например, igtrp и ilno = NULL где-то в половине записей.
В общем, пошлите меня куда-нибудь, пожалуйста, ... почитать, чтобы мозги на место встали.

no reserve - потому, что по базе никогда не делается update - только delete <устаревшие данные> и insert <новенькое>. (Или может не стоило экономить? Хотя 20% - это всё-таки 2 лишних Гига...)

дело вкуса.

Получается, что в результате упаковки (?) средняя длина записи равна 25.92. Помноженное на количество записей это даёт 3,3 Гб. Реально таблица занимает 1223251 страниц или 9556.65 Гб. Получается, что реально используется где-то треть от занятых страниц, однако IBAnalyst показывает AvgFill=12%, а RealFill=55%.
Если честно, от такого количества небьющихся между собой цифр у меня голова кругом пошла.

по поводу объема данных см. Процент версий данных в IBAnalyst на первой странице.
1223251 * 8К получается 9.5 гигабайт, а не 9 тысяч гигабайт.
произведи обратную операцию - подели это число на кол-во записей.
Средний размер записи получится 76.8 байт. Почему статистика так врет - не знаю.
основными для тебя (и вообще) является число страниц, занятых таблицей, и число записей. Статистику, кстати, рекомендую взять как через services api, так и через gstat -a -r, и сравнить.

Я подозревал, что дело может быть в этом, но для верности полез в исходники FB и нашёл, что для хранения rel_recod_space (объём дискового пространства, занятого под записи) используется 32-битный ULONG, максимальное значение которого 2^32=4294967296 или 4 Гб. В моём случае размер таблицы более 9 гигабайт, поэтому эта переменная переполняется, и... Короче, к данным статистики для таблиц размером более 4 Гб, надо относиться весьма критически.

Andrew Sagulin писал(а):rel_recod_space (объём дискового пространства, занятого под записи) используется 32-битный ULONG

Похоже на правду, будем смотреть, спасибо

Исправлено. Просьба проверить в текущих снапшотах (build >= 2.0.0.12177)

PS Никто не забыт, ничто не забыто

iBase.ru Forum

Прошу пояснить статистику

Прошу пояснить статистику