mission critical app fejlesztése miben min?:D

UNIX haladó

Guru testvereim a kernelekben.

Javaslatokat varok op.rendszer-adatbazis kezelo- programozasi nyelv kombinaciokra.
A fejleszteni kivant app 7X24-ben mukodne.
Nem ipari kornyezetben.
Erdekelne a velemenyetek.

Udv

lzskiss aka jimmyPhD

  • 3115 megtekintés

( rozmar564 | 2009. 01. 08., cs – 18:49 )

azert tobb info nem artana a projektrol - sokat billent a merlegen.

( eax | 2009. 01. 08., cs – 18:53 )

Pl. az erlang/OTP-t (meg hozza a mnesia nevu DBM-et) direkt ilyesmire talaltak ki, de nem artana tudni, hogy ez kb. mit fog csinalni, es milyen architekturat kepzelsz el hozza.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

+1

redhat enterprise linux + oracle + javaEE, IBM JVM-el

Mission critical linux valyon él még?

Esetleg ADA ill. IBM DB2 játszhat még.

A 7X24 alatt ötkilences rendelkezésre állást értenek? Ilyen tényleg létezik, de ugye hajlandóak megfizetni az _igen_ borsos ártá. Ehhez külön szoftverfejlesztési modell kell, helyességbizonyítás ezerrel (pi kalkulus és barátai), átlagban minden programozó mellé tíz tesztelő és öt code auditor.

update: trusted solaris lemaradt

--
The Net is indeed vast and infinite...
http://gablog.eu

És ha az app elhal egy adott bemenetre akkor mi leszen? gondolom nem csak attol Mission Critical mert mindig mennie kell, hanem mert mindig jol is kell működnie. Persze ide nekem a keresztetháromszöggel ha nem van igazam.

### ()__))____________)~~~ ###
#"Ha én veletek, ki ellenetek?"
#ASUS eee 900 Ubuntu 8.10 // fluxbox //

Nem kell hozzá exploit, elég, ha bizonyos szabályos bemeneti mintára nem tesztelt a rendszer, és elhasal rajta. Láttam olyan rendszert, aminél az adatbázis tartalmazott három mezőt, melyekből legalább kettő fel volt töltve, és a három mezőbe elvileg nem kerülhetett azonos érték. Került. Ha TOAD-ból futtattam a query-t, simán lefutott, ha az appszerveren keresztül jött elvileg ugyanaz az kérés, akkor beledöglött. Elvileg tesztelték, gyakorlatilag me mi sz0ptunk vele egy csomót...

Nem erre gondoltam, hanem hogy ez a kapasbol ujrainditgatas azzal a jelentekeny hatrannyal bir, hogy ha valaki meg szeretne torni az adott daemont, de az exploitja nem sikerult tokeletesen megbizhatora (vagy pl. beint az ASLR), akkor lehetosege van probalgatni, amig el nem talalja a jo visszateresi cimet, heap layout-ot, vagy masegyebet. Ellenben ha az adott daemon kapasbol ledoglik, es ugymarad, az nem csak a probalkozasokat limitalja, hanem jelentosen noveli annak az eselyet is, hogy a logolvasasben kevesbe jeleskedo rendszergazdanak is feltunjon a dolog.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

5-9 bullshit, azt barmibol ki lehet hozni. redundancia, redundancia, redundancia

lol, ugye azt vágod, hogy az 99.999%-os rendelkezésre állás évente ~ 1 perc leállást jelent

Ezt nem fogja a hobbi pc az asztal alatt hozni, akkor sem, ha tíz diszk van raid 1-ben.

--
The Net is indeed vast and infinite...
http://gablog.eu

lehet tobb ilyet terveztem mar, mint Te [hiszed] :)

elosszor is, az 5-9 az evi 5.26 perc.

masodszor a dzsunka vas jo sw arch mellett nem problema (csak sok kell belole), persze jobb a normalis vas.

harmadszor: ki beszel itt raid1rol? nem torolheto rekordokrol, normalis dbrol beszelunk (master-master replikacio, elosztott tranzakciokezeles, foreign key mindenutt [egyszoval normalisan megtervezve]), aztan a keresek megoszlanak tobb frontend gep kozott..

de errol orakat lehetne meselni, mint ahogy szoktam is a megfelelo helyeken.

Minden olyan szoftwaretermek aminek koze van az IBM-hez kerulendo(draga es nem megbizhato, es a magyarorszagi csapat nem ert hozza), egyebkent redhat enterprise linux + oracle + javaEE -vel egyetertek, de nem ezektol lesz valami mission critical, hanem attol, hogy nagyon ertenek ezekhez a termekekhez. Tehat amihez nagyon ertenek a fejlesztok, uzemeltetok.

Az AIX nem szoftwaretermek, olyan nincs hogy bemegyek az IBM boltba, és kerek 2 db AIX-ot, az AIX-ot a vassal adjak, es tenyleg megbizthato. En ugymond a dobozos termekekre gondoltam, hosszu evek tapasztalata, alapjan arra jutottam, hogy az IBM termekek soran hatalmas erofeszitesek es hosszu tunningolas nagy szakertelem, utan lehet olyan stabilitast és magbizhatosagot elerni, amit a tobbi termek alapbol tud.

( lzskiss | 2009. 01. 08., cs – 21:45 )

Tavfelugyeleti rendszerrol lenne szo.
Folyamatos uzem.
ADA nekem is szimpatikusnak tunik mondjuk.
Oracle az nekem hazai palya, de szeretnem valami koltseg es energiahatekony modon megoldani.
Koszonom egyebkent a hozzaszolasokat.

udv

lzskiss aka jimmyPhD

OpenBSD 4.1/i386

( uid_4656 v | 2009. 01. 09., p – 00:01 )

Umm, bármiben?

Mert a nagy rendelkezésre állást úgy fogod elérni, hogy:
- a rendszered megvan több példányban, akár a Föld távoli pontjain, ha valamelyik ponton meghal, akkor még mindig ott van a többi
- az adataidat nem egy példányban fogod tárolni, hanem több példányban, és ha valahonnan elveszik, akkor még mindig megvan máshol
- operációs rendszerként lehetőleg többfélét is alkalmazol, valamelyik csak működni fog
- bármelyik programozási nyelvet is választod, ugyanazokat az elveket fogod követni a program megtervezésekor és kivitelezésekor, mint pl.:
- adatot soha nem törlünk, csak érvénytelenítünk (azaz az adatbázisnak nem küldünk DELETE SQL utasítást, esetleg extrém kritikusságú esetekben, pl. orvosi robotok esetében UPDATE-et sem)
- ha igazán kritikus a dolog, akkor pl. a bemeneti adatok validálását megcsináltatod három példányban három különböző csapattal modulként, és a modulok többségi szavazással döntik el, hogy elfogadják-e a bemeneti adatot egyáltalán (illetve extrém esetben mindegyik modulnak vétójoga van)

Meg hasonlók. Ajánlom az ő könyveit:

http://www.comp.lancs.ac.uk/computing/resources/IanS/

Vagy pl. ezt tőle:

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/…

"
● The cost of producing fault free software is very
high. It is only cost-effective in exceptional
situations. It is often cheaper to accept software
faults and pay for their consequences than to
expend resources on developing fault-free software.
"
Kerdezonek vajon ilyen kell ?

Az egyszeru halandok szamlajank kezelese hasznalt banki rendszerek tobbsege eleri ezt a szintet ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Az egyszeru halandok szamlajank kezelese hasznalt banki rendszerek elerik ezt a szintet ?"

Nem, mert azok tul bonyolultak hozza. Olyasmire erdemes itt inkabb gondolni, ahol a szoftver hibaja kozvetlenul embereleteket veszelyeztet - fekrendszer-vezerles, repulogepen a fly-by-wire rendszer, es hasonlok.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( zsolt | 2009. 01. 09., p – 08:55 )

Érdekes...
Unit tesztekről, teszt-vezérelt fejlesztésről és acceptance tesztekről nem hallott itt senki?

( lzskiss | 2009. 01. 09., p – 09:03 )

Milyen op. rendszer legyen az alap?
Red Hat Linux?
NetBSD?
Varom a szavazatokat:)

udv

Laszlo Zsolt Kiss aka jimmyPhD

OpenBSD 4.1/i386

Azert kerdezgetem kernelhivo testvereimet, hogy elkeruljem az altaluk mar elkovetett hibakat
tevedeseket.
Azt gondolom az egesz nyilt forraskod mozgalomnak talan a tapasztalatcsere az egyik legfontosabb
alappillere.
Egyebkent pedig annyit tennek meg hozza, hogy a bolcsesseg kezdete az alazat.

Udv

Laszlo Zsolt Kiss aka jimmyPhD

OpenBSD 4.1/i386

Igen, x86 mellett legyen sparc IS.

Nem tudom lejött-e abból amit eddig írtam, de NEM azt javaslom, hogy futtasd a rendszeredet windowson, ahogy azt sem javaslom, hogy futtasd linuxon, és azt sem javaslom, hogy futtasd NetBSD-n. Ezzel szemben azt javaslom, hogy futtasd egyszerre több operációs rendszeren is a programodat, lehetőségek szerint úgy, hogy át tudják venni egymás feladatait, és az életben maradt node el tudja végezni a feladatokat. Így ha az összes linux bedől egy bug miatt, akkor a Solarisod életben fog maradni.

Ugyanezt javaslom az architektúrával is, az adatábisaiddal is és minden mással kapcsolatban is.

Feladat: van egy rendszered, ami 99%-os rendelkezésre állást biztosít. Van egy másik rendszered, aminek két változata van, az egyik 98%-os, a másik meg 97%-os rendelkezésre állást biztosít. Melyiknek nagyobb a valószínűsége az alábbiak közül:
- a 99%-os rendelkezésre állású rendszer egy adott pillanatban működik
- a 98%-os és a 97%-os rendelkezésre állású rendszer közül legalább az egyik egy adott pillanatban működik?

Ha nem tudod a választ a kérdésre, akkor mielőtt elkezded az operációs rendszerek, adatbázisok és programozási nyelvek témakörét feszegetni, azelőtt javaslom, hogy az ilyen jellegű kérdéseket rágd át alaposan.

> van egy rendszered, ami 99%-os rendelkezésre állást biztosít. Van egy másik rendszered, aminek két változata van, az egyik 98%-os, a másik meg 97%-os rendelkezésre állást biztosít.

Hmmm. Arra azért kiváncsi lennék, hogy milyen számítások vezetnek arra, hogy jobb a 98%+97% -os rendszer, mint a 99%+99% -os.

> ha az összes linux bedől egy bug miatt

Saccolj rá valami valószínűséget, mert anélkül nem lehet figyelembe venni.

A megoldás kulcsa, hogy két hajszálpontosan ugyanolyan oprendszer ugyanakkor fog összedőlni. Tegyük fel, hogy van olyan hiba, hogy február 29-én elszáll a rendszer, mert nem képes kezelni ezt a dátumot. Ha két ugyanolyan rendszered van, akkor mindkettő február 29-én fog meghalni, és nem marad, aki szolgáltasson. Ha két különböző rendszered van, akkor kevésbé valószínű, hogy ugyanaz a hiba jön ki rajtuk ugyanakkor. Így lesz a 99+99 kevesebb, mint a 98+97. De mondok egy vadabbat: a 99+99 kevesebb, mint a 99 - abban az esetben, ha csak és kizárólag ennek a komponensnek a rendelkezésre állását nézzük, mivel a 99+99-hez kell egy olyan modul is, ami tudja, hogy melyik modul él, és ez a plusz modul is meghibásodhat.

A linux kapcsán én saját magamnak évi 1 óra kieséssel szoktam számolni, ami 99.99%-os rendelkezésreállásnak felel meg. Annak a valószínűsége, hogy az összes linux egyszerre bedőljön nagyon alacsony, mondjuk 0.0001%. Viszont ha csak ezzel számolsz, akkor már el is érted az eredeti kérdésben szereplő rendelkezésre állást, azaz az összes többi komponensnek (hardware, adatbázis, saját fejlesztésű program (!!!)) magasabb rendelkezésre állást kell nyújtania. Ebben nem bíznék, hogy így lesz.

> hogy az összes linux egyszerre bedőljön nagyon alacsony, mondjuk 0.0001%

OK, számolgassunk. Nekem az jött ki, hogy: 99.98990% > 99.940% Vagyis a két hajszálpontosan ugyanolyan 99% -os rendszer rendelkezésre állása nagyobb, mint a 98%+97% -os egymástól eltérő rendszer rendelkezésre állása.

Tegyük fel, hogy az egyszerre történő bedőlés miatt büntit kell fizetni, mondjuk 20M Ft-ot. Ezek szerint a bünti várható értéke: 20 Ft.

Jól számoltam?

Alaposan korbejartam azert a kerdeseket nyilvan.
Igaz, hogy jomagam a bsd alapu rendszerek haza tajan erzem igazan otthon magam.
Sok evig egy Tricord Enterprise 5000 server volt amit uzemeltettem, windoze futott rajta,
ennel egyedibbet eleg nehez talalni.
Van tudas mindenfele op. rendszerrel, adatbaziskezelovel, meg programozasi eszkozzel is.
Ezert elsosorban tapasztalaton alapulo kombinaciok erdekelnenek.

Udv:

Laszlo Zsolt Kiss aka jimmyPhD

OpenBSD 4.1/i386

( turul16 v | 2009. 01. 09., p – 18:57 )

gentoo + mysql/postgreaql + C/C++

Tobb parameter pontosabb valaszt ad.

Mennyi love van vasra ? Mennyi munka ora van fejlesztesre? Milyen jelegu alkalmazasrol van szo, hanyas szintu fejlesztok fognak rajta dolgozni/hanyan...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( larpad | 2009. 01. 09., p – 18:57 )

Szerintem próbálkozz virtualizált cluster megoldással, persze a fenti megoldásokkal együtt. Így jól skálázható rendszert kapsz, ami online hw migrálásra is képes lehet.

( rozmar564 | 2009. 01. 09., p – 23:53 )

C++ - abszolute - az alap! OS - ha nem is RedHat legalabb CentOS - nagyon bekonfiguralva - selinux kikapcsolva.
DB - hm, Oracle ha nagyon terhelt, ha csak light akko' mysql sem rossz.

nem azt irtam, h nem megoldhato, csak hogy ketlem, hogy 9-5 kihozhato belole, akarmennyire is szeretem.

a master-master replikacio erosen hianyzik.

ha nem sw oldalrol nezzuk, egy vmware esx cluster sok geppel megoldja ezt a problemat, termeszetesen enterprise licencel, hogy legyen DRS meg vmotion. de hat ez nem az sw erdeme. :)

a multi-master amugy sem olyan jo otlet a legtobb esetben a potencialis key-clashing miatt.
auto-incrementet meg csak csak meg lehet csinalni, de nem valami rugalmasan skalazhato az eljaras, es meg mindig nem nyujt megoldast az egyeb (primary, unique, foreign key) utkozesekre.
ha olyan sok az iras, hogy 1 vas nem birja el, akkor ketto sem fogja, plane ha vissza is replikalja mindenki mindenkire az osszes irast.
inkabb partitioning/sharding a megoldas.

ps: de persze mysql alatt is meg lehet csinalni a multi-master felallast, csak imho tobb hatranya, mint elonye van.

Tyrael

elosztott tranzakciokkal a key-clashing (szerintem) kikerulheto, bar ez az izolacios szinttol is fugg

en mindig faztam a master-slave replikaciotol, mert ilyenkor a slave csak olvashato, raadasul a kliensnek tudnia kell rola (a mysql proxy meg nincs kesz, ugye?), aztan ha nem tud rola, es dnst allitasz akkor az meg ido. persze, csak epszilon. de ido.

elosztott tranzakciok alatt az XA-t erted?
mondok peldat amire mi nem talaltunk megoldast:
geo cluster jelleggel kontinensenkent akarsz 1-1 mastert(most kezdesnek csak 2 szerverrel peldalozok), hogy ne kelljen nagy latencykkel dolgozni tengerentulrol. koztul multi-master replikacio.
van pl. 200ms replikacios lag a ket master kozott (ez nagyobb tavolsagoknal siman elofordulhat meg akkor is ha amugy nincs is terheles alatt a db szerver).
namost lefut amcsiban 1 keres, ami beszur egy tranzakcioval 1 rekordot:
megnezi hogy van-e mar ilyen, ha nincs beszurja, ha nem volt hiba tol 1 commitot.
mikor lefutott ez a tranzakcio amcsiban, meg 200 secig nem jelenik meg ez a rekord europaban, ergo ez ido alatt ott kis esellyel de beszurodhat egyedi kulccsal egy tok mas rekord, ami miatt inkonzisztens lesz a 2 db, masreszt meg elhasal a replikacio a duplicate key hibatol.
ezt ha jol emlekszem a facebook-os arcok sem tudtak kiokoskodni, ugyhogy ok is letettek a multi masterrol.
van mysql proxy, van hscale, spock proxy, de az applikacio szamara transzparens shardingrol nem tudok, de szepen megvalosithato, ha kizarolag orm alapokon hasznalod.
hscale-be igertek ezt a transzparens sharding dolgot, de meg nincs kesz, nem egyszeru feladat, es nem pici overheadje van, ha egy
select * from table where ... order by field limit 10, 100
tipusu query-t 5 vasrol kell osszeszedni (ez meg parhuzamosithato jol), de utana a reszeredmenyeket mergelni, rendezni, szurni kell. :/

utolso sorodnal a kliensnek tudnia kell rola alatt azt erted, hogy az app szamara nem teheto transzparensse a sharding? ez esetben a valaszom annyi, hogy nekem (meg :D) nem sikerult, de pont ezzel szorakoztam 1-2 hetet par honapja, es valszeg fogok is meg vele a jovoben.

szerk: elleptem aludni, majd holnap folyt kov.

Tyrael

XAra gondoltam, igen.

megoldast hirtelen csak sw szinten tudok elkepzelni, vagy kiterjeszteni egy kicsit az XA -t. amugy ha mar engeded egy tranzakcionak hogy a dirty adatokhoz is hozzaferjen, akkor ott lehet ellenorizgetni dolgokat, es az belefer a 200msbe talan. persze az sws +reteg (vagy a tranzakciokontroller felokositasa) jobb otlet.

igen, azt ertem alatta, h transzparens shardingot akarok. :) meg transzparensen mindent. juzer lassa, hogy db.anyamkinja.hu, es ot ne erdekelje mas.

* en is aludnek, csak nem tudok. baratno mar nagyban alszik. holnap-ma meg 8kor keles. yay. :)

"most nem tudom eldonteni, h komolyan irtad v nem. :)"

Komolyan, bar ironikusan.

"az nbd nem megoldas, tudtommal a (minden i-re): min(fizikai_memoria_az_i._gepben) fuggveny eredmenye hatarozza meg a maximalis tablameretet (legalabbis 5.0ban igy volt)"

Es? HA szempontjabol tokeletesen irrelevans.

"update: kozben rajottem en is, h masra gondoltam. :)"

Ja, az jo, bar ezt meg en nem tudom hova rakni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"c++? AHAH"

Hat, inkabb mint a java.

"selinux kikapcsolva? lol :)"

Ki bizony, az a legjobb, amit az ember tehet vele, aztan mehet a helyere a grsec - bar jo kerdes, hogy hogy jon ez a HA-hoz.

"mysqlbol meg ember legyen a talpan, aki 5-9et kihozza."

ndb megvan?

"ismet szagertonket olvashattak a parent postban :)"

Tokeletesen egyetertek. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"grsec? mission critical helyre? neviccelj mar. alap, hogy a disztrib altal szallitott kernelt hasznalom."

Hat, lelked rajta.

"tolem szopathatod magad a c++al, csak lehet hogy en tized annyi munkaval 20x jobb rendelkezesreallasu rendszert hozok ossze, mint te cppvel."

Az a baj, hogy ez nem linearis. 5 9-est elhiszem, hogy konnyebb elerni javaval, de minel inkabb szigorodnak a kovetelmenyek, annal inkabb csokken az elonye. Aztan mar csak a hatranyai maradnak. :)

Bar, mint emlitettem, en sem C++-al allnek neki, de attol meg az sem "AHAH".

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Érdekes, amit írsz.

Mindenesetre ha már a C++-szal akarsz 5 kilences kódot elérni, akkor a thread-eket lehet, hogy el kellene felejteni.

Legalábbis el kell rajta gondolkozni, hogy hogyan tervezed meg, hogy ne fagyjon és ne is haljon be (meg ha a haverod átveszi a fejlesztését, ő se tudjon nagy kalamajkát csinálni). A pointerezgetést is el kell felejteni és Managed Pointereket használni helyette (ha van rá referencia, akkor él, ha nincs, akkor meg felszabadul).

Szerintem akármilyen C++ programból nem lesz 5 kilences. Eleve úgy kell megtervezni már a kezdet kezdetén.

Meg az exception-ök dobálása előtt is el kell gondolkozni, hogy lesz-e aki végül elkapja...

A 100% branch coverage tesztelésnél meg gondolom alapfeltétel.

> ha már a C++-szal akarsz 5 kilences kódot elérni, akkor a thread-eket lehet, hogy el kellene felejteni.

Érdekes gondolat. Java esetén is el kellene felejteni a thread-eket? Több processzoros gépet hogy kéne kihasználni, ha nem thread-ekkel? Aszinkron IO hiányában hogy lehet jó teljesítményt elérni thread-ek nélkül?

A threadek teljesen kiszámíthatatlanná teszik a program futását.

Ha két mutexed van, az egyik szál megszerzi A-t, vár B-re, a másik B-t, vár A-ra, akkor kész a baj (java-ban is). Ha elfelejtesz lokkolni és az egyik szál felszabadít valamit, amit a másik használ, akkor is elszállhat.

Fejlesztettem már szerver alkalmazást és volt szerencsém olyan hibákhoz, amik 1 millió végrehajtott tranzakció után jöttek elő.
- ezek: vagy rossz szinkronizálás miatt voltak
- vagy a véges erőforrások felélése miatt (memória elfogy, fájl handle-k elfogynak,...)

A fent említett szinkronizálási problémák nem elfogadhatóak. Ha havonta fagy a program, már a hiba reprodukálásához is 1 hónap kell, ami a fejlesztést lehetetlenné teszi, de ahhoz pont elég, hogy az 5 kilences ne teljesüljön...

Sorokat érdemes használni (futószalag, queue, a szálak gyakorlatilag egymástól függetlenül tevékenykednek mindenféle szinkronizálás nélkül).

A GUI programozásnál Qt-ben gyakran van az, hogy többszálú programozás helyett félbehagyjuk az adott rész feldolgozását, de az eseménysor végére berakjuk a folytatást. Amikor összeszámolod egy könyvtár méretét, akkor mondjuk összeadod 100 file méretét, aztán kiszállsz. Az eseménysorban feldolgozódnak a billentyűzet, egéresemények, majd folytatod a következő 100-zal. Reagál a rendszer az egérre, a billentyűzetre is, miközben számol és mindezt csak 1 thread kezeli.

A skálázást meg úgy oldanám meg, hogy 1 szál kezeli mondjuk a páros tranzakciószámokat, a másik a páratlanokat,... Ebben az esetben maximálisan ki lesz a 2 processzorod használva és nem 50%-on futnak a lokkolgatások miatt.

Egyreszt ugy kell megtervezni programot, hogy ilyen szitucaio ne forduljon elo.

Ha sorokat hasznalsz akkor is kell "lockolni", akkar megfelelo atomic utasitasokat hasznalva, neha megsporolhato kerneles (f/)mutexelgetes.

Ha nehezseget okoz free,delete hasznalta akkor javaslom mondjuk a perl -t , az eddig emlitett nyelveknel sok esetben sokkal gyorsabban lehet fejlesztni vele.

(mai szervereknel szerintem inkabb a 8 mag az atlag)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Egyreszt ugy kell megtervezni programot, hogy ilyen szitucaio ne forduljon elo.

Így van. Szinkronizációs hibát tartalmazó programot nehezebb kijavítani, mint az elején megtervezni, hogy ki mikor lokkol. Lehetőleg kevés és rövid lokkolások legyenek (volt szerencsém látni olyan, hogy egyik szál ideje 90%-ában a lokkolás feloldására várt).

> Ha sorokat hasznalsz akkor is kell "lockolni"

Viszont sorokból vannak már kész, stabilra megírt komponensek. És jól ki is tesztelhető.

> Ha nehezseget okoz free,delete hasznalta

Az mindig nehézséget okoz, amikor egyszerre 10 ember dolgozik valamin. Kinek a felelőssége is felszabadítani? A legtöbb hiba ott jön elő, hogy az adatokat egymásnak adogatják és senki sem tudja, hogy most kell-e törölni, vagy nem. Ha meg még hiba is történik a feldolgozás közben, akkor több mint valószínű, hogy valami elfelejtődik.

Amikor szerveren dolgoztam TCP stack szerűséget írtam. A komponensek egymás között dobálgatták az üzeneteket, mindegyik természetesen lokkolt. A végeredmény az lett, hogy egy 4 magos gépen 1.5 processzort teljesen kiterhelt a lokkolgatások miatt.

Persze az sem megoldás, hogy minden üzenethez külön mutexet foglalunk le. Ez egyrészt időigényes, másrészt meg nincs kizárva, hogy a mutexek előbb vagy utóbb szintén elfogynak...

Egyreszt mutexek szamat minimalizalni kell. A mutex nem olcso mulatsag, masreszt letrehozni es megsemiseteni meg dragabb, mint a lockolni /unlockolni, tervezeskor ezt az aprosagot nem art figyelembe venni. (futas kozben, ha egy mod van ra ne keletkezen mutex, indulaskor inkabb)
(Nem mindenutt kell recurzive mutex se, egyes nyelvek errol nem tudnak )

Most ez a skalazhatosag divat, de elofordulnak esetek, hogy tobbet art, mint hasznal, egyreszt bonyolultabb lesz a design, masreszt lehet pont a skalazhatosag beiptese miatt lesz akkora az erroforas igeny, hogy tenyleg keljen. (csak okosan)

A feledatot igyekezni kell ugy felosztani, hogy annak legyen feleloseg felszabaditani aki letrehozza.
En vagy megirom felszabaditast rogton foglalas melle "parban", vagy egy commentet teszek hozza, hogy eppen milyen elmebeteg modon akarom azt memoriat felszabaditani, vagy atmeretezgetni, vagy milyen jo okom van arra, hogy ne szabaditsam fel es milyen valtozasok eseten lesz ez rossz otlet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( lzskiss | 2009. 01. 11., v – 19:21 )

A szoftver lenyege, hogy riasztasi esemeny ertsd betoresjelzes beerkezese eseten
20 masodpercen belul intezkedes tortenjen.
Es ugyfelnek nem igazan magyarazhatod, hogy bocs ujra kellett inditani a gepet,
meg hogy bug van itt ott.

Udv:

Laszlo Zsolt Kiss aka jimmyPhD

OpenBSD 4.1/i386

Egy apro keresztkerdes: ki tudna Garantalni, hogy az altala felvazolt architectura es szoftverkornyezet a fenti kovetelmenyt? Kockare tenned a teljes vagyonod ezert az allitasert? ;) Ez tipikusan RT (soft/hard) feladat, annak minden kinjaval (tomegkiszolgalas, formalis modszerek (pi/rho calculus)). Ha nagyon energiahatekonyt, es megbizhatot akarsz, nezz szet rt-java + soc kornyeken - aztan harom kulonbozo megvalositas - tobbsegi szavazassal ;D

> riasztasi esemeny ertsd betoresjelzes beerkezese eseten 20 masodpercen belul intezkedes tortenjen.

Egyszerű: bejön két riasztás, két útvonalon, két szerverre; a szervereken futó szoftverek nyilvántartják/továbbítják két útvonalon, két intézkedőnek. (Optimális esetben a 2 intézkedőnek 4 riasztás megy ki.)

Full redundáns, sok kilences :-)

( lzskiss | 2009. 01. 12., h – 09:21 )

celhardwaren jon az info.
soros portokon:D

OpenBSD 4.1/i386