Postgresql terheléselosztás (cluster?)

Debian GNU/Linux

Sajnos teljesen kezdő vagyok a témában, viszont szükségem lenne valamilyen fajta terhelésmegosztásra adatbázis szinten.
Postgresql 8.4-es adatbázist használok a Zabbix monitorozó rendszeremhez.
A helyzet az hogy eddig egy IBM system storage DS4300 látta el az összes blade szervert háttértárral, a DS4300 tartalmaz két RAID vezérlőt, ami két akkumulátort igényel (gondolom cache-eléshez). Szóval ezek az akkumulátorok lemerültek, nincs cache és igencsak belassult minden.
A gond az, hogy a postgres adatbázisom kb. totál meghalt. Már az autovacuum funkciót is kikapcsoltam de még mindig haldoklik.
Egyszerűen képtelen feldolgozni az I/O műveleteket cache nélkül.
Ezért gondoltam hogy talán érdemes volna valamilyen cluster megoldás után nézni.

Sajnos ebben egyáltalán nincs tapasztalatom.

A gond ott kezdődik, hogy ha több különféle gépen tárolom mondjuk az adatbázist, akkor hogyan fogom tudni lementeni?:)
Vagy ebben az esetben minden gépen ugyan az az adatbázis van, és szinkronizálják egymásról magukat? ill. a lekérdezések okozta terhelés oszlik meg a gépek között?
Érdekelne ennek az elvi logikája is, hogy hogyan lehetne kivitelezni azt, hogy az adatbázist viszonylag könnyen tudjam menteni, a terhelés pedig több gép között osztódjon el.

Bocsánat ha h*lyeségeket írok de sajnos tényleg nincs tapasztalatom clusterekkel kapcsolatban. Annyit tudok csak hogy ez valamiféle terhelésmegosztás.
Ha valaki tudna ezzel kapcsolatban leírást küldeni vagy ötletet, linket stb. azt nagyon megköszönném!

  • 6255 megtekintés

( spider | 2012. 10. 04., cs – 11:06 )

Találtam egy táblázatot ezzel kapcsolatban: http://www.postgresql.org/docs/8.4/static/high-availability.html

NAS van, azt használhatnám úgy hogy iSCSI-val vagy NFS-el felcsatolom mondjuk "/mnt/var2"-be és hozhatnék létre új clustert ami a "main cluster" másolata, de fizikálisan már ezen a NAS-on van rajta???
a kérdés az, hogy hogyan lehet rávenni a zabbixot, hogy ő egyszerre több adatbázis klónból (clusterből) is lekérdezheti az adatokat?
(vagy ezt a postgresql automatikusan megoldja?)

DRBD-ről is hallottam már, ill. használok zabbix_proxy-t ez pedig használja a heartbeat-et és a DRBD-t
zabbix_proxy esetén ugye csak ideiglenesen tárolja lokálisan az adatokat a zabbix_proxy, ha van kapcsolat a fő szerverrel,
akkor automatikusan küldi az adatokat a fő szerver adatbázisába
ez sajnos nem segít (szerintem) azon a problémán hogy túl sok az I/O művelet a fő szerveren

A fent linkelt táblázat többi oszlopát (PITR, Slony, pgpool-II, Bucardo, Synchronous Multimaster Replication) sajnos nem ismerem.

A teljes terhelést nem csak a zabbix hozza össze.
Azon a 4 diszkből álló tömbön amin a zabbix is van, összesen kb. 6 szerver osztozik.
Igaz hogy azok a szerverek nem okoznak ilyen szintű terhelést mint a zabbix.

egyébként 181 hoszt 6574 elem 1977 trigger és másodpercenként 87,42 mérés
+ 8 térkép és grafikonok + 2 IP felderítés ill. 5 képernyő

ez azért nem olyan brutális mennyiség szerintem

Ha iops-ban nagy étvágyú alkalmazás húzza a diszkeket, akkor nagyon is. Lehet persze bbwc-t, meg revodrive-ot, ssd-t belerakni, de bármelyik turbósító kütyü elpukkan (szokott olyat tenni...), akkor szopórollerezés következik. És egy mérő/monitorozó rendszernél pláne gond, mert nem fogja tudni az elvárt/beállított sűrűséggel mérni a felügyelt paramétereket.

Proxy szerűen. Az alkalmazás felé transparens. Ezt adod meg mint postgres szerver. A configjaban pedig be tudod allítani, hogy működjön. Az egyik mód a replikáció. Ekkor minden insert,delete,update műveletet elküld az összes beállított backend servernek. A selecteket pedig elosztva futtatja. Ha egy kiesik, akkor azt érzékeli és akkor oda nem küld. Tehát replikál is és load balance is. A konfigja nem túl bonyolult, könnyen emészthető.
Doksi van az oldalán az is jó.

( johans | 2012. 10. 04., cs – 12:05 )

Nem lenne egyszerűbb és sokkal olcsóbb kicserélni a két akkumulátort, mint cluster építésébe fogni tapasztalatok nélkül, ami a végén úgy se fog működni?

(Hint: ha 1 géppel és write-back cache-el ki lehetett szolgálni megfelelően az igényeket, write-back cache nélkül meg nem, akkor alapvetően az IOPS a szűk keresztmetszet, nem a RAM/CPU. Több gépet betolva több RAM-od meg CPU-d lesz, de a storage backend még mindig ugyan azt az IOPS-ot tudja. Mivel nem ott bővítettél, ahol az üvegnyak van, és a felépített rendszer bonyolultabb lesz, jó eséllyel nem hogy gyorsabb rendszert nem kapsz, hanem 10-20%-kal lassabb lesz az eredmény a végén.)

Az akkumulátorok ki lesznek cserélve, a gond az hogy a jövőben amikor lemerül az akku, akkor mindig meg fog halni a zabbix.
Ez szerintem nem túl jó dolog. Ezért gondoltam arra, hogy az adatbázis legyen több gépen egyszerre.
Van több gép is amin Linux fut, és szinte 0 kihasználtsági szinten üzemelnek (szünetmentest monitorozok pl.).
Ezek a gépek is besegíthetnének kicsit a saját winchesterük szabad kapacitásával és sebességével.

Egyébként pedig szívesen képzem magam, ez is egy ilyen lehetőség szerintem.

Eeegen, mondjuk nekem megvan a velemenyem az eles szerveren kiserletezgetokrol, meg is tartom magamnak.

En peldaul inkabb arra torekednek, hogy valahogy erzekeljem (akar idomeressel is) hogy az akksi lemerul, es meg ido elott riasszak. Mert ez pl. sokkal fontosabb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Éles a szerver, de mivel adatbázis mentés van ezért nincs nagy gond ha elszáll a szerver.
Most amúgy sem tudom használni a zabbixot, és sajnos 3-4 nap mire kihozzák a csereaksit,
szóval a következő néhány nap alatt szintén használhatatlan lesz a szerver

és mivel valószínűleg legközelebb is a bejelentéstől számított 3-4 nap lesz az aksicsere, ezért célszerű volna ezt a gondot áthidalni

de akkor talán soha nem tanulok meg clustert konfigurálni :D
pedig ha jól értelmezem a dolgot, akkor a cluster gyorsít a működésen :)
a zabbix weboldala jó ideje lassú, főleg az SQL lekérdezéseknél
pl. amikor ki kell rajzoltatni egy grafikont
ebből én arra következtetek, hogy lassan éri el az adatbázist
egy picit szívesen gyorsítanék rajta

igazából az volna a jó ha a monitorozó rendszert szinte el sem lehetne pusztítani
bármi van az mindig működjön... ha nincs áram és nincs net, még akkor is küldjön egy SMS-t
ha becsapódott egy meteor a szerverszobába ő még akkor is küldjön róla jelentést :)

sajnos ezt a zabbix_proxy és a node sem tudja (vagy csak én nem tudok róla)
talán majd egy újabb verziójú szerver tud cluster üzemmódban működni
addig is azért az adatbázist clusterben használnám

Legelső lépésként akkor talán el kellene dönteni, hogy mi a fontos:

- a működő rendszer biztosítása
- a saját tudásod bővítése

Persze a kettő mehet egymással párhuzamosan is, csak én nem gondolom, hogy a cluster az egyetlen (pláne nem a legjobb) megoldás ebben az esetben.

Ha még sosem volt adatbázis cluster a kezed alatt, nem biztos, hogy egy valóban fontos rendszerrel kéne kezdeni. Clusterben például tipikus probléma az adat-inkonzisztencia (split-brain állapot, stb...) , nem tudom ennek a lehetőségével számoltál-e, illetve hogy ez mekkora problémát jelentene a rendszeretek esetében.

Kicsit olyan ez mintha kidurrant volna az autód kereke (ki kéne cserélni a gumit) ehelyett raksz bele egy turbót. Így ugyanolyan gyorsan fog tudni menni, de valójában egy felesleges komplexitást vittél a rendszerbe a rossz alkatrész cseréje helyett.

--
Gábriel Ákos
http://i-logic.hu

Eloszor meg kellene tanulnod problemat megoldani, szerintem.

Nem az a baj, hogy boviteni akarod a tudasodat ugy, hogy egy Pg clustert konfiguralsz, hanem az, hogy ezt egy total irrelevans problemara akarod benyujtani, mint megoldas. Az akksis problemadra a helyes megoldas az idoben cserelt akksi, pont. Ehhez nem igazan lehet egy betut se hozzatenni.

Aztan talan folytassuk ott, hogy egy monitorozo rendszer akkor elpusztithatatlan, ha minel egyszerubb, minel kevesebb a hibalehetoseg benne, es - minel egyszerubben ujratelepitheto. Namost egy cluster pont az elso es utolso pontokat serti meg. Bonyolultta es nehezen ujrahuzhatova teszi a rendszert. Ugyanis ha nem tartom szem elott azt, hogy a rendszernek egyszeru felepitesunek es egyszeruen javithatonak vagy ujratelepithetonek kell lenni, akkor fenysebesseggel lehet eljutni az ekes latin "Quis custodiet ipsos custodes?" kerdesig, hozzavetolegesen: "Es ki orzi az orzoket?". Ki fog vigyazni a Zabbix mogotti Pg cluster epsegere? Egy masik monitorozo rendszer? Es azt ki fogja felugyelni? Szoval nem igazan egyszerusiti az ugyet.

Szerintem ebben a problemakorben elobb legyen egy faszan mukodo Zabbixed, es parhuzamosan csinalj egy faszan mukodo Pg clustert - de a kettot ne kosd ossze, amig valamilyen mas indok (mint peldaul sebessegnovekedes, vagy terhelescsokkentes) nem indokolja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ennyi gond van egy PG clusterrel?

Alapvetően nem félek a teszteléstől, van VMware-es exportom a zabbix szerverről, ill. friss adatbázismentésem.
Úgy hallottam hogy a 9.1-es PG már tudja a clustert mindenféle kiegészítő alkalmazás nélkül.
Ez sem eléggé megbízható?

Értem én hogy az írás nem lesz gyorsabb, de a lekérdezések csak gyorsabbak lesznek clusterben nem?
Ha a lekérdezések gyorsabbak lesznek, akkor az már csak megnöveli a weboldal sebességét is...
Főleg a grafikonok kirajzoltatásai lassúak.

Egyébként ha van 1 adatbázis clusterben, az egyik az A controllerre a másik a B-re kötött storage-on figyel, akkor kisebb az esély arra, hogy mindkettő egyszerre haljon meg nem?:) Máris kivédtem a lemerült aksi problémáját. Ráadásul RAID 5-ös diszkekről beszélgetünk mindkét esetben.
Már csak az a kérdés hogy a PG cluster elkészítése és üzemeltetése mennyire macerás.
Ha nincs vele sok baj, és viszonylag könnyen helyreállítható akkor szerintem nincs itt semmi probléma :)

De ha az ele kotott load balancer doglik meg, akkor ugyis mindegy. Es itt jon az orzok orzoje effektus a kepbe.

Egyebkent meg barmilyen cluster maceras tud lenni.

Illetve szerintem nem jott at a mondanivalom. Olyan problemara akarsz PG clustert eroltetni, amire 1) nem ez a megoldas 2) a szemelyes vagyaidon kivul nincs logikus indok mellette.

Nem azt mondom, hogy felj a PG clustertol, csak ne egy monitorzo rendszer ala rakd.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Értem amit írtál, és nem is az aksicserét akarom kikerülni vagy áthidalni ezzel a megoldással.
egyértelmű hogy az aksit ki kell cserélni, és legközelebb lehetőleg a lemerülés/elromlás előtt ki kellene cserélni

A clusteres téma egyszerűen csak érdekel... ha nem érdekelne, akkor nem volnék informatikus

szóval vagy ezen a szerveren (vagy ennek egy másolatán) esetleg egy másik szerveren szeretném letesztelni a működését
így lehet tanulni, ha nekiállok összerakni
lehet hogy most nem logikus, de kerülhetek olyan helyzetbe hogy szükségem legyen erre a tudásra amit most megtanulhatok

egyelőre most nincs másik szerver amit tesztelhetnék :)
de ha adsz egy ötletet hozzá, akkor nekem az is jó, azért gondoltam erre, mert viszonylag komoly mértékben használja a zabbix az adatbázist
ha összerakok egy akármilyen szervert, ami nincs ilyen szinten kialakítva, az nem fog reális képet mutatni arról hogy milyen is lenne ez éles működés közben

mentéseim vannak, bármikor csinálhatok másolatot/visszaállítást a zabbixról

a gyakorlatban is van :)
én csináltam a telepítést és én találtam ki a mentést és legalább 10x visszaálltam már adatbázismentésből :)
nincs mitől félnem... persze azért hogy ne legyen kiesés lehet készíteni egy másolatot a szerverről és azt macerálni
egyébként mint írtam most is kb. 3-4 napig nem fog működni a szerver
ettől még azért tudunk létezni :)

Ugye azt is érted, hogy az írási műveletek nem "nem lesznek gyorsabbak", hanem amiatt, hogy egy insert/update esetén 2x annyi adatot írsz fel (2 cluster node-ot feltételezve), sokkal lassabbak lesznek?

Másrészt az komoly, hogy single path-on vannak bekötve a szerverek a storage-ba? Ha részleteznem kell, hogy ez miért probléma, akkor ne építs clustert.

Az akkumulátorok ki lesznek cserélve, a gond az hogy a jövőben amikor lemerül az akku, akkor mindig meg fog halni a zabbix.
Ez szerintem nem túl jó dolog. Ezért gondoltam arra, hogy az adatbázis legyen több gépen egyszerre.

Nagyon jól látod a problémát! Viszont abszolút hibás következtetést vontál le belőle. Az akku lemerülésétől azért lesz lassú a rendszered, mert a diszkegységed lelassul (nem szabad neki cache-elnie, mert akku híján áramszünetnél elveszne a cache tartalma). Nem a számítógép processzora fogy el, hanem az ott malmozik, és vár a diszkegységre.

Ha megduplázod a gépek számát, ugyan megduplázod az amúgy is fölösleges cpu kapacitást (ott fognak üresen ketyegni), cserébe mind a két példány szeretné majd ugyanazt az adatot kiírni, immáron két példányban ugyanazt, de ezzel igazából csak a diszkegység a terhelését fog sikerülni megduplázni, ezért nemhogy nem javítasz a helyzeten, hanem éppenhogy fordítva: tovább rontod az amúgy sem rózsás helyzetet.

Nekem is van egy olyan érzésem, hogy itt kicsit fordítva ülünk a lovon.
Ami biztos: 8.4-es postgres-el nem érdemes cluster építésbe fogni, nincs benne natívan.
A 9.1-ben már van, én azt próbálnám.
Nincs vele éles tapasztalatom, de úgy érzem idén erre is sor fog kerülni :)

--
Gábriel Ákos
http://i-logic.hu

lehet hogy keverem a témát... amikor 1.8.6-ról frissítettem a zabbixot 2.0-ra, akkor az adatbázist át kellett gyúrni, ehhez volt egy script ami felpatchelte, így utólag leesett hogy az adatbázist még nem frissítettem 8.4-ről sosem. :)
no szóval szerintetek a 8.4 mentését be tudom tölteni a 9.1-es adatbázisba?:)

8.4 pg_dump -ot 9.1 pg_restore -ba simán.

De:

9.0 és 9.1 release notes-t el kell olvasni, ha jól emlékszem valami default implicit konverziók kikerültek a 9.1-ből, ezeket vagy vissza kell tenni, és akkor a viselkedése nem változott, vagy a query-kbe a konverziókat bele kell explicit írni.
Nézd meg a zabbix release notes-ét, hogy melyik pg-vel kompatilibis.

--
Gábriel Ákos
http://i-logic.hu

( nagysa v | 2012. 10. 05., p – 13:53 )

Nem értem, hogy miért akarjátok lebeszélni a pg cluster építésről.
Megvan minden eszköze, (virtuális gépek stb.) hogy tanuljon.
Adjatok inkább tanácsokat, hogyan csinálja!

ember! :) van adatbázismentés és vmware export
ha ebből nem tudok visszaállni akkor semmiből...
másrészt írtam már hogy 10x minimum le lett tesztelve a visszaállás
és azt is írtam hogy csinálnék egy másolatot az élesről és azt macerálnám
de jelenleg ez az éles szerver olyan kamu riasztásokkal szórta tele a postaládámat hogy öröm volt nézni
néhány óra alatt 50 riasztást kaptam (és még mázlim volt hogy nem kaptam 150-et)
szóval offon van az egész úgy ahogy van :)
majd ha kicserélik az aksit a storage vezérlőben akkor újra feléled a zabbix is
de ha már 4-5 nap leállás sem kritikus, akkor gondolhatod hogy akár megcsinálhatnám az egészet kis túlzással kézzel előről is :)
na de ennél több eszem van, külön ki is exportáltam a hosztcsoportokat
tehát ha nem működik a mentés és nem működik a vmware export sem, akkor még mindig meg tudom csinálni az alap telepítést 1 óra alatt
+ vissza importálom a hosztcsoportokat
még a térképeket és a képernyőket is vissza tudnám hozni
egyedül az eljárások vesznének el
azzal 1,5-2 órát biztos el lennék...
viszont akár hogyan is számolom, a legnagyobb önszivatásom esetén is max 3-4 óra melót csinálnék magamnak
ami persze nem kellemes de ez már a nagyon nagyon pesszimista eset...
normál esetben 20 perc alatt visszatöltöm az exportot és minden megy tovább (közben meg csak várnom kell kicsit, mást úgy sem tudnék csinálni)

szóval ki szivatja magát és mivel?:)

Most kimeletlenul oszinte leszek: mindenki letojja magasrol, hogy mid van.

Ez hozzaallas kerdese, hogy eles szerverrel nem jatszunk. Akkor sem, ha lehetne. Mint ahogy az ember nem dugja a kettoharmincba az ujjat csak azert, mert lehet, es mert ugyse razza meg (ahhoz melyen van az erintkezo).

Alapvetoen a hozzaallasod rossz, hogy en majd jatszok ezzel a geppel. Igy nem szabad hozzaallni dolgonak, mert nem fogsz felelos embernek tunni tole.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

ohh barátom! hányszor mondjam el hogy csinálok másolatot az élesről, kap egy másik IP-t és kikapcsolom a riasztásokat
aztán mehet a tesztelés...
az éleshez hozzá sem nyúlok!
de ezt már kb. 5x leírtam!

célszerű volna a lekérdezések jó részét is kikapcsolni

egyre inkább úgy látom hogy a cluster nekem nem lesz megoldás

valahogy az adatbázist kellene feldarabolnom
talán egy zabbix node-ot vagy proxy-t lehet úgy konfigurálni hogy saját adatbázisban tárolja a saját lekérdezéseit
ebben az esetben lehetne több kisebb szerver egy közös weboldallal
és persze annak a valószínűsége is kicsi hogy minden node egyszerre áll meg
alapvetően volt valami gondom a node-okkal, de már nem emlékszem hogy mi volt az
(talán éppen pont adatbázist nem tudtam alájuk varázsolni)
a proxy saját adatbázissal dolgozik, de az csak pufferként működik, hálózatszakadás esetén ideiglenes tár,
amúgy 1-2 másodpercenként küldi az adatokat a központi adatbázisnak.

Te szívattad magad azzal, hogy nem lett lecserélve időben az aksi. Az gondolom nem újdonság a számodra, hogy normális vezérlő az aksi állapotáról is tud pár dolgot. Az, hogy 4-5 napig nem megy a monitoring, és ez "nem gond", az megint csak a hozzáállás hibája - vagy kell a monitoring, és akkor akár nagyobb időközönként (1-2 perc helyett 5-10 percenként), de menjenek az ellenőrzések (és akkor nem szívsz azzal, hogy fals riasztásokat generál, mert nem képes a DB-t elérni).

Szóval első, és legfontosabb dolog szerintem az lenne, hogy ha fél/negyed/sokad teljesítménnyel, de működjön a monitoring, és verni a tamtamot, hogy ezzel a rendelkezésreállás, illetve az üzemeltetők reakcióideje jelentősen megnő, ergo nagyonsürgősendegyorsan legyen aksi a vezérlőhöz.

majdnem minden szerverhez lett egyéni riasztás beállítva, a zabbix még mindig tesztelés alatt áll, ezeket az egyéni megoldásokat váltaná ki hosszabb távon,
viszont jelenleg még nincs katasztrófa ha a szerver nem működik néhány napig
ezért is írtam hogy tesztelhetek ezen is
a hangsúly azonban az "is"-en van, és most leírom hatodszor is, hogy csinálok másolatot az éles szerverről, és a másolaton tesztelek!

azt pedig te sem gondolhatod komolyan hogy 8000 elemet kézzel át fogok paraméterezni hogy az adatbázisba ne kerüljön annyi adat és csökkenjen az írás olvasás a winyón

egyébként én 1 éve dolgozom ennél a cégnél... az hogy nem volt riasztás beállítva a DS4300-hoz nem az én hibám
talán valaki olyan embernek kellett volna erről gondoskodnia aki már 10-15 éve van a cégnél

a tamtamot hiába verjük, közölték hogy 3-4 nap legrosszabb esetben 1 hét mire tudnak aksit szerezni (az IBM mondta hogy max 1 hét)

1 éve diplomáztam, nincs még sok tapasztalatom, viszont próbálok fejlődni
nagy kihívás egyedül összerakni egy monitorozó rendszert tapasztalatok nélkül
ráadásul úgy hogy nem ismertem a cég felépítését
ennyi idő alatt ennyire futotta

Ha mind a 8k elemnek egyedileg van beállítva az időzítése... No mindegy. Amit leírtál, az azt jelenti, hogy a Zabbix nem éles, hanem tesztelés alatti megoldásnak tekinthető. A másolaton azt csinálsz, amit jólesik - pl. meg lehetne nézni, hogy mennyire szuboptimálsan vannak felvéve az egyes service-ek/check-ek - ennél jóval okosabb a Zabbix ugyanis :)

Ja, ha az admin felületről kidumpolod a konfigot, és ésszel(!) átírod a fájlt, majd visszatöltöd, máris meg van oldva az időzítéses problémád. Szerintem.

És egy jótanács: a sértődött válasz nem jó, pláne hétfőn ne húzd fel magad :)

igyekszem...

van egy érdekes hibaüzenetem:
"INFO: task postgres:2004 blocked for more then 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message"

mit jelenthet ez?

az hogy egy service vagy check mennyire szuboptimális az alatt mit értesz?:)
és hogyan tudom ezt ellenőrizni?

A hibaüzenet pontosan azt takarja, amit ír: 120 másodpercnél hosszabb ideig volt blokkolt (pl. i/o-ra vár) állapotban a 2004-es PID-del bíró postgres processz.
A "szuboptimális" vagy sem megjegyzésemmel arra céloztam, hogy a template, csoport és hasonló dolgok mennyire vannak jól kitalálva, mennyire használod, használjátok ezeket? Ha még nem annyira nagyon, akkor itt az ideje :) Kevesebb check nem lesz tőle, de üzemeltetni, konfigurálni egyszerűbb lesz.
És persze a "mindent a maximális sűrűséggel" igényeket is érdemes kordában tartani - pl. az agent verzióját nem kell percenként lekérdezni :)

( andrej_ v | 2012. 10. 05., p – 17:34 )

Nem olvastam végig a szálat, de alapvetően én az alkalmazás oldalról indítanék és a PostgreSQL-nél csak a replikációt vetném be. Mivel a diszk IO szűk, ezért mindenképp több tömbre kéne bontani a postgresek fizikai elhelyezkedését. Az alkalmazásban pedig az olvasó műveleteket egy serverpool-ból vehetné az azt kezelő réteg, míg az írási műveletek mindíg egy helyre mennek. Ez természetesen abban az esetben megoldás, ha jelentősen több (mondjuk 80-20-as arány nem ritka egy webes alkalmazásnál) az olvasó jellegű lekerdezés, mint az írás.

A RAID akksikat mindenképp töltsd fel, cseréld le, ne hagyd így féllábasan. Jelen esetben már minimális írásos diszk IO lerohasztja az egészet.

Szerk: azt jól értem, hogy iSCSI-val csatolod fel a DS4300-at? Ha ez "sima" 1Gbites iSCSI akkor szénné terhelt adatbázis szerver alá nem egy "editor's choice" választás. :)

Ez természetesen abban az esetben megoldás, ha jelentősen több (mondjuk 80-20-as arány nem ritka egy webes alkalmazásnál) az olvasó jellegű lekerdezés, mint az írás.

Ezek szerint még nem láttál monitorozó programot (belülről). Egy monitorozó alkalmazásnál nem ritka a 20-80, de a 10-90 se. Azaz szinte csak írás van, nagy ritkán olvasunk is valamit.