Ова страница је машински преведена. Прочитајте енглески оригинал. English

IBSurgeon библиотека

Подешавање 1,7 терабајтне Firebird SQL базе података

Alexey Kovyazin, 14. јул 2014.

Као што се сећате из наших претходних чланака, истраживали смо митове о деградацији перформанси Firebird-а ( /sr/articles/firebird-performance-degradation-tests-myths-and-truth/), где смо креирали неколико база података од 9Gb до 30Gb, а такође тестирали и веома велику Firebird базу података (1,7 терабајта) (/sr/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

Сви тестови су обављени на истом хардверу, који је нека врста јефтине конфигурације: CPU AMD-FX8350, RAM 16GB, SATA софтверски RAID1 2x4Tb HDD Seagate дискови, оперативни систем Windows Server 2008R2 (2008R2 је 64-битни), и са истом Firebird конфигурацијом: то је био Firebird 2.5.2 64-битни, SuperServer, са повећаним page баферима и TempCacheSize. Овај SuperServer конфигурациони фајл можете бесплатно преузети са ове локације: /sr/optimized-firebird-configuration/

Као резултат, имали смо следећу слику перформанси базе података:

![Firebird перформансе 1813Gb (1.7Tb)](/images/performance/perf7_performance_with 1800Gb_Firebird_database.png)

Слика 1. Деградација перформанси од 9Gb до 30Gb, и 1,7Tb

Тачка #11 је ознака перформанси за базу од 30Gb, а #12 за базу од 1,7 терабајта - величина базе је порасла 60 пута (од 30Gb до 1813Gb), губитак перформанси је био 2,4 пута (од 407 до 169 поена).

Дакле, питање је: можемо ли побољшати перформансе Firebird-а на истом хардверу подешавањем конфигурације?

А одговор је: да!

Supercharging FirebirdSQL

Као што се сећате, у овом тесту смо покренули 20 истовремених веза које обављају интензивне INSERT-ове и, мање интензивне, UPDATE-ове.

Сви SELECT-ови су кратки и добро дефинисани, са ефикасним SQL плановима извршења, тако да је ово типична OLTP (онлајн обрада трансакција) апликација. За такве апликације најкритичнија ствар за перформансе је паралелна обрада. Firebird SuperServer 2.5.2 није погодан за обраду са више нити - ефикасно користи само 1 језгро по бази података, и ова чињеница чини SuperServer не баш добрим избором за OLTP апликације.

Дакле, потребно је променити Firebird архитектуру на Classic или SuperClassic, које подржавају обраду са више нити и користе више језгара CPU-а (постоји 8 језгара у CPU AMD-FX8350).

Затим је потребно извршити одређена подешавања, јер подразумевана конфигурација за Firebird није оптимална за наш тест систем.

Подешавање параметара у firebird.conf

Page кеш

Дакле, да бисмо побољшали OLTP перформансе, одлучили смо да испробамо Classic и SuperClassic архитектуре. Један од кључних параметара за Classic и SuperClassic је број page бафера у кешу. За разлику од SuperServer-а, Classic и SuperClassic додељују page кеш по вези.

За више детаља о Firebird архитектурама у 2.5 можете погледати ову табелу: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

Постоји једноставна формула за израчунавање употребе меморије page кеша за различите Firebird архитектуре:

    1. SuperServer - један page кеш по бази података. Подразумевана величина page кеша је 2048 страница, уобичајена препорука је 10000 бафера. У нашем случају кеш је био 16k (величина странице) x 10000 ~= 160Mb. То је за све везе.
    1. Classic и SuperClassic - engine додељује page кеш за сваку везу. Подразумевана величина је 75 страница, дакле 16Kb (величина странице) x 75 = ~= 1,17 Mb, за сваку везу.

Очигледно, величина page кеша треба да буде повећана, јер је 75 страница по вези премало. У наставку ћемо приказати резултате неколико различитих вредности за величину page кеша.

LockHashSlots

Интерно, Firebird engine користи табелу закључавања за захтевање и добијање закључавања за интерне објекте унутар базе података, и за Classic и SuperClassic постоји параметар LockHashSlots (подразумевана вредност је 1009). Треба га повећати под великим оптерећењем, да би се смањили хеш ланци у табели закључавања. Па, „велико оптерећење“ изгледа да је било која реална апликација са више корисника, па смо га поставили на 30011 (за све тестове).

LockMemSize

Параметар LockMemSize се користи за подешавање почетне величине табеле закључавања (подразумевана вредност је 1048576). Engine може повећати величину табеле по потреби. Међутим, повећање табеле закључавања је скупо у погледу CPU-а и других ресурса, јер се обавља кроз премапирање меморије. Дакле, поставили смо га на 7Mb, да бисмо уштедели неко време и CPU ресурсе.

Тестна покретања

Извршили смо неколико тестних покретања са различитим вредностима page кеша, са следећим резултатима:

Page бафери Classic, тестни поени SuperClassic, тестни поени
256 299 372
512 371 359
768 362 386
1024 312 387
1500 390 392
2048 285 284

Табела 1. Тестна покретања за Classic и SuperClassic

Као што можете видети, Classic и SuperClassic су много ефикаснији од Firebird SuperServer-а за овај задатак: резултати тестова су побољшани са 169 поена на 300-400, што је близу резултата које смо имали за базу од 30Gb!

Боље је видети резултате на следећем графикону:

Firebird перформансе 1813Gb (1.7Tb)

Слика 2. Резултати тестова за базу од 1,7 терабајта

Можете видети да је најбоља перформанса (и код Classic-а и код SuperClassic-а) била на 1500 страница по вези, тако да је величина page кеша по вези била:

1500x16k ~= 23,4Mb

Са 2000 страница по вези перформансе су значајно опале. Изгледа да је негде око 1500-2000 страница предност кеширања постала мања од трошка изазваног интеракцијама табеле закључавања између процеса за синхронизацију страница у кешевима сваког серверског процеса. Очигледно, за већи број веза ово ће се десити раније, зато су Classic/SuperClassic сервери обично конфигурисани са бројевима као што су 256-512 страница.

Такође постоји пад Classic перформанси око 768-1000 page кеша - нисмо сигурни зашто се то догодило.

Резиме

Наши експерименти потврђују да се перформансе Firebird-а могу повећати правилним избором Firebird архитектуре (SuperServer, Classic или SuperClassic) и одговарајућим подешавањем неколико важних параметара за специфичну архитектуру.

Као резултат, огромна база података Firebird SQL од 1,7 Tb може радити на јефтином хардверу са довољно добрим перформансама. Као практични резултат ових тестова, креирали смо неколико конфигурационих фајлова за све верзије Firebird-а за све архитектуре. Наравно, они нису подешени за специфичну апликацију и/или хардвер, али су бољи од подразумеваних конфигурационих фајлова, који су направљени за веома скромно оптерећење.

Комплетан сет оптимизованих Firebird конфигурационих фајлова: /sr/optimized-firebird-configuration/

Слободно постављајте питања: [email protected]

Шта даље?

Радимо на свеобухватном тесту који ће упоредити перформансе Firebird 2.5 и Firebird 3.0, са симулацијом реалног оптерећења и великим бројем веза. Останите са нама!