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.
2008. április 19., szombat
2008. április 12., szombat
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...
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...
2008. április 2., szerda
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?
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.)
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.
- 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.
- 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.
- 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.
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
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
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.
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.
Feliratkozás:
Bejegyzések (Atom)
