Alokacija prostora u Firebird 2.1 i novijim verzijama

Vlad Khorsun, 20-OCT-2010

Од почетокот, Firebird немаше правила за тоа како да се распредели простор на дискот за датотеката(ите) на базата на податоци. Едноставно запишува нови алоцирани страници по неопределен редослед (поради зависностите помеѓу страниците за да се служи стратегијата „внимателно запишување“).

Овој пристап е многу едноставен, но има некои недостатоци:

• поради неопределениот редослед на запишување, може да се појави ситуација кога кешот на страници содржи многу „валкани“ страници во моментот кога треба да се запише ново алоцирана страница, но не може поради недостаток на простор на дискот. Во такви случаи, често сите други „валкани“ страници се губат бидејќи администраторите претпочитаат да ја исклучат базата на податоци пред да ослободат простор на дискот. Ова води до сериозни корупции.

• распределбата на просторот на дискот во релативно мали парчиња може да доведе до значителна фрагментација на датотеката на ниво на датотечен систем и да ја намали перформансата на големи скенирања (на пример, за време на резервна копија).

Користејќи го новиот ODS 11.1, Firebird го менува својот алгоритам за распределба на простор на дискот за да избегне корупции во услови на недостаток на простор на дискот и да му даде шанса на датотечниот систем да избегне фрагментација. Овие промени се опишани подолу.

а) Секоја ново алоцирана страница се запишува на дискот веднаш пред да се врати на моторот. Ако страницата не може да се запише, тогаш алоцирањето не се случува, PIP битот не се чисти и се подига соодветна I/O грешка. Оваа грешка не може да доведе до корупции бидејќи имаме гаранција дека сите „валкани“ страници во кешот имаат алоциран простор на дискот и можат безбедно да се запишат.

Оваа промена прави едно дополнително запишување на секоја ново алоцирана страница во споредба со старото однесување. Затоа се очекува намалување на перформансите за време на растот на датотеката на базата на податоци. За да се намали ова намалување, Firebird групира запишувања на ново алоцирани страници до 128KB одеднаш и го следи бројот на „иницијализирани“ страници во PIP заглавието.

Забелешка: ново алоцираната страница ќе биде запишана на дискот двапати само ако оваа страница е алоцирана прв пат. Односно, ако страницата била алоцирана, ослободена и повторно алоцирана, нема да биде запишана двапати при второто алоцирање.

б) За да се избегне фрагментација на датотеката, Firebird го користи соодветниот API на датотечниот систем за претходно алоцирање на простор на дискот во релативно големи парчиња. Во моментов, таков API постои само во Windows, но неодамна беше додаден во Linux API и може да биде имплементиран во такви популарни датотечни системи како ext2, итн. во иднина. Значи, оваа функција е моментално имплементирана само во Windows верзиите на Firebird и може да биде имплементирана во Linux верзиите во иднина.

За подобра контрола на претходното алоцирање на простор на дискот, беше воведена нова поставка во Firebird.conf: DatabaseGrowthIncrement. Ова е горната граница на големината на парчето за претходно алоцирање во бајти. Стандардната вредност е 128MB. Кога моторот има потреба од повеќе простор на дискот, тој алоцира 1/16 од веќе алоцираниот простор, но не помалку од 128KB и не повеќе од вредноста на DatabaseGrowthIncrement. Ако DatabaseGrowthIncrement е поставен на нула, тогаш претходното алоцирање е оневозможено. Просторот за сенка датотеките на базата на податоци не се претходно алоцира.

Исто така, претходното алоцирање е оневозможено ако опцијата „No reserve“ е поставена за базата на податоци.

Забелешка: претходното алоцирање исто така овозможува да се избегнат корупции во услови на недостаток на простор на дискот - во таков случај, постои голема шанса базата на податоци да има доволно претходно алоциран простор за да работи додека администраторот не ослободи простор на дискот.

Автор: Vlad Khorsun,