Sziasztok,
egy uj adatbázisszervert szeretnénk üzembe helyezni;
A napi oldalletöltés a hozzá tartozó weboldalon 10-14 millio/24h; így meglehetősen adatintenzív a dolog (ez jelenleg is így van; azonban a jelenlegi gép már igencsak csereérett).
Amennyiben hddre esik a választás, az 4 db SEAGATE HDD Server Savvio 10K.5 (2.5" ,300GB,64MB,SAS) lenne; raid10 -ben; azonban SSD -vel nincs tapasztalatunk.
Mennyire tartjátok megbízható megoldásnak az SSD -t, egyáltalán milyen márkát válasszunk?
Pro és kontra érvekre is kíváncsi volnék.
Előre is köszönöm mindenkinek!
Update:
OCZ Vertex VTX3-25SAT3-240G lett kinézve SSD meghajtónak.
Update2:
A választás a lent leírtak és a bizonytalanságfaktor miatt az SAS hddkre esett; mindenkinek köszönöm a hozzászólásokat és véleményeket; több szempontból is tanulságos volt!
- 10016 megtekintés
Hozzászólások
Intel drágább szériája? Az 520-ra gondolok.
- A hozzászóláshoz be kell jelentkezni
Kissé zavaró benne, hogy nem mer senki 36 hónapnál több garit vállalni...
- A hozzászóláshoz be kell jelentkezni
mire? a 'túlírásra' nincsen garancia - legalábbis intelnél.
valamint a szerver kategóriás SSD-t jó eséllyel úgyis cseréled 3 év múlva...
- A hozzászóláshoz be kell jelentkezni
#define tuliras
- A hozzászóláshoz be kell jelentkezni
előre meghatározott, h egy adott blokk hányszor írható. A jófajta SSD-k megpróbálják az írásokat nagyjából jól elosztani. ezért mondjuk úgy van definiálva, hogy egy 120G SSD-re nagyjából 5TB-t írhatsz. ha ezt felírtad, akkor onnantól "kopik". Viszont - mivel 5TB felírására van hitelesítve - nem reklamálhatsz, hogy a 6. TB-t már nem tudod felírni.
- A hozzászóláshoz be kell jelentkezni
Ahh, koszi! Műveletlen vagyok ssd tárgykörben...
- A hozzászóláshoz be kell jelentkezni
Ez a limit hol van feltüntetve az ssdnél, és a smartból melyik értéket kell figyelni ezzel kapscolatban, hogy lássuk a (várható?) garantált élettartamát?
- A hozzászóláshoz be kell jelentkezni
Ezek alapján 42x tudom teli írni az SSD-t hivatalosan? Ez nekem kicsit kevésnek tűnik. A fél éves 120GB-s SSD-men már 1,5TB írt mennyiség van, akkor ez alapján igen csak rövid élettartamú lesz a hivatalos forma szerint.
- A hozzászóláshoz be kell jelentkezni
Bocs, hogy kicsit regi hozzaszolasra reagalok, de ez az 5 TB nagysagrendileg hulyeseg. 64GB-os jobb minosegu SSD-knel inkabb 500TB korul van ahol kifarad a medium, de most is vannak tesztben olyanok, amik mar 1 PB korul jarnak. 128 GB-os kapacitasnal varhato, hogy ennek duplaja lesz az elettartam.
A gyartok szoktak egy Media Wear Indicator attributumot felvenni a smart-ba, amikor ez az 1-et eleri, akkor ert veget a "garantalt" elettartam. Jobb gyartoknal nem ritka, hogy ezutan meg kb 5-7x ennyit lehet irni az SSD-re, es csak ekkor kezdenek el nagyon felszaporodni az irasi/torlesi hibak, amik az elettartam tenyleges veget jelentik.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
itten mi jól elvetettük a (nem kifejezetten szervercélra tervezett) SSD használatát...
- A hozzászóláshoz be kell jelentkezni
Hát igen... mondjuk itt nagyságrendi eltérés van az árakban...
- A hozzászóláshoz be kell jelentkezni
http://meta.stackoverflow.com/questions/10369/which-tools-and-technolog…
Ez talán majd segít.
(Náluk Intel 710 van, ~240k HUF normál boltokban.)
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
++;
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Én nem javaslom az SSD-t. Ennek oka a minőségi SSD ára. Ha SSD-ben gondolkodsz, akkor ott az enterprise kategóriás eszközöket nézd. Márpedig azok jóval drágábbak.
Ha tényleg nagyforgalmú az adatbázis, akkor többet nyersz optimalizációval ár/minőség mutatót nézve. A helyedben nem 4, hanem 8 vagy 10 darab, de kisebb merevlemezt tennék be. Szépen szétosztva a feladatokat a tömbök között.
Például 2 db RAID-1: oprendszer, 2 db RAID-1 adatbázis log, 2 db RAID-1 adatbázis data, 2 db RAID-1 linuxnál naplók, swap/pagefile, adatbázis temp, 2 db RAID-1 adatbázis redo log.
- A hozzászóláshoz be kell jelentkezni
ennél jobban jársz IOPS szempontjából, ha a sok diszkből inkább egy nagy RAID5/6-ot csinálsz. akkor eloszlik a seekelés a diszkek között...
- A hozzászóláshoz be kell jelentkezni
sw raid6 alatt már borult a rendszer egyszer (IO terhelés miatt); ezért esett a választás a raid10 -re.
- A hozzászóláshoz be kell jelentkezni
Esetleg akkor egy rendes hw-es raid vezérlőbe beruházni? Elég sokat tud számítani ha ki kell hajtani minden iops-ot.
- A hozzászóláshoz be kell jelentkezni
Egy Areca ARC-1680ix-16 áll rendelkezésre. (Megjegyzem, aki a CLI -jét csinálta, while(true) l..ném fejbe)
- A hozzászóláshoz be kell jelentkezni
Mi a baj a CLI interfészével? Szerintem inkább a webes felülete egy agyfasz.
- A hozzászóláshoz be kell jelentkezni
Kidolt diszk eseten smart requestre segfaultol; raid set az nem raid, helyette a volume set a raid, whatever...
Sajnos mar kinlodtunk egy ilyennel anno; nem feher embernek valo...(itt is van valohol nyoma a HUP-on)
UPD: Hasonlítsd össze a 3ware tw_cli -vel...
- A hozzászóláshoz be kell jelentkezni
Areca vezérlővel csak rossz tapasztalatok vannak, egy kártyavár stabilitásával vetekszik.
- A hozzászóláshoz be kell jelentkezni
Én ugyanezt tudom mondani az LSI Megaraidekre. Szvsz mindegyiknek megvan az eléőnye és a hátránya is...
- A hozzászóláshoz be kell jelentkezni
Én csak arra akartam célozni, hogy érdemes jó hardverbe befektetni. Sokszor inkább kispórolják a jóféle Raidvezérlőt a gépből, hogy utána egy borulás miatt többszörösét kifizessék.
Dolgoztam már olyan helyen, ahol a rendszergazdának olyan céges notebookja volt, amiből hiányoztak a csavarok és takarófedelek, néha futott a képernyő is. Egy-egy borulásnál az előbb említett hibák miatt nem egy új notebook árát bukták el. De már sajnos nem emlékszem, hogy hol volt :>
- A hozzászóláshoz be kell jelentkezni
areca majdnem a legjobb az osszes kozul _szerintem_
- A hozzászóláshoz be kell jelentkezni
Hát Windows Server alatt volt, hogy eltűnt az egész diszk alrendszer, de anno 5.1-es MySQL is meg-meg borult vele (bár az nem feltétlen az areca hibája volt) :)
Szerk.: Lehet, hogy konkrétan az az egy volt rossz széria, amivel próbálkoztunk.
- A hozzászóláshoz be kell jelentkezni
Egy 1220-as már nálunk is elborult; reboot óta azóta is működik...:)
- A hozzászóláshoz be kell jelentkezni
DB alá nem teszünk RAID5/6-ot - kivéve, ha nagyon sok(>~8) lemezünk van. Egyébként én is RAID5/6-ot szoktam ajánlani.
- A hozzászóláshoz be kell jelentkezni
> DB alá nem teszünk RAID5/6-ot
De teszünk, ha van kellően sok komponensünk :)
- A hozzászóláshoz be kell jelentkezni
De akkor is csak abban az esetben, ha az olvasás:írás arány 8:2 vagy még több az olvasás javára.
- A hozzászóláshoz be kell jelentkezni
Két esetben teszünk:
- ha nincs apró, random írás (OLTP adatbázisoknál sajnos vannak)
- ha abszolút lényegtelen a performancia.
És természetesen a SW raid5/6, az nem raid, az csak a megbízhatóság csökkentésére alkalmas.
- A hozzászóláshoz be kell jelentkezni
> És természetesen a SW raid5/6, az nem raid, az csak a megbízhatóság csökkentésére alkalmas.
Na, ezt most kinyomtatom A3-asban, és bekeretezve megy a falra :)))
- A hozzászóláshoz be kell jelentkezni
Nekem jo tapasztalataim vannak az SW raid-del, linuxon. Egyszeruen menedzselheto, jo a teljesitmenye (plane a 8+ magos CPUk koraban, gyakorlatilag ugyse tudod leterhelni az osszes magot), es nem gond, ha kicsereled felette a vezerlot vagy a komplett rendszert, csak muxik tovabb.
- A hozzászóláshoz be kell jelentkezni
És milyen marha jó is az a rengeteg alacsony szintű I/O...
- A hozzászóláshoz be kell jelentkezni
2006 óta többször tesztelek sw raidet 3ware és LSI vezérlőkkel. Nem tapasztaltam eget verő különbséget. A HW raid javára pedig végképp nem.
Ennek ellenére, ha nem akarok látni 16 diszket az fdisk -l alatt, vagy blackbox jellegű OS kerül telepítésre, HW raid kerül felhasználásra.
De van, hogy 16 portos 3ware-n SW raidben vannak a vinyók, mert így dobott jobb teljesítményt. Kb mindig eljátszom a tesztet, de sosem győzött meg úgy komolyabban.
- A hozzászóláshoz be kell jelentkezni
Igen, igazad van alacsony kihasználtság esetén. Csak amikor elkezdenek jönni a megmagyarázhatatlan hibák, mert az io teljesítmény elfogy, akkor jön a fejvakarás. A mai hagyományos rendszereknek(x86/x64) pont ez a legnagyobb bajuk: gyorsan elfogy az io. A nagygépek ebben is jobbak.
Na meg mondjuk számtalan olyan környezet van, amikor hw raid kell. Pl: ESX telepítés.
- A hozzászóláshoz be kell jelentkezni
Nem ugyanezt írtam a >~8 kitétellel? :)
- A hozzászóláshoz be kell jelentkezni
Jelenleg egy 6 diszkes (2.5") 1 unitos eszköz határozza meg a keretet; ezzel kell dolgoznom.
A session db külön szerveren van; +1 szerver InnoDB alapú adatbázist szolgál ki; ez a konfig pedig csak MyISAM alapu kiszolgálásra lesz.
Ez alapján egy raid10 és egy raid1 kerül be; binlog + rendszer a raid1; db pedig raid10.
- A hozzászóláshoz be kell jelentkezni
Az OS raid1-nél mindenképp megfontolandó egy olcsóbb MLC SSD pár.
- A hozzászóláshoz be kell jelentkezni
Miért? Az OS-nek nem hiszem, hogy akkora szüksége lenne az IOPS-re.
- A hozzászóláshoz be kell jelentkezni
Igen, de a binlog is ott lesz...:)
- A hozzászóláshoz be kell jelentkezni
Igen, de ha rendes BBWC van, akkor ez nem hiszem, hogy akkora gondot okoz.
- A hozzászóláshoz be kell jelentkezni
Az ellen nem véd...:) Redundáns táp már talán jobban; két külön betápról.
- A hozzászóláshoz be kell jelentkezni
Legalább az OS legyen fürge , ha már a DB nem az.:)
Ott várhatóan , az SSD-k túlélik a DB diszkjeit.:)
Ezeket az olcsó MLC SSD-ket ilyen céllal ajánlják a gyártók , és nem nagy írás terhelésű DB-k alá.
Az adatbázis alá az OCZ Vertex EX 120 GB-os SLC SSD-k valók , arany árában (1300$).
- A hozzászóláshoz be kell jelentkezni
Arany ár? Akkor nézd meg az enterprise meghajtókat (deneva 2, talos 2)
- A hozzászóláshoz be kell jelentkezni
Az bizony ,az arany gramm ára pont a duplája.:)
- A hozzászóláshoz be kell jelentkezni
6 lemez, akkor gondolkodj 3 db raid-1-ben. Egyik tömb OS+DB szoftver, másik tömb db adat, harmadik tömb binlog. Így a rendszer eléggé kiegyensúlyozott lesz a párhuzamos olvasás-írás műveletekben. Pl: binlog írás nem tartja fel a data írást vagy a swapelés nem lassítja a db-ből az adat olvasást. Lemezhiba esetén gyorsabb a helyreállítás is ebben a felállásban.
- A hozzászóláshoz be kell jelentkezni
A szimpla tükörbe rakott diszk miért jobb, mint a tükörbe rakott ssd? Van két slot, abból kell főznie a DB alá valami gyors storage-ot.
- A hozzászóláshoz be kell jelentkezni
Ha jól olvastam, akkor nem 2, hanem 6 slot van. Továbbá a minőségi ssd drága + nehezen beszerezhető. Nem beszélve arról, hogy nagy teljesítmény esetén érdemes több tömböt definiálni más-más vezérlőre. Ezt 6 lemezzel meg tudja tenni, 2-vel nem.
- A hozzászóláshoz be kell jelentkezni
Nem lenne jobb a session-öket memcached-ben tartani?
- A hozzászóláshoz be kell jelentkezni
Történtek próbálkozások erre is, de a session eddig jobbnak tűnt db -ben (tmpfs + 2 replikalas); a repcached pedig még nem eléggé kiforrott.
Redis pedig elvérzett a bevezetés pillanatában.
- A hozzászóláshoz be kell jelentkezni
A redis elverzeset ki tudod fejteni? Mit tapasztaltatok?
- A hozzászóláshoz be kell jelentkezni
Konkrétan majd kollégám fogja tudni a részleteket, én csak a sűrű k.anyázásra emlékszem...:)
Meg fogom írni.
- A hozzászóláshoz be kell jelentkezni
Hat igen aki nem tudja hasznalni annak nem valo. Sessiont DB-be tarolni jo nagy tervezei bug bar ez nalatok meno.
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Kifejtened, miert?
Erdekelne, hogy vajon hany szajbavert konneksont nyissunk egy tetves oldalletolteshez? (Ez nem a jozsikbt gumiaruhaza; )
Memcached van _normalisan_es_stabilan_ perzisztens konneksonnel php-hez? Nincs. (A memleakes verzio (memcache es memcached pecl extensionok) annyira nem erdekelnek)
Tehat:
Mivel te tudod hasznalni, kerlek, most oszd meg velunk, tudatlan halandokkal, vajon hogyan oldanad meg a dolgot (uzembiztosan, tehat replikalva, mivel fizetos a futo szolgaltatas egy resze).
Koszi elore is!
- A hozzászóláshoz be kell jelentkezni
:D:D hat Ti vagytok a benak az tuti amugy semmi extra ficsor nem kell mert mukodik attol.
Amugy alexa ~TOP50 oldal alatt uzemel stabbilan. :)
Szoval a hiba bennetek van.
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Köszönöm, kb. ennyire számítottam.
- A hozzászóláshoz be kell jelentkezni
Csinaljam meg helyeted vagy mit varsz?:D
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Igen, lécci, tetszettek a szakmai jellegű érveid :)
- A hozzászóláshoz be kell jelentkezni
Ezen mit kell ervelni? Mukodik azon sok mindent sajnos nem lehet :(. De csak sirjal.
--
1 leszel vagy 0 élő vagy hulla!
- A hozzászóláshoz be kell jelentkezni
Tudod, az a baj, hogy mondtál valamit, amit nem tudtál érvekkel alátámasztani.
Értem én, hogy az Alexa TOP50 oldalaknál ezt jól tudják használni, de nekem/nekünk még nem sikerült. Mivel @ságnak állítottad be ezt a részünkről (és nem kizárt, hogy igazad van), gondoltam, alá tudod támasztani; esetleg konkrét esettanulmányokkal, ez sajnos azonban nem sikerült. Pusztán szóbeszéd alapján migrálni egy szolgáltatást nagyobb @ság lenne a részemről, mint dedikált sql instance -ket használni session adatokhoz.
- A hozzászóláshoz be kell jelentkezni
Nálunk a monitoring rendszer alá került SSD a mysqlnek elég nagy terhelése volt már, 4-6 load, majd 2 ocz vertex3 SSD raid1 ben azóta .5 load.
Kiváncsi leszek mert 97% ban csak írás történik kb 10e iops, hát elválik mikor hullik ki.
Randomban verhetetlen, szerintem 2 SSD + sűrű/jó backup és nagy gond nem lehet.
Raid10 lehet még esetleg 4-8 diskkel, de randomban nem lesz ott mint a 2 SSD.
Fedora 16, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
Ez mióta megy így?
Írás, vagy felülírás is van? (Mondjuk monitoring szervernél sok felülírás nem lehet...)
- A hozzászóláshoz be kell jelentkezni
január 17. kb csak írás ugye, jelenleg a mysql táblában 115 milló sor van, kb 4G.
Ez tavaly január óta gyűlik, idén kapott SSD-t.
Fedora 16, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
Hmmm, reméltem, hogy minimum 12 hónapot írsz...:)
- A hozzászóláshoz be kell jelentkezni
Az SSD elvileg számolja, hogy mennyi írás történt rá (Host Writes, a SMART-ban), az mennyi most? Itt a HUP-on egyszer linkeltek egy fórumot (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm/page160, ahol emberek nem csinálnak mást, csak folyamatosan írják az SSD-t, és mérik, hogy mennyi idő alatt hogy csökken a sebességük, állapotuk. Azzal a módszerrel pár TB-ot kibírnak. Azt mondjuk nem tudom, hogy ez adatbázis alatti használat esetén hogyan módosul.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ez alapján az F1 (241) mező (Total_LBAs_Written) értéke 20385 GB.
Az előző linkem alapján még egy darabig el tudna menni... (De kétszer sem biztos, hogy így lesz :))
- A hozzászóláshoz be kell jelentkezni
Monitoring rendszer alatt mit kell érteni? Nagios? Vagy valami más de hasonló?
- A hozzászóláshoz be kell jelentkezni
Centreon + nagios, Aircontrol, kvm-ben win2k3 alatt dude szerver, valamint IrMon az sflow adatokhoz.
Fedora 16, Thinkpad x61s
- A hozzászóláshoz be kell jelentkezni
cegen belul mi betettunk ket raid1 be rakott intel ssdt az adatbazis server (es hardveres intel raid kartya) ala, es meglepoen jol birjak a strapat. Mivel az ssdk "faradaskor" nem hibazni kezdenek hanem lelassulnak, ezert az io wait novekedesen idoben eszre lehet venni ha az ssdk a veguket jarjak.
Az ultimate megoldas egy opensolarisos zfs ala bepakolt mysql server lenne ssdken (szigoruan raidz1 / 0 / 10 felhasznalastol fuggoen) mivel a zfs hacsak teheti nem ir ugyanarra a teruletre (pontosabban ciklikusan vegigmegy a merevlemezen az irasokkal, igy egyetlen szektort se farast el az ssdn) ... kar hogy ez linux alatt gyerekcipoben jar nagyon...
- A hozzászóláshoz be kell jelentkezni
hint: static/dynamic wear leveling alacsonyabb szinten
- A hozzászóláshoz be kell jelentkezni
Intel SSD-re +1.
- A hozzászóláshoz be kell jelentkezni
6x 15k-s diszk vagy 4x SSD, de mindenképp RAID1+0 szerintem. Ha sok írás van, akkor rögtön +1 SSD-t rendeljetek biztos ami biztos alapon, hogy legyen a polcon is egy.
- A hozzászóláshoz be kell jelentkezni
Mindenképp kell +1 alkatrészt tartanunk mindenből, így ez nem probléma.
- A hozzászóláshoz be kell jelentkezni
Diszknél nem mindenki tart mert sokszor a géphez járó 4-6-8 órás reakcióidős garival számolnak. Szerintem attól függetlenül jó dolog a hidegtartalék a polcon. :)
- A hozzászóláshoz be kell jelentkezni
Vasárnap éjjel 2kor elszállt már hdd...:)
- A hozzászóláshoz be kell jelentkezni
Az laza, akkor már mindjárt hétfő :) Az igazi nyomor pénteken szokott beütni, lehetőleg olyankor, amikor már minden döntéshozó elérhetetlen, és természetesen jó esetben hosszú hétvége is jön :( Pl.: http://hup.hu/node/114048
Persze disket venni viszonylag hamar lehet, de a hibák nagyon leleményesek tudnak lenni :D
- A hozzászóláshoz be kell jelentkezni
Átéltem veled együtt; ügyeletben voltam...:)
Az ISZT is természetesen ekkor szórakozott... és igen, volt ekkor diszk (pontosabban kontroller) hiba is...:)
IT életem egyik legszebb hétvégéje volt; első nap bekaptunk 3 FE -re is massziv DDoS -t.
- A hozzászóláshoz be kell jelentkezni
24/7-es gariknál van ilyen reakció idő és ha hívod jönnek. :) Ha következő munkanapi (NBD) vagy egyéb garid van akkor nyilván musthave megfelelő számú coldspare.
- A hozzászóláshoz be kell jelentkezni
subs
- A hozzászóláshoz be kell jelentkezni
Az aktualis geprol egy `iostat -dk` es egy `uptime` sokat segitene
Nehany altalanos eszrevetel:
1) Ha fontosak az adatok, es a normal ugymenetnek nem resze aramszunet (vagy hasonlo disk energiaellatast erinto hiba) utan mentesbol adatbazist visszaallitani, akkor mersekelten celszeru olyan ssd, amelyben nincs power loss protection. Vagy ki kell kapcsolni az write cachet - de ilyenkor meg a normal diskeket is alulmuljak tipikusan az ssdk.
2) Az ssdk megbizhatosaga igen valtozatos:
http://www.hardware.fr/articles/862-7/ssd.html
- A hozzászóláshoz be kell jelentkezni
server:~# iostat -dk
Linux 2.6.32-5-amd64 (server) 05/30/2012 _x86_64_ (8 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 189.19 310.84 864.76 718813295 1999753872
sdb 0.59 169.39 0.77 391709338 1785788
sdc 0.53 169.39 0.77 391725403 1785788
md0 0.17 0.68 0.37 1571177 865620
md1 0.11 0.19 0.23 439228 541160
server:~# uptime
06:41:40 up 26 days, 18:22, 1 user, load average: 0.47, 0.23, 0.19
Az sda,sdb és sdc mind hwraid (areca 1220); ebből az sda raid1+0; mind sata2 diszkekkel (nem véletlen vár cserére)
Ez gyakorlatilag a legalacsonyabb terhelésnél készült (kb. 400 belépett user+ a guestek, utóbbinál minimális az erre a szerverre jutó lekérdezések száma és ez esetben írás nincs)
- A hozzászóláshoz be kell jelentkezni
Egyebkent caching reverse proxy is sokat tud dobni a betoltesi idon es mersekelni az adatbazis lekerdezesek szamat a backenden.
Pl. egy Varnish a weboldal ele valoszinuleg sokkal olcsobban tudna nektek eroforrast sporolni mint az SSD-k. Meg egy masszivan dinamikus weboldalnal is 10 masodperces cache expire mellett is latvanyos javulast lehet tapasztalni, mikozben az oldal dinamikus jellege megorzodik.
Hasznaltok valami hasonlot?
- A hozzászóláshoz be kell jelentkezni
Az oldal teljesen dinamikus; soha egyetlen eleme sem ismétlődik (direktben) by design; Varnish -ról a legutóbbi tapasztalat a Guru meditation volt ennél az esetnél...:) (3 frontend van egyébként rotálva; php-fpm backendekkel)
- A hozzászóláshoz be kell jelentkezni
.
- A hozzászóláshoz be kell jelentkezni
Mekkora az adatbázis mérete? Mekkora a növekedési arány?
Adatbázis kiszolgalonak két dolog kell, cpu és memória, kivéve ha nagyon irasintenziv a használat, de ez most nem áll fenn. Ha a lekerdezeseket hattertarrol kell kiszolgálni, vagyis a db nem fér el a memoriaban akkor mindegy mit teszel alá.
- A hozzászóláshoz be kell jelentkezni
120 GB; havi 1-2G növekedés; illetve:
Uptime: 2342550 Threads: 783 Questions: 4317567321 Slow queries: 4161 Opens: 138587 Flush tables: 3 Open tables: 5880 Queries per second avg: 1843.106
Mindezt 16 G RAM mellett.
- A hozzászóláshoz be kell jelentkezni
Az új gépbe különösebb extra nélkül tudtok 32 vagy akár 64GB memót is tenni, mert elég sok slot van már az alaplapokon és a modulok ára se vészes.
- A hozzászóláshoz be kell jelentkezni
Így is lesz; ez van tervben (konkrétan 32 első körben)
- A hozzászóláshoz be kell jelentkezni
Én 64 GB-ot tennék bele. Mi 2009-ben nem hasonlóan nagy méretű(20 GB) adatbázisszerverbe tettünk 48 GB-ot. Nagyon szerette az Oracle.
- A hozzászóláshoz be kell jelentkezni
Tetszőlegesen sok memóriát szeretnek a db szerverek, főleg ha ekkora a DB. Azért írtam a 32/64-et, mert nem tudom mit enged meg a költségvetés, itt nyilván a minnél több, annál jobb. Ha dual xeonos gép akkor ráadásul 6-asával érdemes venni a modulokat, mondjuk 12x8GB-ot ami 96GB. Minden esetre érdemes lehetne a mysqltuner.pl -t is ráereszteni kezdetnek, hogy a buffer méretekre adjon tippet.
- A hozzászóláshoz be kell jelentkezni
Már hogy lenne mind1 mit teszel alá. Mivel fel kell olvasni blockokat a diszkről nem mind1 milyen sebességgel teszed azt.
Ha csak a a redo logokat ki tudod tenni ssdre 10-15% teljesitmény növekedést jelentene. (oracle szinten a mysqlt nem ismerem de nagyot néznék ha ott ez másképp lenne.)
- A hozzászóláshoz be kell jelentkezni
Láttál már méretesebb DB-t?
- A hozzászóláshoz be kell jelentkezni
egyetertek ebben az elottem szoloval, ha lehetseges akkor mindenkeppen kell annyi memoria az sql serverbe mint amekkorak a leggyakrabban hasznalt tablak. Ellenben nagyon kell vigyazni, tapasztalataink szerint van egy mysql memoriakezelesi hiba (feltetelezem mysql, es ez a test ugy fel eve volt, nem vagyok benne biztos hogy meg megvan a hiba, de figyelni mindenkeppen erdemes) ami ha a mysql server max memoria cachet 8G fele rakod (akar egy kilobyte-al is), akkor jon elo. Drasztikus lassulast beragadt szalakat, akkumulativ modon csokkeno teljesitmenyt eredmenyezett nalunk.
Nalunk ezert valahogy ugy van, hogy 7.8G a mysql memoriacache, es a tobbi 24G linux disc cache.
- A hozzászóláshoz be kell jelentkezni
Syslog-ng nem jó erre? Vagy ott is ioban fogy el a gép?
- A hozzászóláshoz be kell jelentkezni
Adatok SAS HDD-ken raid10-ben, SSD-re cache kerulne.
Regebben nezegettem ezt, azota talan vannak ujabb tapasztalatok:
http://www.facebook.com/note.php?note_id=388112370932&_fb_noscript=1
- A hozzászóláshoz be kell jelentkezni
Én használom és bevált (Flashcache).
Bármilyen blokkeszközre ráültethető transzparens módon.
Load negyedére, ötödére esett, amióta megy és szépen javítja a statisztikát azóta is.
Vertex3 van beüzemelve és nem ritka a 30k IO.
- A hozzászóláshoz be kell jelentkezni
Elsőként azt kéne tisztázni, hogy milyen adatbázis?
- A hozzászóláshoz be kell jelentkezni
Egy működő mysql (MYISAM) migrálásáról van szó tulajképp.
- A hozzászóláshoz be kell jelentkezni