Vodič za hardver Firebird

Алексеј Ковјазин, последње ажурирање: 30. новембар 2015.

Често можете видети следеће питање у групама за техничку подршку за Firebird: „Који је хардвер избор за Firebird DBMS?“. Ова тема остаје трајно популарна јер се захтеви за хардвер разликују у зависности од задатака, а сам хардвер се мења током времена.

Одлучили смо да напишемо овај водич како бисмо пружили потребно знање свима који желе да изаберу заиста ефикасан хардвер за своју Firebird базу података. Да бисте то урадили, мораћете да научите неке основне детаље о томе како Firebird, оперативни систем и, наравно, хардвер функционишу.

Мало теорије

Да бисмо сазнали који ће хардвер најбоље одговарати вашој Firebird бази података, морамо да разумемо како Firebird користи своје компоненте: CPU, RAM, HDD/SSD и како ове компоненте интерагују са оперативним системом (на пример, са кешом датотека).

Функционални модули Firebird сервера

Пре свега, погледаћемо функционалне модуле Firebird-а уз помоћ Слике 1:

Слика 1. Firebird модули

Firebird укључује следеће главне функционалне модуле:

Објекти метаподатака: погледи, табеле, индекси, окидачи, ускладиштене процедуре и други објекти базе података. Објекти метаподатака се налазе у адресном простору Firebird процеса (то може бити fbserver, fb_inet_server или firebird.exe).
Кеш бафера страница садржи странице базе података прочитане са диска и налази се у адресном простору серверског процеса. Механизам кеширања страница је прилично сложен, па ћемо само навести да Firebird кешира најчешће коришћене странице базе података.
Firebird сортира записе у меморији (у адресном простору серверског процеса) све док количина меморије коришћене за све истовремене операције сортирања не достигне лимит постављен параметром TempCacheLimit (firebird.conf). Када се овај лимит прекорачи, привремена датотека (са одговарајућим флагом оперативног система) се креира у фолдеру са привременим датотекама и користи се за сортирање. Ако у систему постоји слободан RAM, датотека за сортирање ће бити кеширана од стране оперативног система и сортирање ће се обављати у меморији.
Глобалне привремене табеле (GTT) се креирају као привремене датотеке у оперативном систему. Ако оперативни систем има слободне меморије, операције са GTT се изводе у RAM-у.

Основне операције са хардвером

Погледајмо како функционални модули Firebird-а интерагују са хардверским компонентама током операција које се изводе у раду са базама података.

Када се Firebird покрене, серверски процес заузима минималну количину RAM-а (неколико мегабајта) и не обавља интензивне операције са CPU-јем или RAM-ом.

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

Када клијент почне да извршава SQL упите (укључујући ускладиштене процедуре), сервер обавља одговарајуће операције користећи хардвер. Могуће је издвојити следеће основне операције које укључују интеракцију са хардвером:

читање страница базе података са хард диска,
писање страница базе података на хард диск,
читање страница базе података из кеша,
писање страница базе података у кеш,
читање података из и писање података у глобалне привремене табеле,
обрада SQL упита (на пример, JOIN-ови),
сортирање записа у резултујућим скуповима.

Свака од ових операција захтева одређену количину системских ресурса. Табела испод приказује потрошњу ресурса у интензивним јединицама (1 значи најмање интензивно, 10 значи најинтензивније):


	Читање странице са диска	Писање странице на диск	Читање странице из кеша бафера страница	Писање странице у кеш бафера страница	Читање из GTT	Писање у GTT	Сортирање записа	Обрада SQL упита
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Диск I/O	10	10	1	1	1	1	1	1

Као што можете видети, најзахтевније операције у погледу ресурса су оне које укључују приступ диску јер дискови остају најспорија хардверска компонента упркос напретку у последњих неколико година везаном за SSD.

Ово води до једног од начина за оптимизацију перформанси који је у потпуности везан за хардвер - пребацити све операције читања и писања у RAM. Али имајте на уму да приступ повећања кеша страница не функционише. Овим питањем ћемо се детаљно позабавити у одељку о RAM-у.

Истовремено изведене операције

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

Са становишта хардверских компоненти, можемо говорити о паралелном коришћењу CPU-ја, диска и RAM-а. Савремени CPU-јеви имају неколико језгара која могу паралелно извршавати скупове инструкција, па DBMS сервер распоређује операције између језгара, што значи закључак да што више језгара CPU има, то ће више клијената моћи да ради на овом серверу.

Није тако једноставно са становишта дискова. Када традиционални хард дискови (HDD) читају информације, они физички померају главу преко магнетног материјала одређеном коначном брзином. База података може бити прилично велика, тј. 3 терабајта, и ако SQL упити клијената паралелно приступају њеним подацима који се налазе у различитим областима диска, глава диска ће скакати између различитих области на диску, чиме ће озбиљно успорити операције читања и писања. То ће значајно повећати ред на диску док остали ресурси (CPU, RAM) мирују. Наравно, кеш диска (кеш HDD-а или RAID контролера) донекле надокнађује ово успоравање, али није довољно.

За разлику од традиционалних HDD-ова, солид-стејт дискови (SSD) су много мање склони деградацији перформанси у случају паралелног приступа подацима. Предност SSD-а је посебно очигледна када паралелно пишете податке - наши тестови показују да је SSD 7 пута бржи од SATA диска (линк!). Међутим, SSD-ови имају неке проблеме које треба узети у обзир током њихове употребе (видети Одабир дискова) како би се избегла успоравања, рани кварови и губитак података.

Операције са RAM-ом се на савременим рачунарима изводе веома брзо, практично су ограничене само пропусним опсегом магистрале података, па ове операције не представљају уско грло чак и ако постоји много паралелних SQL упита.

Токови података

Током извршавања SQL упита, Firebird чита и пише много података, преноси их између функционалних модула и одговарајућих хардверских компоненти. Да бисмо идентификовали могућа уска грла, морамо разумети како се врши размена података. Слика 2 испод ће нам помоћи у томе:

Слика 2. Токови података између RAM-а и трајне меморије

Очигледно је да је пренос података из трајне меморије у RAM и назад најзахтевнија операција у погледу времена. Она ствара два тока података: читање/писање страница података из датотека базе података и читање/писање датотека за сортирање. Пошто може постојати неколико датотека за сортирање и оне могу бити прилично велике, могу створити прилично велико оптерећење на дисковима, па је препоручљиво усмерити ове улазно/излазне токове на различите дискове.

Резервно копирање

Firebird вам нуди два метода резервног копирања: верификовано резервно копирање помоћу gbak алатке и неверификовано инкрементално резервно копирање помоћу nbackup алатке.

Препоручујемо да комбинујете ове методе резервног копирања: покрените nbackup често (на пример, сваког сата, дана и недеље) и креирајте верификовану резервну копију сваке ноћи помоћу gbak-а.

Који год метод резервног копирања да користите, датотека базе података се чита (цела или део) и записује се резервна копија (пуна или инкрементална). Операције писања се током процеса резервног копирања изводе секвенцијално, што значи да ће обични јефтини хард дискови са SATA интерфејсом (HDD SATA) бити добри за резервно копирање јер секвенцијално пишу прилично брзо.

Одабир одговарајућег хардвера

Сада када имамо представу о томе како Firebird интерагује са хардвером, треба да се осврнемо на факторе који утичу на избор сваке појединачне компоненте и њених спецификација.

Понекад стварна статистика одређене базе података снажно утиче на избор хардверских компоненти, па ћемо користити алате из HQbird-а (професионалног дистрибутивног пакета Firebird-а од IBSurgeon-а) да добијемо те статистике. Пробну верзију HQbird-а можете преузети на http://hqbird.com/en/hqbird/.

CPU

Приликом избора CPU-а, треба узети у обзир следеће три ствари:

Који упити преовлађују у апликацији,
Број активних конекција на базу података у просеку и под вршним оптерећењем,
Верзија и архитектура Firebird-а.

Који упити преовлађују у апликацији?

Firebird увек извршава један упит на једном језгру, тако да сложени и лоше оптимизовани упити могу да искористе једно језгро до 100%, гурајући друге упите на мање оптерећена језгра. Што је више језгара, мање су шансе да ће цео CPU бити искоришћен и да ће корисници приметити било какво погоршање перформанси у апликацији.

Ако апликација углавном покреће једноставне кратке SQL упите, сви упити су добро оптимизовани и не генеришу се ad hoc упити (на пример, за извештаје), CPU неће представљати уско грло за перформансе и можете изабрати јефтинији CPU са мање језгара.

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

Број активних конекција на базу података у просеку и под вршним оптерећењем

Број конекција (активних корисника) такође утиче на избор CPU-а. Нажалост, чак ни програмери апликација немају појма колико је тачно конекција, упита и трансакција активно у одређеном тренутку. Да бисте добили прецизније информације о овоме, препоручујемо да користите MON$ Logger алат из HQbird-а и направите неколико снимака док ради, где ћете видети колико је конекција заправо успостављено.

Слика 3. MON$ Logger: број конекција

На пример, овде можете видети да је број конекција 296. Очигледно је да је превише оптимистично користити quad-core CPU у овом случају, док ће решење са 24 језгра бити сасвим у реду. Такође је препоручљиво избројати број истовремено покренутих упита, јер конекције могу бити неактивне без иједног покренутог SQL упита.

Можете користити стопу од 10 до 30 конекција по 1 језгру да бисте грубо проценили потребан број језгара у вашем CPU-у. 10 конекција по језгру за апликацију са углавном сложеним и спорим упитима, 30 конекција по језгру за апликацију са углавном једноставним добро оптимизованим упитима.

Верзија и архитектура Firebird-а

Ако користите Firebird верзију 2.5, имајте на уму да треба да користите Classic или SuperClassic архитектуру да бисте могли да распоредите обраду на више језгара. У верзији 2.5, SuperServer архитектура може да користи само једно језгро за једну базу података, па је не треба користити у системима који троше много ресурса.

У Firebird верзији 3.0, SuperServer, Classic и SuperClassic користе могућности multi-core CPU-а. Firebird 3.0 SuperServer показује најбоље перформансе.

RAM

Када бирате RAM, треба обратити пажњу на две ствари:

меморијски модул мора имати код за исправљање грешака (ECC RAM)
количина RAM-а мора бити правилно израчуната

ECC RAM

ECC RAM значајно смањује број грешака које се јављају током рада са меморијом и препоручује се његова употреба у индустријским системима.

Израчунавање потребне количине RAM-а

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

Firebird SuperServer покреће један процес са једним кешом страница за све конекције.

Дакле, следећи параметри утичу на укупну потрошњу меморије:

Број конекција
Величина странице базе података
Величина метаподатака (пропорционална броју табела, окидача, ускладиштених процедура итд.; неподесива; одређена физичком употребом)
За Classic и SuperClassic - по конекцији
За SuperServer - по инстанци отворене базе података
Величина кеша страница (одређена параметрима у заглављу базе података или у firebird.conf или у својствима одређене конекције)
За Classic и SuperClassic - по конекцији
За SuperServer - по инстанци отворене базе података
Величина кеша за сортирање (одређена параметром у firebird.conf). Имајте на уму да се меморија за сортирање не додељује одједном, већ по потреби.
За Classic - по конекцији
За SuperServer и SuperClassic - по процесу (тј. један кеш за сортирање)
За Classic/SuperClassic - величина lock табеле (обично је мала, па ћемо је изоставити из нашег израчунавања).

Компанија IBSurgeon је извршила неколико тестова и добила скуп оптималних вредности за број страница у Firebird кешу страница:

Classic/SuperClassic - од 256 до 2000 страница
SuperServer 2.5 - 10000 страница
SuperServer 3.0 - 100000 страница

На основу ових тестова, креирали смо оптимизоване Firebird конфигурационе датотеке за сервере са 4-6 GB меморије. Можете их преузети овде: /sr/optimized-firebird-configuration/

Формуле за израчунавање потребне количине RAM-а

Испод можете видети формуле које се користе за процену приближне количине меморије која ће бити потребна Firebird-у. Стварна потрошња меморије може се разликовати јер ова процена не узима у обзир количину меморије потребну за метаподатке, за бит маске индекса итд., што може повећати потрошњу меморије. Међутим, такође се претпоставља да ће меморија за сортирање бити у потпуности искоришћена у свим конекцијама, што обично није случај.

Када је ваша база података већ у употреби, можете погледати просечну количину меморије коју користи Firebird процес (помоћу TaskManager-а или ProcessExplorer-а).

Процена за Classic:

Број конекција * ( (Број страница у кешу * Величина странице) + Величина кеша за сортирање )

Пример за Classic: претпоставимо да очекујемо 100 активних корисника, величина странице базе података је подешена на 8 KB, број страница у кешу страница је подешен на 256, величина кеша за сортирање је повећана са 8 MB (подразумевана вредност за Classic и SuperClassic) на 64 MB:

((256.8 KB)+64) = 6600 MB

Процена за SuperClassic:

Број конекција * (Број страница у кешу * Величина странице) + Величина кеша за сортирање

Пример за SuperClassic: 100 корисника, величина странице базе података је 8 KB, број страница у кешу страница је 256, величина кеша за сортирање је 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Процена за SuperServer:

(Број страница у кешу * Величина странице) + Величина кеша за сортирање

Пример за SuperServer (Firebird 2.5): 1 база података, 100 корисника, величина странице базе података је 8 KB, број страница у кешу страница је 10000, величина кеша за сортирање је 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Пример за SuperServer (Firebird 3.0): 1 база података, 100 корисника, величина странице базе података је 8 KB, број страница у кешу страница је 100000, величина кеша за сортирање је 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Прекомерна меморија”

Firebird се често оптужује за неефикасно коришћење меморије - када покренути процес сервера троши малу количину RAM-а, а остатак меморије остаје наводно неискоришћен.

Заправо, то није тачно. Овај закључак у основи лежи у погрешном разумевању начина на који Firebird-ов механизам кеширања функционише и у несавршености алата за праћење оперативног система.

Пре свега, морате бити потпуно јасни да Firebird у великој мери користи кеш датотека оперативног система. Када се страница учита у Firebird кеш страница, она пролази кроз кеш датотека оперативног система. Када Firebird истовари страницу из свог кеша страница, оперативни систем наставља да држи овај део базе података у својој RAM меморији, под условом да има довољно слободне меморије.

Слика 4. Нивои кеша: Firebird, оперативни систем и складиште

Међутим, ако само погледате, оперативни систем не приказује меморију додељену кешу датотека као заузету. На пример, ево типичне ситуације расподеле меморије када је Firebird сервер покренут, као што је приказано у Таск Манагер-у:

Слика 5. Таск Манагер не приказује коришћење кеша датотека

Изгледа као да је само 6,3 GB од 16 GB искоришћено.

Међутим, ако користите RAMMap алат (од SysInternals-а од Microsoft-а), све изгледа много логичније:

Слика 6. RAMMap приказује детаље о коришћењу меморије: мапиране датотеке су кеширане базе података

Датотеке базе података (dbw350.fb252x64.fdb и dbw250.fb252x64.fdb) су кеширане од стране оперативног система и заузимају целу меморију коју Таск Манагер проглашава слободном:

Слика 7. RAMMap: детаљи о коришћењу кеша датотека

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

Диск подсистем

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

Одвојени дискови за све

Да би се смањила конкуренција за улаз/излаз диска између операција са датотеком базе података и смањиле шансе за истовремени губитак базе података и резервне копије, препоручује се да имате три различита диска (или RAID низова): један за базу података, један за привремене датотеке и један за креирање и чување резервних копија.

Када кажемо „одвојени дискови", то значи да токови података морају пролазити кроз различите канале улаза/излаза. Ако креирате три логичка диска на једном физичком диску, неће бити повећања перформанси. Међутим, ако распоредите три логичка диска на уређају за складиштење података опремљеном мултиканалним контролерима, перформансе ће највероватније бити повећане јер уређај може да расподели токове података између контролера. Понекад се каже да издвајање посебног диска за чување датотека оперативног система и swap датотеке оперативног система повећава перформансе.

SSD за базу података

SSD је најбољи избор за рад са базом података јер обезбеђује одлично скалирање током паралелног улаза/излаза. Обавезно је да користите предузећске дискове са повећаним бројем циклуса читања/уписа, у супротном је врло вероватно да ћете изгубити податке због квара SSD-а.

Пре неког времена, SSD дискови су били склони повећаном хабању када је остајало мало слободног простора на диску (мање од 30%). Једноставно речено, свака измена на SSD-у се уписује у нову слободну ћелију, па је недостатак слободног простора доводио до повећаног хабања ћелија које су остајале слободне и до краћег животног века диска.

Произвођачи модерних SSD контролера тврде да је овај проблем решен превентивним премештањем статичких података и да је сада хабање ћелија мање-више изједначено. Међутим, тачне спецификације и алгоритми рада SSD-ова се чувају у тајности од стране произвођача, па и даље препоручујемо да оставите 30% простора на SSD-овима слободним, као и да смањите њихов очекивани животни век и планирате замену најмање једном у три године.

Претпоставимо да је величина ваше базе података тренутно 100 GB и да расте 1 GB месечно. У овом случају, не смете купити SSD минималне величине (120 GB), већ је боље изабрати следећи уређај у линији производа - 250 GB. Истовремено, куповина SSD-а од 512 гигабајта биће бацање новца, јер је препоручљиво заменити диск за три године.

Најбоља пракса је посветити SSD искључиво раду са базом података, јер било какве операције улаза/излаза смањују животни век дискова.

Диск за привремене датотеке

Пошто се привремене датотеке појављују на диску само када нема довољно RAM меморије, најбољи начин је, наравно, избећи ову ситуацију у потпуности. Могуће је проценити број и величину привремених датотека у производном систему само праћењем фасцикле са привременим датотекама. FBDataGuard из HQbird дистрибутивног пакета врши такво праћење. Када сазнате колико се привремених датотека за сортирање креира на диску и када се креирају, моћи ћете да повећате количину RAM меморије и промените конфигурацију у firebird.conf.

У сваком случају, Firebird захтева да наведете фасциклу где ће се чувати привремене датотеке. Обично се подразумевана вредност оставља непромењеном, тј. користи се фасцикла оперативног система за привремене датотеке. Ако је слободне RAM меморије довољно, ово је добар избор.

Међутим, постоји још једно важно питање у вези са локацијом привремених датотека на диску - то је креирање индекса када враћате верификовану резервну копију (креирану помоћу gbak алата). Када се индекс креира, такође се креира и привремена датотека која садржи све кључеве из овог индекса. Ако је база података прилично велика, величина индекса за неку велику табелу такође може бити прилично велика. На пример, индекс највеће табеле која садржи 3,2 милијарде записа у бази података од 1 терабајта је 29 GB, али је било потребно 180 GB слободног простора за креирање овог индекса:

Да бисте спречили недостатак слободног простора на системском диску, могуће је навести још један диск као додатни резервисани простор у firebird.conf:

TempDirectories =C:\temp; H:\Temp

Ако нема простора на првом диску, Firebird ће наставити да користи други диск за привремене датотеке и тако даље.

HDD за резервне копије

Обични HDD дискови са SATA или nSAS интерфејсом ће бити сасвим у реду за креирање и чување резервних копија. Они обезбеђују брзе секвенцијалне операције уписа и читања за датотеке резервних копија и довољно су јефтини да не штедите на њиховој величини и да чувате неколико резервних копија.

Дискови за резервне копије морају увек имати додатног слободног простора: величина најновије резервне копије + 10%. У овом случају, могуће је креирати свежу резервну копију, уверити се да је процес резервисања успешно завршен (овај процес може трајати неколико сати за базу података величине неколико терабајта) и тек након тога обрисати претходну резервну копију.

Ако обришете претходну резервну копију пре него што се нова креира, могуће је да нова резервна копија неће бити креирана док ће стара већ бити обрисана, а база података ће бити оштећена, на пример, због квара диска.

Ако користите горе препоручени метод резервисања (комбинација инкременталне тростепене резервне копије и верификоване резервне копије једном дневно са чувањем само једне најновије копије), користите следећу формулу за израчунавање минималног простора за резервну копију:

Database_size*3+0.2.Database_size

Размотримо следећи пример израчунавања простора потребног за резервну копију:

Претпоставимо да имамо базу података од 100 GB за коју чувамо тростепену инкременталну резервну копију (недеља-дан-сат - по једна копија) и једну копију дневне верификоване резервне копије. У овом случају, резервне копије ће заузети следећи простор:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (приближно)
Nbackup_level_2.hourly - 200 MB (приближно)
Дневна верификована резервна копија - 100 GB (приближно)
Плус вам је потребно резервисаних 110 GB да бисте могли да креирате следећу резервну копију.

Укупно - 316 GB.

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

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

Природно, паметни алати за резервно копирање (FBDataGuard из HQbird-а) ће приметити недостатак простора за резервне копије и послати одговарајућу поруку администратору.

HDD за базу података

SSD може да се испостави као прескупо решење или база података може бити превелика па ћете морати да користите јефтиније методе. У том случају, треба да користите HDD са SAS интерфејсом. Ако то није могуће, користите SATA дискове са nSAS интерфејсом или најјефтинију опцију - обичне SATA дискове.

Да бисте повећали брзину (а такође и поузданост - видети доле) чврстих дискова, треба их комбиновати у RAID10. RAID10 је комбинација огледаних (RAID1) и стрипованих (RAID0) блокова. Добар и добро конфигурисан RAID контролер са великим кешом је добра алтернатива SSD-овима.

Поузданост и RAID

Наравно, неопходно је повећати поузданост дисковног подсистема комбиновањем дискова у RAID у свим горе поменутим варијантама (осим за диск намењен искључиво привременим датотекама).

• За SSD-ове, побрините се да користите RAID1 - тј. два огледана диска на која се промене истовремено уписују, што значајно смањује шансе за губитак свих података. RAID 10 који се састоји од SSD-ова ће највероватније бити сувишан јер ће RAID магистрала ограничити проток. На пример, 6 Gbit/s интерфејс има проток од 600 мегабајта у секунди док су савремени појединачни SSD-ови већ достигли ову брзину. Тако ћемо добити исти лимит од 600 MB/s за RAID 10.

Осим што можете користити PCI Express 3.0 за комбиновање SSD-ова у RAID 10 јер је проток ове магистрале већ 16 гигабита у секунди и више.

• Ако користите HDD-ове за потребе резервног копирања, довољно је користити RAID1 који ће обезбедити сигурност резервних копија и прихватљиву брзину читања и писања.

• HDD-ови који се користе за базу података треба да буду комбиновани у RAID10 (најмање 4 диска) који пружа оптималну комбинацију цене, поузданости и перформанси. Неки корисници такође користе RAID5 жртвујући перформансе за већи простор.

RAID конфигурација за Firebird

Пре свега, треба да се уверите да у RAID-у постоји правилно напуњена резервна батеријска јединица (BBU). Ако таква батеријска јединица не постоји, већина RAID-ова прелази у сигурни режим писања (кеш диска је потпуно онемогућен) који пружа нижу брзину улаза/излаза од обичног SATA диска!

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

Затим треба да конфигуришете кеш за читање и писање. Често је кеш онемогућен подразумевано и ако желите да RAID буде прилично брз, морате омогућити кеш.

Поред омогућавања кеша, треба проверити како ради - може бити write through и write back. Брз начин рада са кешом је write back - у овом случају, све промене се уписују у контролер кеша и, након неког времена, директно на диск.

Можете користити алате произвођача који долазе са RAID-ом да проверите батеријску јединицу, кеш и режим.

Савремени RAID контролери такође могу фино подесити кеш - може се прилагодити за олакшавање читања или писања. Обично је подељен 50%/50% за читање и писање.

Да бисте сазнали како тачно конфигурисати кеш, можете користити и MON$ Logger алат из напредног HQbird дистрибутивног пакета. Он приказује однос операција читања и писања једна према другој (агрегирано од тренутка прве конекције на сервер):

Слика 8. HQbird MON$Logger: однос читања/писања

Као што видите, у овом примеру има много више операција читања него писања, па има смисла конфигурисати RAID контролер за 80% операција читања и 20% операција писања.

SAN и базе података

Интегрисана складишта су постала популарна у последње време. Она укључују флексибилно прилагодљив низ дискова (све врсте RAID-а) са напредним могућностима кеширања. Обично SAN-ови имају неколико улазно/излазних контролера, што омогућава истовремено опслуживање више сервера и прилично брз рад.

Многе организације купују SAN-ове и користе их у раду са Firebird базама података. Ако је SAN правилно конфигурисан, могуће је постићи добре перформансе. Треба узети у обзир следеће ствари ако користите SAN:

Морају бити доступни неколико високоперформансних диск контролера који обезбеђују мултиканалну размену података
Резервне батеријске јединице морају бити присутне (BBU) ако су предвиђене дизајном.
Дискови за базу података морају бити комбиновани у RAID10.
Кеш мора бити омогућен, режим писања мора бити пребачен на write back.
Ако је неколико рачунара повезано на SAN, сваки од њих мора имати свој контролер.
Инсталирани су најновији SAN драјвери. Наишли смо на случајеве када су каснији драјвери дали 30% повећање перформанси.
Ако постоји неколико логичких дискова на SAN-у (за базе података, резервне копије, оперативни систем), они имају различите улазно/излазне канале. Покушај коришћења једног канала за све дискове заједно ће резултирати нижим перформансама.
Слично томе, ако неколико сервера и база података користи SAN истовремено, перформансе могу бити ниже због повећаног пропусног опсега улазно/излазних контролера.
Често се користе комбиновани начини - када се оперативни систем и привремене датотеке чувају на локалним дисковима док се база података и резервне копије чувају на SAN-у.

Често се SAN-ови користе као “два сервера - један SAN” да би се створио кластер отпоран на отказе. Треба напоменути да такав кластер може решити проблеме везане само за хардверске отказе на једном од сервера пребацивањем на други сервер одмах. Ако је проблем везан за SAN или саму базу података, ово решење неће помоћи.

Да бисте изградили заиста решење отпорно на отказе, треба користити решења која реплицирају податке између две инстанце базе података. Можете контактирати [email protected] да сазнате више доступних решења за Firebird.

Кратки закључци и препоруке

Хајде да сумирамо закључке и препоруке за Firebird у вези са хардвером.

Вишејезгарни процесори морају се користити за опслуживање великог броја корисника
Најмања количина RAM-а се израчунава на основу броја корисника и конфигурације базе података, вишак RAM-а ће оперативни систем ефикасно користити за кеширање датотеке базе података.
Користите одвојене дискове за базе података, привремене датотеке и резервне копије
Радије користите SSD-ове за базе података
Резервишите најмање 30% слободног простора на SSD-овима.
Препоручљиво је посветити диск бази података.
Користите предузећске SSD-ове (са много циклуса писања/читања).
Уверите се да користите RAID.
За SSD - RAID 1, за HDD - RAID10, за резервни HDD - RAID1. i. SAS, SATA, nSAS
Уверите се да је RAID батерија присутна и напуњена
Уверите се да је пребачен на write back.
Неки RAID контролери већ имају конфигурисану величину кеша, на пример, 75% за читање, 25% за писање, или 50/50 итд. Зато је неопходно инсталирати MON$Logger - софтвер који ће контролисати RAID параметре, тражити однос читања/писања и мењати RAID подешавања.
Постоје предности и мане у коришћењу SAN-ова. Да бисте извукли максимум, треба правилно конфигурисати SAN.
Да бисте изградили решење отпорно на отказе, потребно је користити решења са репликама које раде на различитим серверима.

Контакти

Компанија IBSurgeon/IBase.ru развија напредни HQbird дистрибутивни пакет за предузећа, пружајући комплексну техничку подршку за Firebird и развијајући прилагођене дистрибутивне пакете као и решавајући друге сложене проблеме.

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

Контактирајте нас: [email protected]