2008. április 2., szerda

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.

2008. február 23., szombat

Új lendület

Legutóbbi bejegyzésem óta elég sok idő telt el. Lezárult a vizsgidőszak, síeltem, elkezdeődött az új félév. Erre a rövid szünetre szükség volt, hogy átgondoljam milyen irányba folytassam az Önálló laboratóriumot. Marton József konzulensemmel több levelet is váltottam ez ügyben, és személyesen is leültünk megbeszélni, hogyan tovább. Több lehetőség közül választhattam, de a legszimpatikusabbnak azt tartottam, hogy erre a félévre kicsit félreteszem "pihenni" a TimesTen-t, de azért nem megyek olyan messzire a memóriára alapozott rendszerteljesítménytől, mert az Oracle11g memória kezelését, és konfigurálását fogom vizsgálni. Egészen pontosan azt fogom gorcső alá venni, hogy meghatározott típusú adatbázisterhelés mellett milyen SGA beállításokkal érhető el a legnagyobb teljesítmény.
A jövőben ezt a témát és az előző félévben feldolgozott témát szeretném minél közelebb hozni egymáshoz. De ez még csak egy ötlet, addig még rengeteg midnen történhet.
Ebben a félévben a labor már négyszer(8) annyi kreditet ér, mint az előzőben(2). Ennél fogja több munkára is szükség lesz, hogy az elvártaknak megfelelően teljesítsek. A konzulenseim hozzáállása is sokat változott ebben félévben. Itt gondolok arra, hogy 3-heti rendszerességgel lesz közös konzultáció, ahol az Oracle technológiát feldolgozó társaság egy részének(mindig más) kell előadást tartania az elvégzett munkájáról.
Mint az fent olvasható, a blogom címe is megváltozott. Ezentúl az "Éberhardt Péter Oracle blogja" címet viseli, mert már nem csak speciálisan TimesTen-nel kapcsolatos bejegyzések vannak benne, hanem sokkal áltlánosabb, Oracle-el kapcsolatos dolgok is.

2008. január 22., kedd

Triggerek

Múlt héten kaptam egy feladatot a munkahelyemen, amit úgy gondoltam, hogy egy trigger elkészítésével tudom a legegyszerűbben és leghatékonyabban megoldani. Ez pont jó alkalom volt arra, hogy kicsit közelebbről is megismerkedjek vele. Az eseménygyűjtő rendszerünk egy Microsoft SQL Server 2005 adatbázisra épül, így a T-SQL nyelvet kellett használnom.
Álljon itt egy áttekintés a triggerekről, melyeket megpróbálok rendszertől függetlenül bemutatni. Természetesen kitérek a Microsoft által használt T-SQL és az Oracle által használt PL/SQL közötti szintektikai és szemantikai különbégekre, valamint szó lesz a TimesTen és a triggerek kapcsolatáról is.

Trigger
A trigger nem más, mint egy tárolt eljárás, melynek lefutását egy esemény vált ki. Az események típusa szerint háromféle trigger létezik. DML(Data Manipulation Language), DDL(Data Definition Language), logon trigger.
DML trigger akkor aktiválódik, ha valamilyen DML esemény történik. Ilyen események az INSERT, UPDATE vagy DELETE , melyeket táblákon vagy nézeteken hajthatunk végre.
DDL trigger akkor aktiválódik, ha DDL esemény történik. DDL események a CREATE, ALTER, DROP műveletek végrehajtása.
A logon trigger akkor tüzel, ha valamilyen LOGON esemény történik.
Egy trigger egy esemény előtt, helyett vagy után futhat le. Ennek a segítségével jóval összetettebb megszoírtásokat készíthetünk az adatbázisunkhoz, így növelve a biztonságot és a megbízhatóságot.
Ha például az adatbázisunkban csak olyan eseményeket szetnénk tárolni, melyek nem öregebbek 1 évnél, akkor ezt egy helyettesítő triggerrel szűrhetjük. Csak azt az adatot engedjük beilleszteni, melynek időpontja 1 évnél fiatalabb.
A triggerek logikailag az adattáblákhoz tartoznak. Egy táblához és egy eseményhez tőbb trigger is tartozhat, azonban ezeknek a tüzelési sorrendje nem meghatározható.
A trigger által generált visszatérési értékek, pl. egy SELECT utasítás eredménye a sikeres lefutás után átadódik a kiváltó eseménynek, mely úgy kezeli, mintha az ővé lenne. Ha azt szeretnénk, hogy ez ne jelenjen meg, akkor a trigger elején be kell állítani a NOCOUNT-ot ON-ra. (SET NOCOUNT ON) Ezzel természetesen szelektálhatunk, hogy mi az az érték, amire szükségünk van, és mi az, a mire nincs.
Rendelkezésünkre áll két átmeneti tábla a triggerben. Az egyik az INSERTED, a másik a DELETED. Az INSERTED táblába kerülnek az új értékek, ha INSERT, vagy UPDATE művelet hatására fut le a trigger. A DELETED táblában pedig a régi adatok lesznek, melyek DELETE vagy UPDATE hatására töltődnek be.
Trigger létrehozása. Csak a legalapvetőbb beállításokat mutatom be, bővebben itt lehet róluk olvasni:
T-SQL CREATE TRIGGER
PL/SQL CREATE TRIGGER
A két esetben a szintaxis majdnem ugyan az. Én a T-SQL -t használva mutatom meg egy trigger
létrehozását.

DML trigger készítése:
CREATE TRIGGER [ schema_name . ]trigger_name
ON { table | view }
[ WITH [ ,...n ] ]
{ FOR | AFTER | INSTEAD OF }
{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }
AS { sql_statement [ ; ] [ ,...n ] | EXTERNAL NAME }

[ schema_name . ] - a schema, melyben az adattáblánk is
szzerepel trigger_name - általunk
megadott trigger név
ON { table | view } - megadjuk, hogy melyik táblához,
vagy nézethez akarjuk létrehozni
a triggert
::= [ ENCRYPTION ] - ennek segítségével meggátolhatjuk,
hogy ha az adatbázis replikálják,
akkor ez a trigger ne kerüljön át
[ EXECUTE AS Clause ] - lehetőségünk van a triggert egy
meghatározott felhasználó nevében
futtatni
FOR - a trigger a kiváltó esemény előtt fut le
AFTER - a trigger a kiváltó esemény után fut le
INSTEAD OF - a trigger a kiváltó esemény helyett fut le
INSERT|UPDATE|DELETE - kiválaszthatjuk, hogy milyen
eseményre triggereljünk, tetszőleges
kombináció előállítható
AS sql statement - az AS utáni rész maga a trigger feltétel
teljesülése esetén végrehajtandó rész
ha
több műveletből áll, akkor BEGIN .. END
közé kell rakni

Pl.:
use teszt_db
CREATE TRIGGER ins_trigger
ON tabla1
INSTEAD OF INSERT
AS
BEGIN
IF ((SELECT id FROM inserted)>10) INSERT INTO tabla1 (id, nev)
VALUES (SELECT id, nev FROM inserted)
END

Rövid magyarázat: Ez a trigger csak abban az esetben engedi beillszteni
az új sort, ha az "id" > 10.


A DDL- és logon-trigger létrehozása nagyon hasonló felépítésű a DML-
hez, csak ott nem a táblához, hanem egy adatbázishoz vagy szerverhez
rendeljük hozzá a triggert és helyettesítés nincsen.

Érdekes kérdés, hogy egy többsoros INSERT esetében mi történik. A
trigger csak egyszer hívódik meg, vagy minden sorra külön külön. Na
itt különbség van a PL/SQL és T-SQL között. A PL/SQL-ben lehetőség
van megadni, hogy többsoros INSERT esetén a trigger soronként tüzeljen,
míg T-SQL esetében erre nincs mód.
Ennek a korántsem teljes beszámolónak a végén meg kell még említenem,
hogy a TimesTen-ben nincs lehetőség triggerek létrehozására. Ennek
az lehet az oka, hogy triggerek kezelése nagyon megbonyolítaná a
tudatosan leegyszerűsített működést.

Pár hasznos link:
MSDN - CREATE TRIGGER (T-SQL)
hu.wikipedia.org - trigger
wikipedia.org - trigger
psoug.org - jó példák tipikus alkalmazásokra (PL/SQL)

2008. január 19., szombat

Oracle Blogger Dinner

Lezajlott az első Oracle Blogger Dinner, melyet Sárecz Lajos szervezett. A találkozó lényege az volt, hogy azok az emberek, akik ma Magyarországon blogot írnak valamilyen Oracle technológia témában, azok személyesen is találkozhassanak. 2007 őszéig összesen két ilyen blog létezett, melyet Izsák Tamás ír Oracle Application Express témában(apexblog.hu), valamint Darvas Tamás OracleDBA témában(OracleDBA). Az előző(őszi) félévben viszont a bloggerek száma megsokszorozódott, mivel az Önálló Labor keretein belül az Oracle technológiát választóknak feladatuk volt az is, hogy munkájukról blogot készítsenek, hogy ezzel tájékoztassák konzulensüket és az érdeklődőket - itt elsősorban az Oracle Hungary kapcsolattartójára gondolok, Sárecz Lajosra. Ez a blog is ennek köszönheti létét. Összesen körülbelül a félév során 16 blog működött aktívan melynek összetétele 2 "öreg motorosból" (Izsák Tamás és Darvas Tamás), 13 TMIT(Távközlési és Médiainformatikai Tanszék) hallgatóból és 2 AUT(Automatizálás és Alkalmazott Informatikai Tanszék) hallgatóból állt.
A találkozó előtt Sárecz Lajos megkért, hogy tartsak egy rövid beszámolót a félév során szerzett TimesTen tapasztalataimról. Így a többiek is megismerkedhetnek más Oracle technológiákkal, nem csak azzzal, amivel ők maguk foglalkoztak.
Az első Oracle Blogger Dinner-en körülbelül 8-10-en jelentünk meg. Ez számomra meglepő volt, mert azt hittem, hogy ezt a lehetőséget senki nem hagyja ki. Bár gondolom azok, akik nem jöttek el, biztos más elfoglaltságuk akadt, ami fontosabb volt.
Az összejövetel címe vagy neve egy kis magyarázatra szorul. Oracle Blogger Dinner. Az Oracle az egyértelmű. Szerintem a Blogger is. Ez a kettő már igazából meghatározza azt a közösséget, akinek szól ez az egész. A Dinner pedig csak arra utal, hogy miközben találkozunk, pizzát eszünk. :) A találkozó pontosabb címe az lehetne, hogy Oracle Blogger Pizza Meeting. De ez nagyon viccesen hat és elveszíti minden komolyságát az ügy. Így sokkal hivatalosabban fest a Dinner. Szóval Oracle Blogger Dinner.
Az összejövetel bemutatkozással kezdődött kerekasztal formájában. Mindenkinek el kellett mondania, hogy mi motiválta, hogy Oracle termékkel foglalkozzon az ÖnállóLabor keretein belül. Valamint arról is kellett beszélnie, hogy mi a véleménye a blogírásról. Van-e haszna, vagy abszolút hülyeség.
A beszélgetés nagyon jó hangulatban zajlott, mindenki kifejthette a véleményét a témával kapcsolatban.
A találkozó második fele pizzázással és előadással telt, melyet én tartottam a TimesTen memória adatbázisokról. Azt hiszem sikerült megértetnem a technológia jelentőségét és lényegét. Azt, hogy a hallgatóság mennyire unatkozott, azt nem tudom, de a végén kapott kérdésekből arra következtetek, hogy azért valamennyire figyeltek.
A találkozó bő két órán át tartott, ami alatt azt hiszem senki nem unatkozott. Ha mégis, akkor remélem a pizza valamennyire lekötötte a figyelmét. :D Megegyeztünk, hogy a következő, azaz a második Oracle Blogger Dinner negyed év múlva kerül megrendezésre. Akkor is lesz (remélem) pizza, eszmecsere és előadás, melyet ha jól emlékszem Tóth László és Szabó Gergely tart a .NET és OracleDB kapcsolatáról.

A magyar Oracle blogok listája, melyet Sárecz Lajos gyűjtött össze:
http://gyurak.blog.hu/
http://oraclefarkas.blog.hu/
http://vasvari.blog.hu/
http://bozsik.blog.hu/
http://sumeghy-onlab.blog.hu/
http://benyo-oracle.blogspot.com/
http://bblog.notice.hu/
http://pglabor.blogspot.com/
http://rai-labor.blog.hu/
http://orabusiness.blogspot.com/
http://oraoptimization.blogspot.com/
http://www.apexblog.hu
http://eptentimes.blogspot.com/
http://oracle-with-dotnet.blogspot.com/
http://oracleondotnet.blogspot.com/
http://oracle.blog.hu/