Настройката на производителността на OpenEdge® RDBMS еПросто!
Този раздел съдържа препоръки, които всеки може лесно да следва. Те могат да бъдат направени бързо за няколко минути, когато базата е спряна. Все пак трябва да се разбере, че най-простите средства няма да бъдат непременно оптимални - но те са значително по-добри от настройките по подразбиране и трябва да ви доближат до оптималните стойности. Имайте предвид, че стойностите на конфигурационните параметри по подразбиране, обсъдени в тази монография, се отнасят за стойностите за Progress версия 9.1. По-късните версии може да имат различни настройки по подразбиране.
4.1. Увеличете размера на буферния пул
Най-ефективният начин за увеличаване на производителността е да се разпредели повече памет за базата данни, с която да работи, като се започне от размера на буферния пул. Буферният пул на базата данни е област от паметта, предназначена да ускори много операции с база данни. Производителността се ускорява чрез намаляване на броя на четенията на диска чрез запазване на копия на наскоро използвани блокове данни в паметта. Друг фактор за ускоряване на работата е намаляването на броя на операциите за запис, тъй като. блоковете от данни в паметта могат да бъдат актуализирани много пъти, преди в крайна сметка да бъдат записани на диска. Достъпът до блокове, които вече са в паметта, е много по-бърз от четенето от диск. Буферният пул на базата данни обикновено заема най-голямата част от областта на споделената памет. Увеличаването на размера на тази област обикновено води до по-добра производителност.
Броят на буферите в пула на базата данни се задава с опцията -B. Размерът на буфера е равен на размера на блока с данни на базата данни.
Размерът по подразбиране е доста малък и много далеч от оптималния. За режим за един потребител по подразбиране е зададено 10 буфера, а за режим за много потребители е зададено на 8пъти повече от -n. Ако -n е по подразбиране 20, тогава броят на буферите ще бъде 160. Въпреки че оптималната стойност зависи от конкретната база данни и натоварването на приложението, две много груби стойности могат да се използват като начало:
- 10% от размера на базата данни
- 2 до 4 MB на потребител
Можете да увеличите размера на буферния пул, стига да имате свободна памет във вашата система. Но има ограничения: ако го направите твърде голям, системата може да започне да се разменя, което може да доведе до рязък спад в производителността на системата като цяло. Много системи имат достатъчно памет, за да можете да посочите 100 000 или повече буфера за буферен пул. Имайте предвид, че за база данни с размер на блок от 8192 байта, 100 000 буфера ще изискват около 900 мегабайта памет.
За 64-битови версии на Progress OpenEdge, ако системата има достатъчно физическа памет, можете да зададете общия размер на областта на споделената памет до 116 гигабайта.
За 32-битови версии на Progress OpenEdge общата споделена памет не може да надвишава приблизително 2 GB. Точната стойност на ограничението зависи от операционната система, но за повечето системи, при идеални условия, 32-битовите програми могат да използват приблизително 2 GB5 памет. Действителният лимит често ще бъде по-малък в зависимост от много фактори 4 .
Ако вашето приложение се свързва с много бази данни в режим на самообслужване, общото пространство, заето от споделени области на паметта за всички бази данни, към които се свързвате едновременно, не трябва да надвишава зададеното по-рано ограничение. Освен това трябва да имате достатъчно памет, за да съхранявате другиресурси, като например файлови дескриптори за всички файлове, свързани с бази данни, и семафори, използвани за комуникация на процеса.
4.2. Увеличете броя на буферите за регистрационния файл преди изображението
За да се кешира информация за транзакции в паметта, се използва отделен набор от буфери, които впоследствие се изчистват на диска в регистрационния файл преди изображението. Всяка промяна на състоянието на транзакция и промяна на състоянието на базата данни се записва като един или повече записи в журнала на транзакциите, които първо се поставят в текущия буфер на регистрационния файл преди изображение и след това се записват в регистрационния файл преди изображение. Това обикновено се прави чрез процеса на запис на BIW. Наличието на достатъчно буфери в паметта дава на този процес времето, необходимо за завършване на записа. Когато текущият регистрационен буфер е пълен и няма повече свободни празни буфери, транзакция, която иска да запише данни в регистрационния буфер, трябва да изчака, докато стане наличен празен буфер. Чрез увеличаване на броя на буферите намаляваме вероятността от изчакване при извършване на актуализация на базата данни.
Броят по подразбиране на регистрационните буфери преди изображение е 5 и се задава с опцията -bibufs. Увеличете тази стойност до около 25. Имайте предвид, че този параметър не е „регулатор на скоростта“. Просто трябва да имате достатъчно буфери, за да изгладите временните промени в количеството на регистрационните данни, които трябва да бъдат записани. В програмата за промоции можете да видите броя на изчакванията за празни буфери за регистрационния файл преди изображението. Ако стойността надвишава няколко единици в секунда, увеличете броя на буферите. Въпреки това, ако устройството, на което се намира регистрационният файл преди изображението, е претоварено и не може да завърши допълнителни операции за запис навреме, тогава увеличаването на броя на буферите няма да има ефект.
Ако не използвате Преди-изображениеWriter, увеличаването на броя на буферите ще има малък или никакъв ефект.
4.3. Увеличете броя на буферите за регистъра на следното изображение
Ако не стартирате процеса AIW, тогава увеличаването на броя на буферите ще има малък или никакъв ефект.
Ако не използвате записване на след изображение, увеличаването на броя на буферите няма да има положителен ефект и само ще губи памет.
4.4. Използване на опцията --spin
Базата данни може да използва механизма за заключване като метод за синхронизиране на дейността на процесите, осъществяващи достъп до данни, съхранени в споделена споделена област на паметта, като буферния пул на базата данни, по едно и също време. Ако системата, изпълняваща вашата база данни, има повече от един процесор, задайте опцията -spin на различна от нула стойност.
При условие, че сте стартирали вашата база данни с ненулева стойност на параметъра -spin, можете да я промените направо по време на операцията с базата данни, като използвате помощната програма promon. Това ще ви позволи да определите по-добра стойност за този параметър.
След като направите това, не забравяйте да актуализирате конфигурационния файл или базовия скрипт за стартиране.
Виждали сме голяма система с много процесори, където 2 000 000 работят добре, но това е доста нетипично.
Имайте предвид, че лицензът за RDBMS на работната група не поддържа използването на опцията -spin.
4.5. Увеличете размера на клъстера на регистрационния файл преди изображението
В многопотребителски режим базата данни извършва непрекъснат процес на синхронизиране на съдържанието на споделената памет със състоянието на базата данни на диска, по време на който модифицираните блокове данни се записват на диска във фонов режим. Нов цикъл на синхронизиране започва с отварянето на следващия регистрационен клъстер преди изображение. Увеличаване на размераКлъстерът от регистрационни файлове преди изображение води до увеличаване на интервала между контролните точки, което дава на писателите на APW времето, от което се нуждаят, за да работят. Продължителността на последните 8 проверки се показва на екрана Контролни точки на промоционалната програма. В идеалния случай интервалът между проверките трябва да бъде около минута или повече, а броят на буферите, изчистени на диска в контролна точка, трябва да бъде равен или близо до нула. По-дълги интервали са възможни, но не са необходими. Ако са по-кратки от минута, тогава трябва да увеличите размера на клъстера. Ако броят на прочистените буфери е по-голям от 10, тогава трябва да увеличите размера на клъстера или да увеличите броя на фоновите APW процеси или да увеличите производителността на запис на диск.
Размерът на клъстера преди изображение може да бъде зададен със следната команда:
proutil foo -C truncate bi -bi 4096
Размерът на клъстера е посочен в килобайти. Може да се използва начална стойност от 4 MB, но бази данни с високо ниво на транзакционна активност може да изискват по-голям размер на клъстера. Базата ще запомни стойността на размера на клъстера, която сте й дали.
Когато работите с лицензи за RDBMS на работна група, поддържайте малкия размер на клъстера. Стойност от 512 KB или по-малко ще бъде по-добра от по-големите клъстери. Тъй като не можете да стартирате фонови процеси с този лиценз, всички модифицирани блокове с данни ще бъдат записани на диска точно на контролни точки. Колкото по-голям е размерът на клъстера, толкова повече променени блокове ще се натрупат до този момент. Записването на тези блокове на диск ще доведе до периодично замразяване на базата данни.
4.6. Задаване на размера на регистрационния блок преди изображението
Увеличаването на размера на блока, използван за работа с регистрационния файл преди изображение, подобрява производителността. На UNIX системи (Solaris, AIX,HP-UX, Tru64, UnixWare и др.) трябва да използват 8K. В Linux системи трябва да се използва стойността 4K. Под Windows трябва да се използва стойността 4K, освен ако не сте увеличили размера на NTFS клъстера, както е посочено в раздела за Windows.
Размерът на блока преди изображение може да бъде зададен в програмата proutil със следната команда:
proutil foo -C truncate bi -biblocksize 8
4.7. Задайте размера на блока на регистъра на следното изображение
Увеличаването на размера на блока за регистрационния файл след изображение го прави по-ефективен. Желателно е размерът на блока след изображение да е точно равен на размера на блока преди изображение. На UNIX системи (Solaris, AIX, HP-UX, Tru64, UnixWare и др.) трябва да се използва 8K. На Linux системи трябва да се използват 4KB. Под Windows трябва да използвате 4K, освен ако не увеличите размера на NTFS клъстера, както е посочено в раздела за Windows. Преди да преоразмерите блока за остатъчно изображение, изключете регистрационния файл за остатъчно изображение (ако е бил активиран) и нулирайте регистъра за предишно изображение:
rfutil foo -C aimage end proutil foo -C truncate bi
Размерът на блока с остатъчно изображение може да бъде зададен със следната команда:
rfutil foo -C aimage truncate -aiblocksize 8
Размерът на блока е посочен в килобайти.
4.8. Използване на запис на предишни изображения (BIW)
Писачът на предишно изображение е процес за записване на прясно попълнени регистрационни буфери на предишно изображение на диск. Ако този процес се изпълнява, тогава сървърът на базата данни не трябва да извършва тези действия, което му дава повече време за полезна работа. Когато използвате самообслужващи се клиенти, сървърът и клиентът ще бъдат в равни условия, но все пак ще бъдат желателни,така че сървърната част да е заета с непосредствената си работа.
Обърнете внимание, че лицензът за RDBMS на Workgroup не ви позволява да стартирате записващо устройство преди изображения.
Можете да стартирате програмата за писане на изображения преди със следната команда:
Можете да стартирате само един писател преди изображения.
4.9. Използвайте програмата за запис на остатъчно изображение (AIW)
Ако използвате регистриране на остатъчно изображение (и трябва, макар и не от съображения за производителност), трябва да стартирате процеса на запис на остатъчно изображение (AIW). Този процес е предназначен да записва прясно попълнени регистрационни буфери след изображение на диск, така че сървърът да не се налага да го прави. Ако процесът се изпълнява, тогава сървърът на базата данни не трябва да извършва тези действия, което му дава повече време за полезна работа. Когато използвате самообслужващи се клиенти, сървърът и клиентът ще бъдат при равни условия, но все пак ще искате сървърната част да е заета с директната си работа.
Обърнете внимание, че лицензът за RDBMS на Workgroup не ви позволява да стартирате програмата за запис на следно изображение.
Можете да стартирате програмата за запис на остатъчно изображение със следната команда:
Можете да стартирате само една програма за запис на следно изображение.
4.10. Използвайте Asynchronous Page Writers (APW)
Винаги трябва да стартирате поне един асинхронен процес на писане на страници (APW).
Асинхронният запис на страници е фонов процес, предназначен да записва новопроменени блокове от база данни на диск в област с данни. В този случай сървърът не трябва да изпълнява тази задача и модифицираните блокове от данни няма да бъдат изчистени на диска всички наведнъж в края на цикъла на контролната точка. Редица елементи от промоционалното меню отчитат такива записи като прочистени буфери. За повечето проверки този номер трябвада е по-малко от 10.
В повечето случаи изпълнението на един или два от тези процеси ще бъде достатъчно. Твърде много от тях обикновено не причиняват вреда, но твърде много, да речем 50, могат донякъде да влошат производителността, тъй като ще има повече конфликти при достъп до буферния пул.
Обърнете внимание, че лицензът за RDBMS на работната група не ви позволява да стартирате програми за писане на страници.
Асинхронен запис на страница може да бъде стартиран със следната команда:
4.11. Избягвайте режима за един потребител
Почти всички препоръки в тази глава предполагат, че базата данни работи в режим на много потребители. Обикновено, когато използвате база данни в режим на един потребител, нейната производителност ще бъде значително по-лоша.
Когато база данни работи в режим на един потребител, има само една връзка към базата данни и няма споделена област на паметта (вместо това всички структури от данни се намират в личната памет на процеса). Режимът за един потребител има следните недостатъци в сравнение с режима за много потребители:
- Няма асинхронни фонови процеси за запис на данни в региона на данни и регистрационните файлове на транзакциите. Това ограничава производителността.
- Не е възможно да използвате програмата promon или други програми за наблюдение на работата на базата данни.
- Не е възможно да се използват онлайн помощни програми като превключване на активния екстент на следизображение, архивиране на пълни екстенти или създаване на копие на база данни в движение.
3 на най-новите версии на Linux, максимум 2,7 GB 4, което е извън обхвата на тази монография 5 всъщност има едно или две изключения, но не се притеснявайте за тях