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

IBSurgeon библиотека

23 додатних начина да убрзате Firebird

Алексеј Ковијазин, IBSurgeon, [email protected], 08-јан-2019

Преводи: Portuguese

Зашто „још 23"?

Неки од вас се сећају чланка « 45 начина да убрзате Firebird», који је објављен у мају 2016. Сада је време да објавимо следећу серију савета и трикова, углавном заснованих на искуству оптимизације и одржавања Firebird база података и сервера са великим бројем конекција (1000+).

1. Подесите Power Options на High Performance у Windows Server 2016 и 2019

Подразумевано, Windows Server има план напајања подешен на „Balanced", што није погодно за сервере база података. Подесите га на „High Performance" и добијте приближно +20% перформанси за CPU-интензивне операције. Може се подесити онлајн, без рестартовања или поновног покретања. Слика испод приказује CPU графикон који демонстрира предност „High-performance" плана напајања:

Више детаља о нашим тестовима са Windows плановима напајања можете пронаћи овде.

2. Омогућите „Интеракцију са радном површином" на Classic за Windows

Ако користите Firebird са Classic архитектуром на Windows-у, омогућите потврдни знак „Allow service to interact with desktop". Без ове поставке, ресурс „desktop heap" је ограничен од стране Windows-а, и Firebird не може да отвори више од 250-300 конекција (зависи од метаподатака базе и повезане потрошње меморије) - појавиће се Out Of Memory грешка.

3. Пазите: Domain Controller

Проблем је што Windows са Domain Controller улогом онемогућава write cache на диску са Active Directory базом података.

То утиче на Firebird на различите начине (као и на друге апликације, наравно), и показује значајно лошије перформансе него на серверима без Active Directory улога.

Имајте на уму да овај проблем утиче на тако популарне Windows верзије као што је Windows Small Business Server 2011, као и на друге верзије са DC.

4. Повећајте „max open files" лимит на Linux-у

Ако користите Linux као сервер база података, не заборавите да подесите лимите за Firebird. Проверите лимите за ваш Firebird процес (SuperServer или SuperClassic) следећом командом:

Code 
cat /proc//limits

и обратите пажњу на линију са максималним бројем отворених фајлова.

Firebird може да користи до 4 handle-а по конекцији, и ако имате нешто овако:

Code 
Max open files 4096 4096 files

то значи да ће укупан број конекција које сервисира Firebird процес бити ограничен на око 1000.

Имајте на уму - ако имате 4 базе на серверу, конекција за сваку базу се броји.

Подесите више - препоручујем 65535.

Не заборавите да поново проверите након рестартовања Firebird процеса: да ли је примењено или не.

За Classic архитектуру, потребно је проверити и повећати лимите за корисника „firebird".

5. Користите модеран Linux

Да, разумем да је овај савет тривијалан, али много пута сам видео добро побољшање перформанси након миграције са CentOS 6 на 7, Ubuntu 12 на 16 (на истом хардверу!), па је сада то обавезна препорука за сервере база података са више од 250-300 конекција. Модеран Linux је предуслов пре даљих корака оптимизације.

Препоручене верзије Linux-а: CentOS 7.x и Ubuntu 16, 18.

6. Резервишите 40% RAM-а за file cache на Windows-у

OS Memory Manager има импликације у вези са алокацијом меморије, и, подразумевано, Windows захтева 40% RAM-а за file cache.

Нажалост, лош алат Windows Task Manager приказује меморију која се користи за file cache као „слободну", и неки администратори покушавају да натерају Firebird да потроши сву ту слободну меморију, па подесе DefaultDBCachePage параметар у firebird.conf на веома високе вредности, што обично води до swapping-а.

Увек користите RAMMap алат да видите стварну употребу меморије на Windows-у.

Емпиријско правило за Windows Server (намењен за коришћење као Firebird сервер) је следеће: Firebird меморија (Working Set) треба да буде мања од 40% укупног RAM-а. Ако је укупна величина working set-ова за све процесе већа од 50%, Windows може да покрене swap.

Имајте на уму: „резервисати" овде значи не само „не подешавати превише page buffer-а у Firebird-у" већ, такође важно, ограничити употребу меморије другог софтвера. На пример, ако имате MS Exchange или MSSQL на истом серверу са Firebird-ом, побрините се да ограничите њихове меморијске апетите.

Ако сте заинтересовани да сазнате детаље, снимио сам вебинар посвећен управљању меморијом у Firebird-у:

7. Резервишите 30% RAM-а за file cache на Linux-у

Linux ради са file cache-ом на другачији начин него Windows, и, генерално, количина RAM-а која се користи за file cache може бити значајно мања него на Windows-у, без приметне деградације перформанси Firebird-а. Међутим, да бисте гарантовали високе перформансе система са великим бројем конекција, посебно на Classic и SuperClassic, добра идеја је да резервишете 30% RAM-а за file cache.

8. Користите irqbalance на Linux-у

irqbalance често побољшава Firebird перформансе и балансирање CPU оптерећења на серверима са великим бројем језгара.

9. За виртуелне машине - пазите на Memory Overcommit

Виртуелна машина може бити конфигурисана да има више меморије него што физички постоји на хост машини - са функцијом познатом као Memory Overcommit (назив може бити другачији на различитим системима виртуелизације). То значи да у случају врхунца потрошње меморије (на VM-у са сервером базе или на суседном VM-у) swap може да почне, што ће довести до значајних кашњења. За високоперформансни VM намењен за сервер базе података, сва меморија треба да буде статична.

10. За виртуелне машине - проверите VM лимите

Често се VM-ови креирају са подразумеваним CPU и IO лимитима, који могу бити веома ниски, као 50 IOPS и 10% CPU. Проверите подешавања вашег сервер VM-а и уклоните све лимите - високоперформансни сервер базе података треба да има све могуће CPU, пропусни опсег и IO.

11. Очистите привремене фајлове Firebird-а

Firebird креира много привремених фајлова за различите операције: сортирање, BLOB обраду, праћење. Ови фајлови се чувају на следећим локацијама: на Windows-у C:\ProgramData\firebird, на Linux-у / tmp / firebird

Нормално, ови фајлови би требало да се аутоматски чисте, међутим, понекад се то не деси (на пример, у случају рестартовања сервера).

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

12. Не заборавите да омогућите file cache са великим Firebird cache-ом

Као што знате, Firebird cache (такође назван „page buffers") је одређен параметром DefaultDBCachePages у firebird.conf/databases.conf, или директно у заглављу базе података.

У Firebird 3 SuperServer величина овог cache-а може бити подешена веома високо, али је важно запамтити још један параметар: FileSystemCacheThreshold.

Ако је FileSystemCacheThreshold мањи од DefaultDBCachePages или page buffer-а, оперативни системски file cache неће бити коришћен, што може довести до проблема са перформансама.

У 99% случајева, боље је имати омогућен file cache.

Да бисте то обезбедили, увек подешавајте параметре према следећем правилу:

  • DefaultDBCachePages = X
  • FileSystemCacheThreshold = X+ N, N>1

Постоје ретки случајеви када онемогућавање file cache-а побољшава перформансе - ако имате такав пример, молим вас контактирајте ме - [email protected]!

13. Убрзајте безбедносну базу података

Свака конекција на Firebird базу података успоставља конекцију на безбедносну базу (security3.fdb у случају Firebird 3), и обавља неколико читања и уписа (трансакционе странице, header страница). Ако имате честе конекције, перформансе ваше безбедносне базе могу постати проблем.

Као минимум, можете да урадите следеће:

  • Повећајте page buffers за securityN.fdb (емпиријски оптимум је 256 бафера)
  • Преместите security3.fdb на брзи диск (то је стандардна функција у Firebird 3, у 2.5 ће захтевати поновну инсталацију)

Затим, можете поставити Forced Writes OFF за безбедносну базу података - мала шанса за корупцију није проблем у овом случају.

Најрадикалнији начин је да безбедносну базу података учините само за читање - то ће елиминисати сва уписа у њу.

Ако не мењате често кориснике у безбедносној бази података, то је најбоље решење.

14. Пробајте SuperClassic на Firebird 3

У Firebird 3, SuperServer архитектура је била нашироко рекламирана као крајње решење за перформансе, али постоје неки типови оптерећења који показују боље перформансе са SuperClassic (али не и Classic - он увек ради спорије од SuperServer/SuperClassic).

Како да спроведете овај експеримент на безбедан начин? Пратите кораке испод:

Да бисте пробали SuperClassic

  1. Подесите у firebird.conf
  2. ServerMode=SuperClassic
  3. DefaultDbCachePages=1024
  4. gfix -buff 0
  5. Поново покрените Firebird

Да бисте се вратили на SuperServer

  1. Подесите у firebird.conf
  2. ServerMode=SuperServer
  3. DefaultDbCachePages=N # N*величина странице*број_база < 25% RAM
  4. FileSystemCacheThreshold = N+1
  5. gfix -buff 0
  6. Поново покрените Firebird

Молим вас да ми пишете ([email protected]) о резултатима експеримента, занима ме да видим резултате.

15. Велика база података? Повећајте величину странице

Подразумевано, Firebird базе података имају следеће величине страница:

  • 2.5 - 4096 бајтова
  • 3.0 - 8192 бајтова

Међутим, максимална величина странице је 16K (у 4.0 - 32K).

За базе података веће од 100Gb у 95% случајева, боље је имати највећу доступну величину странице, како би се:

  • Смањила дубина индекса. Препоручује се да индекси имају дубину мању или једнаку 3. Индекси са дубином 4 и 5 биће много спорији
  • Повећала искоришћеност RAM. Firebird кеш је одређен у страницама, 1000 страница са величином 8K биће 8Mb стварне меморије, а са 16K - 16Mb.
  • Смањио број системских страница. То ће убрзати приступ записима великих табела (мање скокова показивач-показивач-страница података) и помаже у припреми великих SQL упита. Да бисте повећали величину странице базе података, базу треба бекаповати gbak алатом, а затим рестаурирати са параметром -page ( gbak -c -page 16384).

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

16. Не користите no_reserve флаг

Флаг no_reserve чини да Firebird не резервише слободан простор (30%) на страницама података за могуће верзије записа, које настају након UPDATE или DELETE. Овај флаг омогућава да се подаци чувају на компактнији начин (и величина базе је мања), али у случају UPDATE/DELETE све промене иду на нову страницу података. Као резултат, у бази са no_reserve флагом UPDATE/DELETE операције су спорије.

Дакле, ако ваша база није само за читање, препоручујем уклањање no_reserve флага.

Како да проверите да ли је постављен или не - погледајте линију Attributes у излазу команде

Code 
gstat -h database

Како да га онемогућите:

Code 
gfix -use reserve database

Након ове команде, нове странице података ће се креирати са резервисаним простором.

Међутим, да бисте постигли пун ефекат, потребно је бекаповати базу са gbak и затим је рестаурирати, у том случају ће све странице података имати резервисан простор.

Напомена: величина базе ће порасти након уклањања no_reserve флага и бекапа/рестаурације.

17. Поставите високу почетну величину за Firebird lock table

Lock table је механизам Firebird-а који се користи за синхронизацију приступа интерним објектима мотора.

Firebird lock table може аутоматски да расте, али његово повећање је спора операција, која може довести до микро-замрзавања. Lock table може само да расте, почевши од почетне величине (поставља се у firebird.conf).

Да бисте спречили вишеструка повећања lock table-а, добра идеја је да пратите величину lock table-а на крају радног периода (дан, недеља, итд.), а затим је поставите као почетну величину у firebird.conf.

LockMemSize=99999999

За вашу референцу: LockMemSize на системима са високим оптерећењем са ~1000 корисника је обично испод 200Mb.

18. Користите fb_lock_print за бројање веза ка бази података

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

Често програмери користе упит SELECT count(*) FROM MON$ATTACHMENTS да би добили ову вредност, али то није оптималан начин: чести упити ка MON$ табелама могу бити терет за базу, па је боље користити алтернативу:

Покрените

fb_lock_print -d име_базе | алиас

и проверите Owners вредност - она ће показати тренутни број веза ка бази података.

19. Избегавајте непотребне LEFT JOIN-ове

Често виђам упите са конструкцијом као што је ова:

T1 LEFT JOIN T2 ON (…) WHERE T2.Field_condition

У суштини, услов на T2 искључује NULL-ове из излаза LEFT JOIN T2, па је могуће променити LEFT JOIN у INNER JOIN - то неће утицати на резултат упита.

INNER JOIN даје више слободе Firebird оптимизатору, и у модерним верзијама Firebird-а, он је много боље оптимизован од LEFT.

Посебно има смисла у следећим случајевима:

  • Нема услова за T1 у WHERE клаузули
  • T2 је мала табела

20. Избегавајте непотребно бројање записа

Још једна честа грешка у сложеним упитима и ускладиштеним процедурама је коришћење select count() само да би се проверило постојање записа.

Следећи упит ће прочитати све записе према услову1:

Code 
(select count(*)…. where condition11) >0

Боље је користити ову конструкцију уместо тога

Code 
Exists(select first 1 id where condition1)

Ако услов1 враћа више од 1 записа, предложена опција ће бити много бржа, јер не чита све записе, већ се зауставља након првог прочитаног записа.

21. Избегавајте непотребно сортирање у ускладиштеним процедурама

Поређење резултата упита унутар ускладиштене процедуре треба да буде оправдано пословном логиком.

На пример, у примеру ускладиштене процедуре испод, ORDER BY клаузула је бескорисна са становишта пословне логике, али додаје непотребну операцију сортирања.

Code 
create or alter procedure NEW_PROCEDURE
returns (
    SUMX double precision)
as
declare variable _amount double precision;
begin
for select T1.amount from Table1 t1 where ....
    order by id
    into :_amount
    do
    begin
     sumx=sumx+_amount
    end;
  suspend;
end

Проверите свој PSQL код за сличне ситуације и уклоните бескорисни ORDER BY (као и distinct и UNION).

22. Не држите упите у припремљеном стању без потребе

Често виђамо 500-1000 припремљених изјава у свакој вези (може се проверити MON$ упитима).

Огромна већина њих се покреће само једном, а затим само седи у RAM-у, чинећи Firebird радни скуп већим и успоравајући MON$ упите.

Препорука је да SQL упите држите у припремљеном стању само ако је намењено да се покрећу много пута, или ако је њихово време припреме велико (може бити тако за веома велике упите са много join-ова и приступом огромним табелама).

23. Увек затварајте упите са великим сортирањем

Док SQL упит са сортирањем (ORDER BY, GROUP BY, UNION, distinct) није затворен, Firebird задржава сортиране записе у меморији. Величина меморије издвојене за сортирање је постављена TempCacheLimit параметром у firebird.conf, подразумевано је 64Mb.

Чак и са повећаним TempCacheLimit-ом, дуготрајни упити са великим бројем сортираних записа ће на крају потрошити сву издвојену количину, и као резултат, сортирање ће отићи у привремене фајлове (тј. на диск). Као резултат, то може довести до значајног успоравања.

Препорука је да све такве упите затворите на време.

Питања?

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