Memória konfiguráció - Alapelvek

Az Oracle adatbázis alapvetően memóriában tárol minden információt. Azonban, ha nincs elegendő erőforrás, akkor az operációs rendszer kénytelen átmenetileg kitenni egy részét a merevlemezre, amíg ismét szükség lesz rá. Ez sajnos elkerülhetetlen elegendő memóriával nem rendelkező rendszerek esetében. (Ugye a memória olvasási és írási sebessége nagyságrendekkel gyorsabb, mint a lemezé.) Egy másik probléma pedig, hogy csak a működéshez elengedhetetlen információk vannak a memóriában, az adatok viszont a merevlemezen pihennek(a TimesTen az adatokat is a memóriában tárolja). Ezeket be kell olvasni, ha szükség van rájuk. A gyakran használt adatokat pedig valamilyen stratégia szerint minél tovább a memóriában kell marasztalni, hogy elkerüljük a felesleges I/O műveleteket.
A cél tehát kirajzolódni látszik. Csökkenteni a fizikai írás/olvasás műveleteket amennyire csak lehet akár cache-eléssel, vagy akár az adatblokkok behozásának hatékonyabbá tételével.

Az alapvető memória részek, melyek hatással vannak a teljesítményre:

• Shared pool
• Large pool
• Java pool
• Buffer cache
• Streams pool size
• Log buffer
• Rendezéshez és hasheléshez szükséges memória(saját processz memória)

Automatikus memória kezelés
Alapesetben a telepített Oracle példányunk automatikusan kezeli a rendelkezésére álló memóriát. Ebbe csak nagyon kevés beleszólásunk van. Mindössze a felhasznált memória célméretét (MEMORY_TARGET) és maximumát (MEMORY_MAX_TARGET) szabhatjuk meg, minden más az adatbázis dolga. Elvégzi a területek kiosztását és méretezését az SGA-nak és PGA-nak. Törekszik a legoptimálisabb megoldásra.
Ha mégis úgy döntünk, hogy magunk szeretnénk kezelni a kiosztott memória területeket, akkor érdemes használni a beépített Memory Advisort.

Automatikus osztott memória kezelés
Ha a szerverpéldányunk SGA-ját szeretnénk egyszerűsítve kezelni, akkor ezt megtehetjük egyszerűen. Csupán az SGA_TARGET paramétert kell nullánál nagyobb értékre állítani (ezzel foglalhatjuk le az SGA-nak szükséges területet), utána pedig a STATISTICS_LEVEL-t TYPICAL vagy ALL módba kapcsolni. Ezekkel a beállításokkal az SGA automatikusan szétosztja a rendelkezésére álló memóriát az alábbi területek között: buffer cache, shared pool, large pool, java pool, streams pool. Ha az ezekhez tartozó memóriaterületeket nullánál nagyobb értékekre állítjuk, akkor ezzel a számukra szükséges minimum területet állítottuk be. Ezt figyelembe veszi az adatbáziskezelő a területek szétosztásánál.
Az SGA_TARGET változót dinamikusan is állíthatjuk, ezzel hozzá hangolva az éppen aktuális rendszerműködéshez. Ha az SGA_TARGET-et nullára állítjuk szerver induláskor, akkor a legutolsó beállítások fognak vonatkozni az SGA területeire(buffer cache, shared pool,...). Ezeket azonban személyesen is átállíthatjuk a megfelelő változókkal: DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE. Erről azonban majd később.
Vannak azonban olyan memóriaterületek is, melyekre az automatikus osztott memória kezelésnek nincsen hatása(log buffer, más cache-ek, belső SGA foglalások), azonban az SGA-ból területet vonnak el. Érdemes odafigyelni rájuk.

Memóriaterületek dinamikus változtatása
Ha magunk szeretnénk a memóriaterületeinket kezelni, akkor ezt megtehetjük, de ekkor körültekintően kell eljárnunk. A területek méretének beállítását az alábbi paraméterekkel tehetjük meg: DB_CACHE_ADVICE, JAVA_POOL_SIZE, LARGE_POOL_SIZE, LOG_BUFFER, SHARED_POOL_SIZE. Ezek közül a Log buffer beállítása indítás után nem változtatható meg, a többi viszont dinamikusan kezelhető. A memória foglalás alapegysége az SGA-nak 4MB, amíg 1GB alatt van, felette viszont 16MB. Ezt menet közben nem lehet megváltoztatni. (Egyébként a V$SGA_DYNAMIC_COMPONENTS nézet tartalmazza az aktuális alapegységet.)
Azzal, hogy beállítjuk induláskor az SGA maximális méretét (SGA_MAX_SIZE) korlátot szabunk a teljes memóriahasználatnak. Az ide tartozó komponenseknek nem adhatunk több operatív tárak, mint amennyit kezdetben allokáltunk. Ezért amikor kiszámoljuk, hogy mennyi hely fog kelleni a szerverünk működéséhez, mindig becsüljük kissé túl, hogy ha valamilyen váratlan okból meg kell növelnünk egyes komponensek rendelkezésére álló memória területet, akkor ne kelljen feltétlenül elvennünk valamely máséból, hogy beleférjünk a keretbe.
Segítség a dinamikus újraméretezéshez
Ahhoz, hogy olyan döntéseket hozzunk meg, melyek eredményeként át kelljen méretezni memória területeket, információra van szükségünk az adatbázisunk állapotáról, teljesítményéről, elvégzett műveleteiről. Ebben segítenek nekünk előre definiált nézetek, melyek az alábbiak:

• V$MEMORY_CURRENT_RESIZE_OPS - A jelenleg is futó átméretezési műveletek listáját tartalmazó nézet.
• V$MEMORY_DYNAMIC_COMPONENTS - Az összes dinamikusan állítható paraméter aktuális értéke, beleértve az SGA és PGA méretét is.
• V$MEMORY_RESIZE_OPS - A legutóbbi 800 végrehajtott átméretezési művelet (csak a befejezettek).
• V$MEMORY_TARGET_ADVICE - Hangolási tanácsokat tartalmaz a MEMORY_TARGET paraméter állítására.
• V$SGA_CURRENT_RESIZE_OPS - Az éppen futó SGA átméretezési műveletek listáját jeleníti meg.
• V$SGA_RESIZE_OPS - A legutóbbi 800 végrehajtott SGA átméretezési művelet (csak a befejezettek).
• V$SGA_DYNAMIC_COMPONENTS - Az SGA dinamikus komponenseiről tárol információt. Tartalmazza az indítástól számított összes SGA átméretezési műveletet.
• V$SGA_DYNAMIC_FREE_MEMORY - Az SGA számára fennálló szabad memória mennyiségét tárolja, ha a jövőben át szeretnénk méretezni.

Megfontolások alkalmazás oldalon
A memória konfigurációját természetesen az alkalmazáshoz kell igazítani, azonban ha a memóriahasználatot megfelelően hangoljuk, akkor nagyban csökkenthetjük az erőforrás szükségleteket. Ha hatékonyan használjuk az adatbázis erőforrásait, akkor jobb teljesítményt érhetünk el, mintha ezzel nem foglalkoznánk.
A legjobb teljesítmény elérése érdekében tehát az alkalmazás memóriahasználatát optimálisan kell kezelni, valamint az adatbázis memória struktúráját az alkalmazás igényeihez kell teljesen igazítani. Ha változtatunk az alkalmazáson, akkor újra kell gondolni az adatbázis memória használatát is.
Ha Java kódot használunk, akkor ezzel külön kell foglalkozni, mert az Oracle adatbáziskezelő külön erre a célra fenntart egy memória területet (Java pool).

Az operációs rendszer memóriahasználata
A legtöbb operációs rendszer használja a lapozási technikát. Vagyis ha nincs elegendő memória, akkor valamilyen stratégia szerint kiválaszt egy memóriaterületet és azt a merevlemezre mozgatja, hogy a helyére az éppen aktuálisan futó processz adatai kerüljenek. Ez teljesítmény csökkenést eredményez az operációs rendszer szintjén. Ebből a megközelítésből tehát a teljesítmény növelése csak a rendelkezésre álló memória növelésével érhető el. Vagy a felesleges processzek leállítása, így szabad memóriaterülethez juthatunk.
Az SGA szemszögéből nézve nagyban rontaná a hatékonyságot, ha egy szerverpéldány egy része nem férne el a memóriába (pl. sok más folyamat miatt) és így folyton használni kéne a lapozást. Ezért ajánlatos valamilyen módon az SGA-t mindig a memóriában tartani. Ennek egy módja, ha van elég hely ugyan a memóriában, hogy megparancsoljuk az operációs rendszernek, hogy nem nyúlhat az SGA-hoz. Ezt az adatbázis LOCK_SGA paraméterével állíthatjuk be. Azonban ha ezt beállítjuk, akkor nem használhatjuk a MEMORY_TARGET és MEMORY_MAX_TARGET paramétereket.
Ha megalkottuk a helyes SGA beállításokat az alkalmazásunkhoz, akkor sem szabad megfeledkeznünk a kapcsolódó felhasználókról, mert nekik is szükségük lesz szabad memóriára, hogy elvégezhessék a műveleteket.
Az SGA aktuális állapotáról a SHOW SGA PL/SQL parancs kiadásával tájékozódhatunk.

Forrás: Oracle Database Performance Tuning Guide 11g Release 1 (11.1) - 7 Memory Configuration and Use - 7.1 Understanding Memory Allocation Issues

Memória konfiguráció

A most következő néhány bejegyzésben szeretném bemutatni, hogy adatbázisunk teljesítményét miként befolyásolja a rendelkezésre álló memória mennyisége és kiosztása. Először csak az alapelveket tisztázom, majd belemegyek az SGA részletes konfigurálási lehetőségeibe. Itt a Buffer Cache, Shared Pool, Large Pool és Redo Log Buffer tárgyalásáról lesz szó, majd kitérek a PGA beállítási lehetőségeire és használatára is.

Ahhoz, hogy adatbázisunk teljesítménye a lehető legjobb legyen, szükséges a konkrét feladathoz hangolni a rendszer memóriahasználatát. Olvasva ehhez kapcsolódó dokumentációkat mindig feltűnt egy mondat: "Oracle recommends using automatic memory management to manage the memory on your system." Ha szót fogadnék neki, akkor mondhatnám, hogy kész is vagyunk, mert alap esetben így működik adatbázisunk, és nekikezdhetünk a rendszer tervnek. De nem hiszek neki, ezért tovább olvasom ezeket a dokumentumokat. Rájövök, hogy jól tettem, hogy nem fordultam vissza rögtön az elején, mert rengeteg lehetőségünk van finomhangolni rendszerünket, amitől a rejtett teljesítmény növekedést várom.

HOUG 2008

Lezajlott az idei HOUG konferencia, melyen idén először én is részt vehettem 3 "sorstársam" társaságában. Köszönet érte az Oracle Hungary Kft. -nek és természetesen Sárecz Lajosnak a meghívásért.

A rendezvény ideje alatt plenáris és szekció előadások voltak, de esténként a szórakozás sem maradt el. Minden nap a plenáris előadásokkal kezdődött a nap, de arra az első napot kivéve nem sikerült odaérni, mert az ébredés és reggeli eléggé elhúzódott. Rendszerint az első kávé szünetre, vagy az azelőtti előadásra értünk a helyszínre. Mentségünkre legyen, hogy minket nem a Konferencia helyszínén, a Hotel Azúrban szállásoltak el, hanem 10 percre onnan, a siófoki móló legvégén a Hotel Yacht Klubban.

Visszatérve a konferenciára sok pihenésre nem maradt időnk, mert mindig akadt érdekes előadás, amit nem lehetett kihagyni, így reggeltől(délelőtt) délután 5-6-ig elfoglaltuk magunkat. Utána akadt egy kis pihenő, majd vacsora, ami után rendszerint érdekes programokkal kedveskedtek a szervezők. Itt kiemelném az esténként díjmentesen fogyasztható csapolt Heinekent :) Persze más ital is ingyen volt a résztvevőknek, de én csak ezt próbáltam ki.

Az előadások közül legjobban Hoppán Gergely (Alpha Consulting 1996 Kft.) Blogoljunk és prosperáljunk című előadása tetszett, aki arról beszélt, hogy mi értelme egy szakmai blognak és azt hogyan kell írni ahhoz, hogy minél többen olvassák. A legjobban az a rész tetszett, amikor egy blogot egy nőhöz hasonlított kiemelve a két végletet. Egy céges honlap unalmas, lassan frissülő, száraz. Egy személyes blog szubjektív, abszolút szórakoztató és érdekes. Ennek a kettőnek az ötvözete adja a szakmai blogot, mely szórakoztató céges weboldal. És akkor a hasonlat: "Amikor feleséget választunk, akkor az a célunk, hogy a hölgy legyen egyszerre úrinő is, meg szexistennő is." Ez vitte a pálmát.

Volt még érdekes előadás bőven, de talán Papp Péter (Kancellár.hu) Oracle Hacking háziasszonyoknak című előadását érdemes kiemelni. Az előadás egy demóból állt, ahol megmutatta, hogy kell eltéríteni egy Oracle 10g patchek nélküli rendszert egy távoli gépről. Azt hiszem a hallgatóság majd lefordult a székről amikor már azt is elérte, hogy minden jogot megkapjon az egyszerű felhasználónk. Ültek a teremben sokan, akik ebben a pillanatban legszívesebben felhívták volna céges adatbázisuk adminisztrátorát, hogy azonnal telepítse fel a patcheket... :) Én mindenesetre jól szórakoztam.

Kardkovács Zsolt (BME TMIT) és Benkő Borbála (BME TMIT) közös előadását is volt alkalmam meghallgatni, melyben arról számoltak be, hogy milyen eredményeket értek el a saját magyar szótövesítő rendszerük fejlesztésében. Ennek alapja az Oracle Text technológia, mely lehetőséget ad arra, hogy szövegeket kezeljünk, rendszerezzünk OracleDB alapokon. Az általuk elkészített rendszer a HunLexer, amit egy rövid demón keresztül prezentáltak.

Nagy örömömre szolgált, hogy két előadás is volt TimesTen témakörben, így egy kis betekintést kaphattam a TT ipari környezetben lévő használatáról.

Az első előadást Ökrös Péter (Astron Informatikai Kft.) tartotta Oracle TimesTen for Real Time Business címmel. Az előadás első része a TimesTen technológia ismertetéséről szólt, majd két megvalósítást hozott fel példának, ami Magyarországon egyedülállónak mondható.
Az első példa egy Applikációs adatbázis felgyorsítása a Mavir Zrt.-nél, mely az első magyar TT prodzsekt volt. Ez nem volt egyszerű feladat, mert egy valós idejű vezérlőrendszerből kellett valós idejű konvertálást végezni az alkalmazások számára. Ezt a TimseTen Cache Connect funkciójával valósították meg.
A megoldandó problémák a következők voltak: gyorsabbnak kell lennie (10x, ha már Times<->Ten), tárolt eljárásokat pótolni kellett (mivel a TT nem támogatja), nagy rendelkezésre állás biztosítása Oracle adatbázis tárolt eljárásaival, TT csak valós (materializált) adatokat kezel. A feladatokat sikerrel oldották meg és a rendszert tényleg sikerült felgyorsítani, ha nem is tízszeres sebességre. Tanulságként annyi vonható le, hogy a TimesTen nem minden esetben gyorsít fel egy már meglévő rendszert, főleg akkor nem, ha ehhez nincs megfelelő szakértelem. Viszont, ha hozzáértő szakember készíti el a terveket, akkor jelentős gyorsulásra tehetünk szert.
A második példa egy Ügyviteli Jelentési Rendszer felgyorsítása volt, ahol a fő gondot az okozta, hogy az alkalmazásokhoz nem lehetett nyúlni, tehát egy olyan integrációs megoldást kellett kitalálni, ahol a beillesztett TimesTen réteg transzparensen tudja ellátni a feladatát. Ezt ugyancsak a Cache Connect funkcióval valósították meg. Érdekessége a dolognak, hogy összesen 10 mérnöknap ráfordítással értek el átlagosan 3x sebesség növekedést. Természetesen további ráfordítással és fejlesztéssel a sebesség tovább növelhető.
Az előadás végén még megemlítésre kerültek a TimesTen további alkalmazási területei, mint például a Call Center-ek (azonnali hibafeloldás), telekommunikáció (sms nyugtázás), banki alkalmazások (gyorsabb adathozzáférés).

A másik TimesTen előadást Mészáros András (Allround Informatikai Kft.) tartotta A TimesTen lehetőségei a Magyar Telekom mobil árazó rendszerében címmel. Az előadó arról számolt be, hogy a TimesTennel milyen eredményeket lehet elérni ezen területen. Ez egy tanulmány ismertetése volt, a megvalósítás még várat magára. Szó volt a számlázó rendszer architektúrájáról, komponenseiről és hogy mihez érdemes hozzányúlni ahhoz, hogy teljesítmény növekedést érjenek el. Megemlítette a tervezési döntéseket is, valamint az elvárásokat a fejlesztéssel kapcsolatban. Az előadás végén összefoglalta a vizsgálat menetét és a mérések eredményeit. Természetesen megéri elvégezni az átalakítást a TT felhasználásával. Az előadó megemlítette, hogy a várt eredményeken túl egy pozitív észrevételük is volt, mégpedig, hogy még kedvezőtlen helyzetben is nagyon gyors volt ez megoldás. A mérések alapján jó választás.

Ezeken kívül természetesen még sok előadást meghallgattam a három nap alatt, azonban nem sikerült megszerettetnem magammal a Business Intelligence témát. Pedig én megpróbáltam. Összesen három ilyen témájú előadást hallgattam végig, de kivétel nélkül mindnek a vége felé már kapartam a falat. Volt amelyikről ki kellett jönnöm. Na de mindegy.
Összességében nagyon hasznos volt a konferencia és örülök, hogy elmehettem. Remélem jövőre is részt vehetek, talán már a másik oldalon...

Tervezés és fejlesztés a teljesítmény nevében - Rendszer architektúra

Rendszer architektúra

Hardver és szoftver komponensek

Hardver

Egy rendszer hardver elemeit érdemes úgy méretezni, mint ahogy egy hídépítő mérnök tervezi a hidat. Mivel a költségekkel mindig számolni kell, ezért nem érdemes bizonyos részeit a legjobb és legdrágább anyagokból építeni, míg más részeit olcsóbb, és így gyengébb elemekből. A híd teherbírása a leggyengébb rész teherbírása lesz. Sokkal erősebb hidat lehet építeni, ha valamiféle egyensúlyt keresünk az egyes részek minősége között, és próbáljuk ezt egymáshoz közel tartani és a költségeket ennek megfelelően minimalizálni.

Egy számítógépes rendszer tervezésénél is pontosan ez a helyzet. Törekedni kell tehát az egyensúlyra és úgy méretezni leendő rendszerünket.

Az alapvető hardver komponensek:

• Processzor
• Memória
• I/O alrendszer
• Hálózat

Szoftver

Úgy, mint a számítógépeknek is vannak közös hardver elemei a szoftvereknek is vannak funkcionálisan közös elemeik. Ha az alkalmazásokat szétválasztjuk funkcionális elemekre, jobban megértjük ezek működését.

A legtöbb alkalmazás tartalmazza az alábbi komponenseket:

• Felhasználói felület
• Üzleti logika
• Felhasználói kérések és erőforrás foglalás
• Adat és tranzakció kezelés

Felhasználói felület

A felhasználó ezen a felületen keresztül kommunikál a programmal.

Feladatai:

• Kép megjelenítése
• Adatgyűjtés és kézbesítés az üzleti logikai rétegnek
• Bejegyzéseket érvényesíti
• Navigál az alkalmazás állapotai között

Üzleti logika

Az alapvető logikai egység. Ettől függ, hogy az alkalmazás milyen feladatot lát el. Ha ebben hiba van, annak helyreállítása nagyon költséges is lehet. Procedurális és deklaratív részek alkotják.

Feladatai:

• Adatmodell átültetése relációs sémába
• Kényszerek definiálása a relációs sémában
• Az üzleti logika megvalósítása függvények segítségével

Felhasználó kérések és erőforrás foglalás

Ez a komponens minden alkalmazásban szerepel. Egy több felhasználós rendszerben az erőforrás foglalást elvégzi az adatbázis szerver, vagy az operációs rendszer. Azonban nagyon nagy alkalmazás esetén a rendszer tervezőjének meg kell bizonyosodnia, hogy nagy terhelés esetén is garantálható a normális működés.

Az ide tartozó feladatok:

• Adatbázis-kapcsolat kezelése
• Lekérdezések végrehajtása
• Kliensek kezelése
• Egyensúlyban tartani a felhasználói kéréseket a hardver erőforrások függvényében

Adat és alkalmazás kezelés

Ezért főleg az adatbázis szerver és az operációs rendszer felelős.

Feladatok:

• Egyidejű adathozzáférés garantálása zárak és tranzakciók segítségével
• Optimalizált adathozzáférés indexek és cache segítségével
• Gondoskodni az adatmódosítások logolásáról
• Érvényesíteni az adatokra vonatkozó szabályokat

A szükségleteknek megfelelő helyes rendszer-architektúra beállítása

Meghatározni a helyes rendszer architektúrát nem egyszerű feladat. Sokszor többször át kell gondolni a tervezés különböző fázisaiban. Alapvetően megkülönböztetünk interaktív (pl. árusító rendszerek, email szerverek, web alapú alkalmazások…) és processz alapú (pl. csalás detektáló rendszer, direct mail) rendszert. A legtöbb esetben ez utóbbit könnyebb fejleszteni, mert itt hiányzik a felhasználói felület. Azonban itt a feladat is nehezebb, mert a célok nem annyira tiszták, mint egy felhasználói igényeket kielégítő rendszerben. A tervező mérnökök nincsenek hozzászokva nagy adatmennyiségek kezeléséhez.

A rendszer architektúra meghatározása nem tartozik a determinisztikus dolgok közé. Ahhoz, hogy valaki jó tervező mérnökké váljon, rengeteg tapasztalatra van szükség. Azonban álljon most itt néhány kérdés, melyek megválaszolása elősegítheti a helyes architektúra kialakítását.

Elsődleges kérdések:

• Hány felhasználó fogja használni a rendszert?
  Majdnem minden alkalmazás besorolható az alábbi kategóriák egyikébe.

· Nagyon kevés felhasználó egy keveset használt számítógépen
Ez általában egy felhasználót jelent. A tervezésnél a fő szempont az, hogy ez az egy felhasználó a lehető legjobb hatékonysággal tudja használni az alkalmazást, minimális válaszidővel. Ezeknek az alkalmazásoknak a felhasználói ritkán zavarják egymást és az erőforrás ütközések is minimálisak.

· Közepesen sok és sok felhasználó egy vállalati, osztott alkalmazásban
Ebben az esetben a felhasználók száma limitált és megjósolható, például egy vállalat alkalmazottai. Azonban a megbízhatóság döntő szempont a tervezésnél. A felhasználók közös erőforrást használnak, így nagy terhelésnél is fontos a válaszidő kordában tartása.

· Megszámolhatatlan felhasználó fér a rendszerhez az interneten keresztül
Ennél az alkalmazástípusnál fontos a mérnöki hozzáértés, mert gondosan meg kell tervezni az erőforrások elosztását. Ha elfogy valamelyik hardverkomponens tartaléka, akkor könnyen kialakulhat ’bottleneck’, ami a rendszer instabilitásához vezethet. Az ilyen alkalmazásokhoz szükséges terhelés kiegyenlítés, állapotmentes alkalmazás szerver, és hatékony adatbázis kapcsolat menedzsment.

• Milyen lesz a felhasználói hozzáférés?
  A felhasználói felület megválasztása a web-alapú technológiáktól egészen a saját kliens programig.
• Hol vannak a felhasználók?
  A felhasználók közötti távolság szabja meg bizonyos esetekben, hogy mennyi lehet a késleltetési idő. De a felhasználók helye még azt is befolyásolhatja, hogy melyik napszakban legyen a karbantartás, és mikor legyen feltétlenül elérhető.
• Mekkora a hálózati sebesség?
  A hálózati sebesség nagyban befolyásolja azt, hogy mennyi adatot célszerű küldeni egyszerre a felhasználói felület és az adatbázis szerver között. Ha lassú a sebesség, akkor nem érdemes minden egyes új információt átküldeni, hanem csak tömbösítve, mert akkor nem lesz szétdarabolt a bevitel. Ha pedig gyors a hálózati elérés, amit használunk, akkor megoldható az, hogy a szerver gyorsan reagáljon minden bevitelre.
• Mennyi adathoz férhet hozzá egy felhasználó és ebből mennyi csak olvasható?
  A lekérdezett adatmennyiség kihat a tervezési döntésekre. A tervezőnek meg kell bizonyosodni róla, hogy a válaszidő az adatbázis méretétől nem függ. Ha az alkalmazás jórészt csak lekér adatokat, akkor az adatreplikáció és adat elosztás egy jó megoldás a fő szerver tehermentesítésére (terhelés megosztás).
• Mekkora a maximális megengedhető válaszidő?
  Ezt felhasználója válogatja. El kell döntenünk, hogy aki használni fogja a rendszert, annak milliszekundumos válaszidőre van szüksége, vagy elegendő akár másodperces nagyságrend is.
• Szükség van-e napi 24 órás elérésre?
  Az internetről is elérhető rendszerek számára ez kötelező. Azonban a vállalati rendszerek, melyek csak egy időzónában működnek, elegendőek csak a munkaidő alatt elérhetőnek lenniük. A maradék időben pedig el lehet rajtuk végezni a karbantartási munkákat és átkonfigurálásokat.
• Minden változtatást valós időben kell elvégezni?
  Fontos a tervezéskor eldöntenünk, hogy a felhasználó által kért változtatásokat azonnal végre kell hajtanunk, vagy ráér esetleg később is, aszinkron módon.

Másodlagos kérdések:

• Mekkora lesz az adatbázis?
  Az adatbázis mérete határozza meg a szerver gép erőforrásait. Az olyan szerver, amin nagy adatbázist használunk egy kicsivel nagyobb gépet igényel, mint amekkorára feltétlenül szüksége lenne. Ez azért van, mert az adminisztrációs folyamatok végrehajtási ideje nagyban függ az adatbázis méretétől. Ha nincs elegendő plusz erőforrás, akkor ezek a műveletek nagyon hosszúra is nyúlhatnak.
• Mennyi a szükséges teljesítmény egy művelethez?
• Mik a rendelkezésre állási szükségletek?
• Milyen kompromisszumokat tudunk kötni, ha finanszírozási megszorítások lennének?

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Skálázhatóság

Skálázhatóság


Mit hívunk skálázhatóságnak?

A skálázhatóság egy rendszerképesség, mely azt mondja meg, hogy ha növeljük a folyamat által felhasználható fizikai erőforrások számát, akkor a rendszer mennyivel több terhelést bír el. Ha például egy skálázható rendszerben kétszeresére növeljük a munkaterhelést, akkor az erőforrás felhasználás is a kétszeresére növekszik. Ez nyilvánvalónak tűnik, azonban egy nem skálázható rendszerben ez nem így van, mert ott a terhelés növelése megsokszorozhatja az erőforrás szükségleteket. Az okok a következők lehetnek: megnövekedett zárhasználat, operációs rendszer terhelése, rosszul megtervezett lekérdezések és indexek növelhetik az I/O műveletek hosszát… Azonban az is okozhatja a lassulást, hogy elfogyott a memória, vagy lemezterület, a hálózati kapcsolat sebessége nem tudja kielégíteni az igényeket, vagy akár annyi folyamatot indítunk (és memóriát foglalunk számukra), hogy az operációs rendszer nem tudja kezelni őket.


A rendszer skálázhatósága

Napjaink legtöbb adatbázis rendszerének meg kell felelnie annak a követelménynek, hogy a nap 24 órájában elérhető legyen az interneten. Ha kezdetben egy kisebb rendszert is tervezünk, szem előtt kell tartani azt is, hogy később szükség lehet jóval nagyobb munkaterhelést is elbírnia. Tehát jól skálázhatónak kell lennie a kezdetektől fogva. Ha erre nem szentelünk elegendő figyelmet, akkor a későbbiekben szembesülhetünk azzal a problémával, hogy a megnövekedett igények miatt újra kell tervezni a teljes rendszert, ami az üzleti világban nem biztos, hogy megmagyarázható lépés. Egy rendszer áttervezése miatti leállás költsége elérheti egy rendszer teljes fejlesztésének költségeit.


Skálázottságot befolyásoló tényezők

Egy rendszer megtervezésénél és megépítésénél a szakemberek mindig arra törekednek, hogy a lehető legjobb legyen a skálázhatóság. Ez optimális esetben lineáris skálázhatóságot jelent, vagyis a processzorok duplázásával duplájára nő a terhelhetőség is. Ez azonban elérhetetlen.
Az alábbiakban összefoglaljuk, hogy melyek azok a tényezők, melyek a leginkább befolyásolják a rendszer skálázhatósági képességét.

• Gyenge alkalmazás tervezés, implementáció és konfiguráció.
(Az alkalmazásnak van a legnagyobb hatása a skálázhatóságra.)

• Gyenge adatbázisséma tervezésből adódó drága SQL lekérdezések.
• Gyengén megtervezett tranzakciók okozhatnak zárolási és sorosítási problémákat.
• Gyengén megtervezett hálózati kapcsolat okozhat nagy válaszidőket és nem megbízható működést.

Azonban nem csak a tervezés okozhat gondot, hanem az alkalmazás gyenge implementációja is:

• Rosszul implementál I/O stratégia.
• Éles környezetben megváltozhat a végrehajtási terv a tesztkörnyezethez képest.
• Nagy memória-igényű alkalmazások nem fordítanak elegendő figyelmet a nem használt memória felszabadítására.
• Nem hatékony memória használat okozhat gondokat a virtuális-memória kezelésben. Ez hatással van a teljesítményre és hozzáférhetőségre.

• Hibásan méretezett hardver komponensek

• Napjaink hardver árai kisebbek, mintsem azzal foglalkozzunk, hogy megvegyük-e még ezt az 1Gb RAM-ot a 10Gb-os rendszerünkbe vagy sem. Azonban a túl nagy hardver kapacitás elfedheti a skálázhatósági problémákat, így csak később vesszük észre azokat, mikor már nagyobb gondot okozhatnak.

• Hardver komponensek korlátozása

• A hardver nem tökéletesen skálázható. A legtöbb multiprocesszoros gép közel lineárisan skálázódik, azonban egy meghatározott processzorszám után a növekedés ugyan összességében folytatódik, de arányaiban nem annyival, mint eddig. Ha tovább növeljük, akkor pedig elérünk oda, ahol a teljesítmény növekedés megtorpan, sőt vissza is esik. Ez a viselkedés nagyban függ a munkaterheléstől és az operációs rendszer beállításaitól.

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Beruházási lehetőségek megértése

Beruházási lehetőségek megértése

Napjainkra a hardverek ára meglehetősen olcsó. Nem okoz gondot, ha a rendszerünk teljesítménye nem megfelelő, akkor vásároljunk még memóriát, vagy háttértárat, esetleg lecseréljük egy több processzort használó rendszerre. Azonban ez hosszútávon nem vezet jóra, mert a teljesítménycsökkenés okát nem szűnteti meg, ami a legtöbb esetben a nem megfelelő tervezésnek köszönhető. A rendszer kapacitásának növelése után, ha az alkalmazásunk tovább növekszik, akkor a probléma rövid időn belül újra jelentkezni fog,
Vannak olyan esetek is, amikor további memória, háttértár beszerzése nem növeli a teljesítményt. Vásárlás előtt mindig érdemes átgondolni, hogy alkalmazásunkban minden folyamat a lehető legoptimálisabban működik-e. Az adatbázisunk sem futtat feleslegesen sok, erőforrást felemésztő műveletet. Hosszú távon sokkal hatékonyabb megoldás ezen hibák kigyomlálása.

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Bevezetés, Oracle módszertan

Bevezetés


Optimális rendszerteljesítményt elérni nem könnyű. Ahhoz, hogy ez sikerüljön, már a tervezési fázisban is figyelembe kell venni teljesítmény specifikus szempontokat. Meg kell hozni olyan döntéseket, melyek a későbbiekben segíthetnek hangolni rendszerünket.

Ez az összefoglaló segít megérteni a teljesítményre hatással lévő rendszerkomponensek óvatos kezelésének fontosságát. Megpróbál egy olyan körképet adni, aminek a segítségével tudatosabban fejleszthető egy rendszer a teljesítmény nevében.



Oracle módszertan


A rendszer-teljesítmény napjainkban egyre fontosabb dolog, mert a számítógép rendszerek folyamatosan nőnek és egyre összetettebbeké válnak. Ehhez még az is hozzájárul, hogy az Internet egyre nagyobb szerepet játszik ebben, mert ezeket a komplex megoldásokat még össze is kapcsoljuk, így létrejőve még ennél is nagyobb bonyolultságú rendszer.

Az Oracle mérnökei kialakítottak egy módszertant, melyet, ha figyelembe veszünk a tervezés és fejlesztés ideje alatt, akkor a végül sokkal jobb teljesítményt érhetünk el, mint ezt nélkülözve. Ez a leírás ismerteti ezeket az alapelveket.

A teljesítmény-stratégiák hatékonysága különbözőek lehetnek attól függően, hogy milyen profilú rendszert építünk. Például egy operatív rendszernek más teljesítmény mutatókkal kell rendelkezni, mint egy döntést támogató adatbázis-rendszernek. Ez a módszertan segít összpontosítani azokra a területekre, melyeknél szükséges a nagy hatékonyság, a célokat figyelembe véve.

A teljesítmény mindig egy konkrét rendszerre van hangolva, mely hardver és szoftver elemekből, erőforrásokból állnak. A teljesítménycsökkenés általában ezeknek az erőforrásoknak a kimerülése miatt következik be. Ha elfogyott valamely rendszerkomponens összes tartaléka, akkor a rendszer nem méretezhető tovább és visszaesik a teljesítmény is.

Ez a módszertan figyel a teljesítmény maximalizálására. A tervezésnél nagy figyelmet fordít az erőforrásokkal való óvatos bánásmódra. A kész rendszernél pedig segít feltárni az erőforráshiányt vagy erőforrás-ütközést, hogy ezeket megszűntetve növelhessük rendszerünk teljesítményét.

Forrás

Tervezés és fejlesztés a teljesítmény nevében

Az elmúlt időszakban nem voltam valami termelékeny, ám nem töltöttem az időm hasztalan. Mint korábban írtam, ebben a félévben az Oracle adatbázis teljesítmény kérdéseivel szeretnék foglalkozni. Ennek fényében egy kis Oracle architektúra gyorstalpalón vettem részt Nyárády Péternek köszönhetően, aki blogjában írt a témáról elég kimerítően. Ezek után a hivatalos Oracle Database Concepts dokumentációban lévő Memory architecture részt tanulmányoztam át.
Péter javaslatára ezután a Performance Tuning Guide-ot lapozgattam, melyből egy összeállítással is elkészültem. Ebben a félévben az irodalomfeldolgozáson kívül egy rendszertervet is össze kell állítani. Ehhez szeretnék segítséget nyújtani ezzel az összefoglalóval, melynek témája a címben is szereplő "Tervezés és fejlesztés a teljesítmény nevében". Még nem készültem el vele teljesen, de ami eddig formába van öntve, azt közzé teszem.
Holnap (2008. április 3. csütörtök) a közös konzultáción az előadásom vezérvonala is ez a téma lesz, erről fogok beszélni. Remélem a rendszerterv megalkotásához segítséget tud majd nyújtani.