Nagy terhelésű szerver optimalizálása

[quote:055194c7d6="pdx"]nem tudja valaki, hogy hol lehet magyarországon silicon image 3124-es sataII kontroller kártyát kapni? a tomshardware elég jó véleménnyel volt róla, és tudja a NCQ-t is, ha a HDD is.

Ezt a linket erdemes megnezned, ha
SATA controllert akarsz venni.

Par idezet:
Innen:
Silicon Image 3124
Summary: Full TCQ/NCQ support, with full SATA control including hotplug and PM.
libata driver status: early review driver available.

Innen:
Even though some SATA host controllers on the market already support command queueing (a.k.a. "TCQ"), libata does not yet support it.

Egyszer volt valami CPU intenziv szamolasi taskom. ~2.4.28-es kernel volt, elinditottam 2 peldanyban a szamolast, es igy 10%-ban gyorsabb volt az egesz, mintha 1 peldanyban futott volna.

Ennyit jelentett a Hyperthreading. egy probat megerhet. Bar lehet a fedora-s kernel tamogatja alapbol, es mar most is hasznalod?

Silicon Image SATA vezérlővel vigyázni, mert a 3112-es (SATA 1) bizonyos fajta Seagate vinyókkal összeakad, workaround miatt teljesítménycsökkenés lesz a vége. A pontos vinyótípusok a kernel megfelelő forrásfile-jában megtekinthetőek. :)

/proc/sys/kernel/shmmax határozza meg, mekkora lehet a maximálisan foglalható shared memory szegmens.

nem tudom nalad mennyire szuk keresztmetszet a db backend, illetve milyen a select/insert aranyod, de egy MySQL 4.x biztos nem rontana a helyzeten ( http://dev.mysql.com/doc/mysql/en/query-cache.html )

SZERK: hupsz csak az elsot olvastam, bocs

egy jo scsi de inkabb scsi raid sokat segithet ;
a lecsupaszitott weblapokhoz tux nem jo ?
a 2.6.x -es kernel szvsz sokkal jobb mint a 2.4-es szeria ; kivetelt az rh advanced server extratunningolt kernele kepez.

ami meg a sendmailt illeti valahol van a konfigjaban egy ilyen :

O QueueLa=8
O RefuseLA=12

ami azt jelenti,hogy 12-es load felett mindenkeppen elutasitja a bejovo kapcsolatot ; lasd a konfigban a kommentet ; emeld meg,ha nagyon kellenek a levelek.

[Mem: 2075968k total, 2022584k used, 53384k free, 156384k buffers
Swap: 1052248k total, 0k used, 1052248k free, 1125096k cached

erdekes. miert nem hasznal egyetlen byte swapot sem ? hm. hm.

Én mod_rewrite helyett inkább egy reverse proxy-t tennék be redirectorral.
Ekkor még a proxy miatt mellékhatásként MaxClients-et lecsökkenthetnéd felére, harmadára, ami a csökkenő context-switch-ek miatt sokat dobna a dolgon.
Aztán lehetne a php-ból kijövő tertalom cache-elhetőségével is játszani, ha elég az, hogy mondjuk 5 bercenként van új tartalom. Persze pl. chat-nél ez a cache-elés nem nagyon jönne be :)

Nekem sokat segitett, a kernel TCP paramaterek optimalizalasa:
net/ipv4/tcp_tw_recycle=1

Meg van meg egy csomo TCP paramater ami nem jut most eszembe, de a google segithet, meg a probalkozas.

[quote:4d877ab60c="szipka"]tcp_tw_recycle=1

ez nem kavar be a csomagszuronek?

ugy jobban belegondolva ; a memoria eleg ; hiszen nem hasznal swapot es ha ez telleg atlagos top,akkor meg szabad is van vmennyi ; a cpu-t a webszerver eszi meg ; ergo vmi gyorsabb proci valamennyit javithat a helyzeten ; de ez csak tuneti kezeles.
a kernelt magad forgattad,vagy valamelyik fc rpm-jebol a binaris megy ?

[quote:02f40b7dcf="snq-"][quote:02f40b7dcf="szipka"]tcp_tw_recycle=1

ez nem kavar be a csomagszuronek?

Eddig nem volt vele baj, viszont teljesitmenyben sokat dobott, elotte volt vagy 6-800 TIME_WAIT socket.

irtad, hogy mar megoldottad a statikus tartalom kulonvalasztasat (a 2 apache instance-os felallashoz). valamelyik tiny http szervert javaslom a kepekre/css file-okra/stb kiprobalni, konkretan mi mathopd-vel futunk, "a tapasztalatok jok" :))

Szevasz Cöme! :)

Pár kósza ötlet csak:

- vmstatot figyeled néha? Miből van legtöbbször nem nulla, r/b/w?

- Ha durva a site, felejtsd el az alaplapi SATA vezérlőket. Egyrészt a SATA még mindig viszonylag lassú, másrészt ez is fogja a procit, mint az IDE. Minimum egy 3Ware 8000-res sorozatú kártya kell RAID10-zel, esetleg a 9000-resek közül egy, de az I/O terhelést igazán a SCSI RAID nyomja le. Ajánlom az Intel SRCU42X kártyáját, memóriával alaposan megpakolva és elemmel, mert akkor van csak write back cache! Ez PCI-X-es kártya, de fut 64bit/66MHz-es PCI slotban is, én is így használom. Ha gyors és redundáns tömböt akarsz, akkor RAID10 kell neked, mint az előbb is írtam.

- MySQL-t frissítsd 4.0/4.1-re, gyorsabb. Bár a topból úgy néz ki, hogy az Apache zabálja meg a procit. Esetleg fordítsd az Apache-ot statikusan újra, bármilyen horrorisztikusan is hangzik. Az x86 architektúra kevés regisztere miatt :? ez is jelent sebességnövekedést.

- Ha külön webszerver alá pakolod a statikus tartalmat, az valami jobban erre kihegyezett legyen, mint az Apache. Akár Tux, akár pl. thttpd (nekem ez bejött nagyon), esetleg Boa stb.

- Ha van rá lehetőséged (tudom, írtad, hogy új gépet ne :) ), akkor inkább duálprocis gép felé mozdulj el. Jobban bírja a rászakadó hirtelen terheléseket és jobb a válaszideje.

- Filerendszer ügyében nekem az a tapasztalatom, hogy az XFS általában lenyomja az Ext3-at, mint a rajzszöget (a Reisert nem használtam soha, nem ismerem). Ha mégis Ext3-at használsz, a dir_index opciót mindenképpen kapcsold be.

- Szinte minden partíciót csatolhatsz noatime kapcsolóval. Ezzel is lemez I/O-t spórolsz meg.

Ha továbbra is "döglenek a libáid", csak szólj, van még ötlet! :lol:

Ha a biztonság és a gyorsaság együtt kell, akkor egy RAID5 vagy ha még inkább biztonságcentrikus vagy, akkor RAID6 vagy RAID5 + hot-spare lenne az ideális megoldás szerintem. A RAID tömbe a vinyókat érdemes jól megválasztani, Seagate vagy WD szvsz. Mi RAID5-öt használunk. A RAID5 a három vinyó együttes használata miatt szerintem elég jó sebességgel bír, még ha a parity kezelést beleszámítjuk akkor is. Biztonságilag is szerintem okés, mert egyszerre nem szokott elszállni két vinyó, ha meg egy elszáll akkor lehet pótolni, vagy pedig hot-spareben eleve odarakni egy új vinyót. A RAID6 jóval drágább, de két vinyó elszállását engedi meg alapból, de akkor szerintem a RAID5 + hot-spare még mindig kapacitás- és költségtakarékosabb megoldás. Mindezt valami gyors (Ultra 3 Wide SCSI) interfészen kéne megvalósítani.

Ja, a filerendszer kérdésben szerintem a /boot mindenképp ext2, az adatoknak meg XFS, esetleg Reiser.

[quote:8d556ba9d8="Beanie"]Ha a biztonság és a gyorsaság együtt kell, akkor egy RAID5 vagy ha még inkább biztonságcentrikus vagy, akkor RAID6 vagy RAID5 + hot-spare lenne az ideális megoldás szerintem. A RAID tömbe a vinyókat érdemes jól megválasztani, Seagate vagy WD szvsz. Mi RAID5-öt használunk. A RAID5 a három vinyó együttes használata miatt szerintem elég jó sebességgel bír, még ha a parity kezelést beleszámítjuk akkor is. Biztonságilag is szerintem okés, mert egyszerre nem szokott elszállni két vinyó, ha meg egy elszáll akkor lehet pótolni, vagy pedig hot-spareben eleve odarakni egy új vinyót. A RAID6 jóval drágább, de két vinyó elszállását engedi meg alapból, de akkor szerintem a RAID5 + hot-spare még mindig kapacitás- és költségtakarékosabb megoldás. Mindezt valami gyors (Ultra 3 Wide SCSI) interfészen kéne megvalósítani.

A paritásszámolós RAID szintekkel az a baj, hogy írásnál halál mind. Ha módosítasz egy csíkban valamit, akkor a másik n-2 lemezről (RAID5-nél) be kell olvasnia a többi adatblokkot is, kiszámolni az új paritást, kiírni az adatblokkot és visszaírni az új paritásblokkot.

RAID5 oda való, ahol elsődlegesen a nagy tárterület a fontos, sok olvasás van és viszonylag kevés írás. Pl. webszerver alá, esetleg fileszervernek, de adatbáziskezelőhöz semmiképpen se.

Némi ütemezés jelentősen javíthat:

http://reports-archive.adm.cs.cmu.edu/anon/home/ftp/usr0/anon/usr/ftp/2000/CMU-CS-00-170.pdf

Na igen, de itt főleg erről van szó ahogyan én látom. Az adatbáziskezelést a back-end szerver végzi, a szerveren a fő cél a webes kiszolgálás.

Szia,

nehany kulcsszoban, a kerdeseidre:

[quote:0a195c6bd9="pdx"]
- az sk98lin driverrel hajtott alaplapi Marvell ETH-et átállítottam IRQ-moderációra (AUTO beállítás, 2000 IRQ/msec nagy terhelés esetén) (ez nagyon nagyot dobott, mert nem csinált megszakítást minden egyes megkapott/kiküldött packethez, hanem szépen sorba állította őket)

Ertheto, tenyleg nagyot tud dobni, nem ismerem a Linux ide vonatkozo lehetosegeit, de pl. FreeBSD -n is az ember elso dolga a device polling bekapcsolasa, a Solaris 10 meg ugye automatikusan valt polling es irq mode kozott. (Kicsit utananeztem, ugy tunik mindket oprendszer ide vonatkozo resze 'okosabb' a Linuxenal.)

[quote:0a195c6bd9="pdx"]
- a PHP-eaccelerator berakása (szintén nagyot dobott)

Ertheto. Az e-accelerator-nak egyebkent erdemes kihasznalni a kodbol az explicit caching lehetosegeit.

[quote:0a195c6bd9="pdx"]
- a site statikus elemeinek (js, css, képek, egyes statikus szövegelemek) és a PHP session filejainak ramdiskre rakása

Reg rossz az a rendszer, ahol a ramdisk-re rakas segit, hiszen a gyakran hasznalt file objektumokat az operacios rendszer ugyis cache-ben tartja.

[quote:0a195c6bd9="pdx"]
- kipróbáltam -- egy tipp alapján -- egy külön apache futtatását, ahonnan az összes statikus (nem-PHP) elem jött, ebben a konfigban nem volt sem mod_rewrite, sem mod_php, sem semmi dinamikus dolog, tehát egy lecsupaszított apache -- nem sok eredmény, le is lőttem azóta

A kulon apache ertelme, hogy hasznalhatod a worker modult akkor is, ha kulonben a PHP nem tenne lehetove (pl. ha olyan php modulokat hasznalsz, amelyek nem thread safe-ek). Igy kis memory footprint-tel eleg sok object-et ki tudsz szolgalni eleg gyorsan, meghagyva a memoriat a dinamikus oldalak es a _file system cache_ szamara. Azonkivul nehany beallitast maskepp szokas a php-kat futtato apacs-ban beallitani: pl keepalive off.

[quote:0a195c6bd9="pdx"]
- okozhatja-e ezt a nagy LA-t a SATA lassúsága ill. processzorfüggése? ha igen, akkor egy SCSI (Ultra160) alrendszer ezen jelentősen segíthet? ha igen, akkor milyen kontroller-kártyát ajánlotok? (Tekram?)

En inkabb arra tippelnek, hogy a PHP scriptek megeszik a processzort. Termeszetesen minden komponens upgrade-je segit, de kellene lennie annyi memoriadnak, hogy ne forduljon annyit a diszkekhez, hogy ez szamitson - ha nincs annyi memoriad, akkor regen rossz, de egyebkent a vmstat kimeneted is azt mutatja, hogy processzorbol van keves.

[quote:0a195c6bd9="pdx"]
- ilyen esetekben akár egy single xeon nagyot tud dobni a rendszeren? ha igen, akkor a 64-bites linux verziót telepítsem?

Ha 64-bit capable xeonod van, akkor kiprobalhatod a 64 bites linuxot, attol fugg.

[quote:0a195c6bd9="pdx"]
- egyes híresztelések szerint a 2.6.xx kernel-ág rosszabul teljesít nagy terhelés alatt, mint a 2.4.xx. igaz ez? ha igen, mekkora teljesítményt nyerhetek egy esetleges kernel-visszaállással?

A 2.6 szerian belul valoban tapasztalhatoak eleg komoly teljesitmeny-hullamzasok a verziok kozott. Alapvetoen sok uj lehetoseg van a 2.6 -os szeriaban, de alkalmazasfuggo, hogy aktualis verzioval mit lehet kiaknazni.

[quote:0a195c6bd9="pdx"]
- a fenti szoftverek közül valamelyikben van valami köztudomású bug, ami hatással lehet a teljesítményre?
- bármi egyéb ötlet az optimalizálásra?

A legtobb az alkalmazason mulik. Az eaccelerator pl. egy jo eszkoz, ha tudod hasznalni. (Jo programozo tudja hasznalni) Cserebe viszont ez is csak egy ujabb hack a kodban. Mivel irtad, a PHP lecserelese, rendes load balancing, ill. gepcsere kizart, ezert sok hozzafuznivalom nincs is a dologhoz: ebben a szituacioban a legtobbet a kodban javithatsz (leszamitva aprobb konfiguracios tippeket, amiket boven megtalalsz a google-ban mindenhol). Nem tudom pl. mennyit memoriat eszik az eacceleratorod, erdemes kiserletezni hatha SHM nelkul jobb eredmenyt ad - vegul is itt az derulne ki, hogy a Linuxnak az SHM implementacioja vagy a filerendszer cache-e a rosszabb. :) Kiprobalhatsz egy FreeBSD 5 -ot, Solaris 10 -et, abbol a szempontbol jobb lesz, hogy biztosan nem kell majd ssh loginra varnod (persze itt is nemi tuningot igenyel), de amig a hardver adott, es a hardvert a programod viszi el, csak a programon tudsz valtoztatni.

Udv,

Mico

[quote:641de0e9b0="pdx"]hehe... kicsi a világ. :)

a tcp-s kernel paraméterek tuningolása sajnos nem sokat segített, egy halvány árnyalatnyit lejjebb ment a terhelés, de igazán jelentős változást nem hozott (pedig átnéztem a többi paramétert is, 1-2n változtattam is (max_orphans pl)).

Csodak nincsenek, nekem az 5-s load ment le tole 2-3 -ra, egyebkent szerintem ott a gondok talan a php-s kodokkal lehetnek, egy ilyen szervernek birnia kell 1-2M hit-et, bar ez attol, is fugg ehhez mekkora halozati forgalom tarsul. Egy teljesen hasonlo szervert lattam mar ami 2-3M hitet is kiszolgalt(igaz izzadt rendesen 3-4-es load), pedig az nem is php-volt hanem jsp es Tomcat.

[quote:8969c55655="szipka"]Egy teljesen hasonlo szervert lattam mar ami 2-3M hitet is kiszolgalt(igaz izzadt rendesen 3-4-es load), pedig az nem is php-volt hanem jsp es Tomcat.

"Pedig" ? A szerver oldali Java alapvetoen gyorsabb, mint a PHP. (Alapvetoen, mert a programon mulik)

Szia,

lasd elozo hozzaszolasomat, plusz:

[quote:32cb08a7e3="pdx"]húú, köszi a sok választ! :D

akkor az én válaszaim/kérdéseim:
- hmm, a tux mennyivel nagyobb teljesítményt tud nyújtani és mennyire könnyen konfigolható?

A statikus oldalak teljesitmenyen fog javitani. Sajnos Tux-szal nincs sok tapasztalatom, a Solaris NCA mar eleg regota letezik, bizonyos esetekben sokat tud dobni. De ugy gondolom nalad egy rendes konfiguracio eseten a PHP -k vinnek el ugyis a CPU-t.

[quote:32cb08a7e3="pdx"]
- kernelben egy stock kernelt használok, tehát csak az rpm-et raktam fel, és abból is a FC2 2.6.10-es legfrissebbet 1 procira, i686 architekturára. mivel ha SCSI-re áttérünk, úgyis felrakok egy FC3-at, abban már valószínűleg saját kernelt forgatok forrásból. ez tapasztalaltotok szerint mennyit segít?

Ha a dolgok ugy mukodnenek, ahogy kellene nekik, akkor nem sokat segitene.

Adi-nak teljesen igaza van abban, hogy ha uj gep, akkor dualproc legyen; az outputjaid alapjan nalad talan nem is annyira, de bizonyos muveleteknel sokat segit a response timeokon, ha van egy masik CPU, ami tud dolgozni mikozben az egyik spinlockban kenytelen varni.

A "hiszen nem hasznal swapot" hozzaszolasokkal nem ertek egyet, nem tudom mennyi contentrol beszelunk, de az hogy nem swappel a gep, nem jelenti azt, hogy az operacios rendszer nem hasznalna meg szivesen 1-2 GB RAM -ot, pl filerendszer cache-nek.

udv,
M.

Ez bizony a vmstat szerint elsősorban karcsú procit jelent. A w amúgy a swap oszlopnak felel meg, csak az újabb vmstat már így írja ki.

Ha upgrade-eltek, akkor inkább duál Opteron és sok memória. Túrjál egy-két tesztet neten, ha jól rémlik, akkor Anandéknál volt egy nagyobb lélegzetvételű MySQL-es móka. Az opteronos gépek elég csúnyán elkalapálták a xeonos versenytársakat.

Az előző hozzászólásokban azt hiszem nagyon hasznos dolgokat írtak, nagyon jó a topic :). Néhány saját tapasztalatot azért hozzátennék:
Mico kolléga említette, hogy nagyon sok múlhat a PHP-kódon. Ezzel teljesen egyetértek. Én egy nagyon általános programozói hibával találkoztam, ami rettentően vissza tudja vetni a PHP sebességét:
Sokan óriási tömböket használnak, amiknek aztán csak egy-két sorát használják fel, pl. LIMIT használata nélkül írnak SQL SELECT-eket.
A PHP memóriakezelése katasztrofálisan lassú. sokszor hosszabb ideig tart a memória lefoglalása és felszabadítása, mint az oldal legenerálása. Nagyon oda kell figyelni a tömbökre!

A másik gond: Ha jól emlékszem az apache nálad 60 szálon fut. A szálak (persze itt processzek) között az ütemező váltogat, 2.6-os kernel-nél 1000-szer másodpercenként (desktopon ez jót tesz). Egy ilyen váltás (context-switch) nagyon költséges művelet. Szerintem első körben ezt le kéne vinned 100-ra (2.4-es default).

A harmadik gond: Az apache szálak száma nem nagyon vihető le, mert akkor viszont rengeteg connect-re váró user lenne, nagyon lecsökkentve a válaszidőt. Ennek az alapja az, hogy míg normális esetben a PHP-nak néhány ms alatt sikerül összeraknia az oldalt, a felhasználók másodpercek alatt töltik le a sávszélességi korlátok miatt.
Erre a problémára írtam korábban a reverse proxy-s megoldást (fordított proxy). A squid egyetlen szálon, conext-switch-ek nélkül dolgozik. Web-szerverként üzemel és a localhost-on futó apache-nak adja tovább a kéréseket. Mivel a proxy gyorsan leszívja a választ az apache-tól, nincs szükség annyi apache processzre, mégis jobb lesz a válaszidő és magasabb lehet az egyidejű kapcsolatok száma. Szóval a lényeg: az adott idő alatt végrehajtott context-swich-ek drasztikus csökkentése! Nálunk ez a megoldás kb. tizedére csökkentette a loadot, lehet, hogy nálad is bejönne, talán egy próbát megér.

[quote:99a1d71732="pdx"]
egy rettentő nagy forgalmú site-ot (és több kis site-ot, továbbá DNS-t és mailt) futtató szerverről van szó, a nagy forgalmat értsd >1,5M hit naponta (lassanként 2M körül kezd lenni, sikeres a site, na).

Csak nem pcforum.hu? :wink:

Viccen kívül: nem jeleztél vissza, hogy noatime benne van-e az fstab-ban.

Ha kevés a pénz, akkor 3ware SATA RAID, jól.

Üdv,
Dw.

nem ertem a rinyalast, napi 2M hittel mar szep penzeket lehet keresni...
azaz fogalmazzunk ugy hogy havi 2M-el lattam mar szep penzeket keresni embereket... :)

Ez a hardver rettentő sok pénzt vitt el? Öhöhöhö. :lol: Azért ne essünk túlzásokba, ez egy egyszerű asztali Asus lap, ha jól látom. Majd ha barebone/brand szerverre, redundáns tápra, SCSI hot-swap szekrénykére és RAID-vezérlőre költesz, az lesz drága! :)

Az eAccelerator get/put függvényeit nem ismerem, de esetleg megpróbálhatod a memcached-t is még. Persze sok memória kell neki, de a LiveJournal terhelését anno eszetlenül lenyomta, amikor kifejlesztették és bevezették.

Dual Opteronhoz való deszkából nálunk leginkább a Tyan cuccai érhetőek el, alaplapfüggő, hogy milyen memória kell bele. Pontosabban proci, mert ugye integrált memóriavezérlő van rajtuk. Ha jól rémlik, az újabb Opteronokhoz nem kell feltétlenül regiszteres memória (de ez szerverbe nem árt). Lehetőleg persze olyan lapot vegyél, amin nem csak 32bit/33 MHz-es PCI csatik vannak, hanem gyorsabbak is, több PCI buszon. Ha az eszközöket több buszra szétrakod, akkor a megemelt áteresztőképesség is csökkenti a loadot, mégha közvetlenül nem is ez a kevés, hanem a processzoridő.

A SATA vinyókat is cseréld le, pontosabban minimum a vezérlőt, mert az is visz el CPU-időt.

A noatime-mal kapcsolatban: én még nem futottam bele olyan daemonba, vagy egyéb programba, aminek megártott volna

Ezt a 10k könyvtárat nem mondtad!
Kegyetlen lassan kezel ennyi alkönyvtárat a Linux (tapasztalataim szerint Solaris is). Ezért szoktak többszörös alkönyvtár-kezelést alkalmazni, pl. név alapján (pl. kezdőbetű alapján külön alkönyvtárba tehetnéd).
Másik általában nagyon lassú dolog file-okban tárolni dolgokat, pl. session-t. shm, de még adatbázis is nagyságrendekkel gyorsabb, bár shm szerintem veszélyes a fix mérete miatt.
Squid kezel HTTP/1.1-et.

Helló

Bár a problémádat nyilván nem a sendmail okozza, de nem gondolkoztál még a lecserélésén? Az eredeti leveledben írtad, hogy gyakran nem fogad levelet. Megpróbálkozhatnál a Qmail -lel, hiszen sebességben, megbízhatóságban szerintem jócskán felülmúlja a sendmailt.

http://lists.mysql.com/benchmarks/

"A "hiszen nem hasznal swapot" hozzaszolasokkal nem ertek egyet, nem tudom mennyi contentrol beszelunk, de az hogy nem swappel a gep, nem jelenti azt, hogy az operacios rendszer nem hasznalna meg szivesen 1-2 GB RAM -ot, pl filerendszer cache-nek."

jogos az egyetnemertes; de ha jol megnezem azt a topot,akkor azt latom,hogy -- igaz nemsok,de -- van meg ott szabad memoria ha kellene neki megette volna cache-nak.

Reszlet a www.sunvolume.hu-rol (ingyen regisztracio utan elerheto a Benchmark resz alatt):

"Persze nem csak ez a két program fontos, ezért egyéb teszteket is végeztünk. Példának okáért néhány program fordítási idejét mértük a Sun V20z-n (mind egy, mind két processzort használva), valamint egy AMD Athlon XP 2400-on. Egy kisebb program, ami az Athlonon körübelul fél perc alatt fordult le, a V20z-n egy processzorral 10, két processzorral 6 másodperc alatt. Ilyen kis programnál ekkora különbség igencsak tetszetős. A linux kernel fordítás volt a másik tesztünk, ott is drámai különbséget tapasztaltunk, hasonló kernel konfiguráció esetén: Míg az Athlonon 40 perc volt, mire kész kernelt kaptunk, a V20z-n egy processzorral 25, kettővel 18 perc. És ez egy igencsak nagy kernel volt.."

Amugy az aprc.hu-n talalhato feltetelek mellett barki bemehet, es letesztelheti a sajat alkalmazasat ezeken a hardvereken...

[quote:b0cae0d87f="Adi"]
A paritásszámolós RAID szintekkel az a baj, hogy írásnál halál mind. Ha módosítasz egy csíkban valamit, akkor a másik n-2 lemezről (RAID5-nél) be kell olvasnia a többi adatblokkot is, kiszámolni az új paritást, kiírni az adatblokkot és visszaírni az új paritásblokkot.

Egy jo trukk az, hogy ha a filesystem blokkmeretet a RAID-5 csik netto meretere, vagy egesz szamu tobbszorosere valasztod meg. Vagyis ha 3+1 diszked van 16k-s blokkmerettel, akkor a filesystem blokkjait 48k-ra meretezve egy iras idealis esetben az egesz csikot irni fogja, es nem kell veszodni a visszaolvasassal/paritasl szamolgatassal.

[quote:c2a619542c="nzmark"]Helló

Bár a problémádat nyilván nem a sendmail okozza, de nem gondolkoztál még a lecserélésén? Az eredeti leveledben írtad, hogy gyakran nem fogad levelet. Megpróbálkozhatnál a Qmail -lel, hiszen sebességben, megbízhatóságban szerintem jócskán felülmúlja a sendmailt.

Akkor már inkább Postfix. Nem hitvitából írom :), a Qmail I/O-igényesebb.

[quote:981c887ca8="hokuszpk"]
jogos az egyetnemertes; de ha jol megnezem azt a topot,akkor azt latom,hogy -- igaz nemsok,de -- van meg ott szabad memoria ha kellene neki megette volna cache-nak.

Jogos, nem is vettem eszre. Persze sok beallithato lehetoseg van ezzel kapcsolatban is, ugyhogy akkor lehetne nyilatkozni, ha lattunk volna mindent. Pl nekem nagyon gyanus hogy /tmp -> ramdisk atallas eseten jelentosen nott a teljesitmeny.

[quote:d08ade0d58="pdx"]
az opteronnál kb. hogy kell számolni, teljesítményügyileg, hányas opteron felel meg hányas xeonnak? persze csak megközelítőleg.

(...)

hááát, szerintem nem lenne rossz ötlet a sessionöket shm-be pakolni, mert php-s serialize'd formában foglal valami 32MB-ot a sok file, ami
amúgy is egy ramdisken van, kb. ennyi szabad memóriám mindenképp

(...)

- plusz minden x-edik (nem emlékszem, talán 1000 kérésenként 1-re van beállítva) lekérésnél elindítani a gc-t, ami vagy 10E file-on söpör végig, mtime-ot keresve
- mindehhez persze még az ext2 filerendszer szokásos belassulása a sok-sok file-t tartalmazó session file könyvtártól (még akkor is, ha ramdisk-en van)...
csak:
- kivenni a cookie-nak megfelelő session adattömböt és bemásolni az adott változóba
- a végén az adott változót visszanyomni a memóriába
- és minden x-edik kérésnél egy gyors láncon végigmenni, és a lejárt sessionöket free-zni...
...szóval asszem átállok az eaccelerator-féle session kezelésre. :lol:

egyébként az eaccelerator-os get, put, rm stb függvények rettentő egyszerű shm-elérést valósítanak meg, nagyon hasznosak. csökkent is a terhelés, mióta a site konfigot shm-ből szedem. következő menetben kipróbálom, hogy mennyit enyhít a terhelésen az eaccelerator session-kezelése.

Látom, Opteron-ügyben már Joel elkezdett lobbizni. :) Amúgy Kugli a te barátod, hogy ezeket megnézd, de mint írtam, az Anandtechen van MySQL teszt régebbről még.

A memcached-be meg mindenfélét el lehet rakni, nem csak a session-ök adatait. Bár az általad írtak alapján az eAccelerator is hasonló módszert használhat. Mondjuk a memcached-nek megvan még az az előnye is, hogyha van olyan géped, amiben még van szabadon memória, akkor azt is bevonhatod, futtathatsz ott is memcached processeket. Ha jól emlékszem, azt írtad, hogy van még egy backend gép is, ugye?

Jut még eszembe: nem okvetlenül muszáj fix méretű ramdiskkel szívni, pakolhatod a cuccokat /dev/shm alá is.

Szia,

[quote:8f2aed4871="pdx"]
az opteronnál kb. hogy kell számolni, teljesítményügyileg, hányas opteron felel meg hányas xeonnak? persze csak megközelítőleg.

Nagyon megkozelitoleg: Opteron 252 -> Xeon 3.6, 248 -> 3.2.
Nehez osszehasonlitani, vannak alkalmazasok es operacios rendszerek, amik jobban szeretik az egyiket vagy masikat.

[quote:8f2aed4871="pdx"]
hááát, szerintem nem lenne rossz ötlet a sessionöket shm-be pakolni, mert php-s serialize'd formában foglal valami 32MB-ot a sok file, ami amúgy is egy ramdisken van, kb. ennyi szabad memóriám mindenképp van. és ha figyelembe vesszük, hogy nem kell minden egyes dinamikus (PHPs) requestnél:

A php session tamogatasaval a szerializacio fuggetlen attol, hogy hogyan tarolod az adatokat. Pl. attol hogy a session save handler az eaccelerator lesz, a szerializacio ugyanaz marad. (nem kotelezo azt hasznalni persze)

[quote:8f2aed4871="pdx"]
következő menetben kipróbálom, hogy mennyit enyhít a terhelésen az eaccelerator session-kezelése.

Korabban irtad, hogy egy /tmp -> ramdisk atallitas is segitett, nekem furcsan hangzik, de ha igy van, mindenkepp allitsd be az eacceleratort, hogy csak shm-et hasznaljon, tempfilet ne.

Udv,
M.

[quote:56eb648bef="_Joel"]Egy kisebb program, ami az Athlonon körübelul fél perc alatt fordult le, a V20z-n egy processzorral 10, két processzorral 6 másodperc alatt. Ilyen kis programnál ekkora különbség igencsak tetszetős. A linux kernel fordítás volt a másik tesztünk, ott is drámai különbséget tapasztaltunk, hasonló kernel konfiguráció esetén: Míg az Athlonon 40 perc volt, mire kész kernelt kaptunk, a V20z-n egy processzorral 25, kettővel 18 perc. És ez egy igencsak nagy kernel volt..

Szezont a fazonnal...

mico a device polling nem zavar be az altq-nak?

mi a kulcs a freebsd.hu -hoz? :)

Szerintem a P4 az kepes hyperthread-amit celszeru lenne egy sajat forditasu kernel formajaban magadeva tenni.

Processor type and...
Processor family: P4.....
Generic x86 ...: OFF
SMP on 2 proci
SMT (Hyperthread)...: ON
Preemptible kernel: OFF
Loadable module support
OFF

Device drivers
Block devices
IO Sheduler
CFQ :ON

Alapertelmezesnek a CFQ boot soran kernel parameterkent elevator=cfq

Ertelem szeruen nem ez az ossz config csak ami jelen esetben mindenkeppen fontos lenne. Szepen pontrol pontra vegig kell menni es beallitani mindent es csak azt forditani a kernelbe ami kell.

Nem tudom FC-ben van-e de Debianban van libc6-i686 csomag az sem art

UI.:

Kernel confignal ajanlom meg a elvegre ez egy szerver es mukodni kell
Code maturity level options: OFF
A modulokra szinten a szerver mivoltbol nincs szukseg elvegre egy szerverben az ember nem cserel minden nap hardwaret es nem dug USB eszkozoket a gep seggebe.

FS-nek en Reisert hasznalok, nem muszaly ezt de ext2 ill. ext3 max boot particionak

[quote:a35086d601="drastik"]mico a device polling nem zavar be az altq-nak?

Nem hasznalok most ALTQ-t, nem tudom, ki fogom probalni...

[quote:a35086d601="drastik"]mi a kulcs a freebsd.hu -hoz? :)

pista

[quote:90d11530af="zsalab"]Szerintem a P4 az kepes hyperthread-amit celszeru lenne egy sajat forditasu kernel formajaban magadeva tenni.

Linuxnal mennyire ismeri mar a scheduler ezeket a cpu felepiteseket?
Desktop hasznalat eseten egyertelmu, hogy segithet a hyperthreading, de ha hajtva van, sok a context switch es a scheduler nem foglalkozik azzal, hogy a ket 'cpu' valojaban egy es ugyanaz, az egesznek a vege jo kis cache trashing lehet.

[quote:0c2288eb18="Mico"]
Szezont a fazonnal...

Jaja, de CPU intenziv terheles eseten jo indikator lehet.

[quote:ed0cabacd1="Mico"][quote:ed0cabacd1="zsalab"]Szerintem a P4 az kepes hyperthread-amit celszeru lenne egy sajat forditasu kernel formajaban magadeva tenni.

Linuxnal mennyire ismeri mar a scheduler ezeket a cpu felepiteseket?
Desktop hasznalat eseten egyertelmu, hogy segithet a hyperthreading, de ha hajtva van, sok a context switch es a scheduler nem foglalkozik azzal, hogy a ket 'cpu' valojaban egy es ugyanaz, az egesznek a vege jo kis cache trashing lehet.

A 2.6-os kernel figylembe veszi, hogy a HT-s az csak egy fizikai cpu.
Igazan ennek dual procinal van szerepe, hogy ne migraljon processt egy fizikai CPU-n belul.