Re: Debian 3.0 SPARC iso merre?
In article [EMAIL PROTECTED], Ruzsinszky Attila [EMAIL PROTECTED] writes: Keresnék 3.0 körüli Debiant iso-ban régi gépekre. Nem találok Guglival. Valami 1, max. 2 CD-sre gondoltam. Nekem az 7 CD-n van meg. Behozzam? Letoltod? De mitol jobb a Woody regi gepekre, mint a Sarge? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Zoltan NAGY [EMAIL PROTECTED] wrote: az a baj, hogy az iowait 30-40%, de a load megy fel, mert az apache megeszi a CPU -t :-) u320as scsi van alatta, smartarray vezerlovel. Ha 30-40% az iowait, akkor vagy rosszul csinalsz valamit, vagy ez sem eleg (hany diszk van azon a kontrolleren, milyen beallitasban? Streamingnek nem sokat szamit, h scsi vagy micsoda) En tesztelgetnem lokalisan azt a diszktombot (iozone, pl), hogy megis kepes lehet-e kiszolgalni az elvart savszelesseget. A load pedig NEM mervado teljesitmenymutato. Tul sok apacs processzed van valoszinuleg (illetve az a +30% cpu is elferne apacseknal gondolom). raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH írta: Zoltan NAGY [EMAIL PROTECTED] wrote: az a baj, hogy az iowait 30-40%, de a load megy fel, mert az apache megeszi a CPU -t :-) u320as scsi van alatta, smartarray vezerlovel. Ha 30-40% az iowait, akkor vagy rosszul csinalsz valamit, vagy ez sem eleg (hany diszk van azon a kontrolleren, milyen beallitasban? szerintem az elso. imho nincs az a kimeno savszelessegigeny, amit ilyen hw-el akarmilyen bena beallitassal ne lehetne kiszolgalni. a mi gepunkon sokszor megvan a 10mbit/sec kimeno forgalom tartosan, 40-60 apache process, 3 jboss instance es 11-12% a cpu atlagos terhelese, aminek jo fele az ejjeli menteskor megy el egyben. iowait max 7-8% de ezek alap sata cuccok, raid1ben. Streamingnek nem sokat szamit, h scsi vagy micsoda) ha sok stream (sok pozicio) akkor sem? En tesztelgetnem lokalisan azt a diszktombot (iozone, pl), hogy megis kepes lehet-e kiszolgalni az elvart savszelesseget. meg a filerendszert A load pedig NEM mervado teljesitmenymutato. Tul sok apacs processzed van valoszinuleg (illetve az a +30% cpu is elferne apacseknal gondolom). persze nemtom milyen az a processzor, nalunk egy atomregi 2.8-as p4 boven jo (12% terheles napi atlagban) -- Üdvözlettel, Gábriel Ákos -=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=- -=Tel/fax:+3612367353/200|Mobil:+36209278894=- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Debian 3.0 SPARC iso merre?
On 06-Oct-25 18:03, Ruzsinszky Attila wrote: Keresnék 3.0 körüli Debiant iso-ban régi gépekre. Nem találok Guglival. Valami 1, max. 2 CD-sre gondoltam. (0,5-1G-s HDD-re) Nekem anno, amikor kellett jigdoval epult az image. Kesz image-et nem talaltam a tukorszervereken, mindenhol csak x86-ot tartottak. G _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos [EMAIL PROTECTED] wrote: szerintem az elso. imho nincs az a kimeno savszelessegigeny, amit ilyen hw-el akarmilyen bena beallitassal ne lehetne kiszolgalni. legyen mondjuk 1gbit/s, 1 tetszoleges diszk, maris nem tudod (elmeletileg sem) kiszolgalni. :) Persze egy sima warez szervernel ez nem jellemzo. Streamingnek nem sokat szamit, h scsi vagy micsoda) ha sok stream (sok pozicio) akkor sem? 100 korul kezdhet esetleg szamitani. A mai diszkekben van annyi cache, meg readahead okossag a linuxban, hogy nem. (No de ha 100 folotti stream-je van, akkor az egy streamre juto savszelesseg mar igen kicsi lesz, raadasul ugyis mindegyik a halozatra fog varni tippem szerint) En tesztelgetnem lokalisan azt a diszktombot (iozone, pl), hogy megis kepes lehet-e kiszolgalni az elvart savszelesseget. meg a filerendszert igen, igen, ugy ertettem. A load pedig NEM mervado teljesitmenymutato. Tul sok apacs processzed van valoszinuleg (illetve az a +30% cpu is elferne apacseknal gondolom). persze nemtom milyen az a processzor, nalunk egy atomregi 2.8-as p4 boven jo (12% terheles napi atlagban) tok mindegy milyen cpu, ha iowait, akkor iowait. Es a load sem jelent szinte semmit, cpu-tol fuggetlenul:) raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Zoltan NAGY [EMAIL PROTECTED] wrote: oke. rosszul csinalok valamit. mit? :-) latatlanban nehez megmondani. 512 mb ram van a kontrolleren, es kulso hp diszkdobozba vannak a vinyok (majdnem televannak, azaz kb ~25 diszk, 15krpm). 600mbit folott mar nincs idleje a gepnek. A 25 diszknek elegnek kene lenni, az rpm edeskeveset szamit ebben a helyzetben. Milyen konfiguracioban vannak a diszkek? Mennyit tud a diszkalrendszer (pl. iozone tesztekkel)? Milyen filerendszer, milyen parameterekkel? udv raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH írta: A 25 diszknek elegnek kene lenni, az rpm edeskeveset szamit ebben a hatugye adottesetben meg a diszkek szama is mindegy lehet. hogyan csatlakozik a diszkdoboz a pcbe? Mert ha ad absurdum egy sima 32 bites pci, akkor helo :) -- Üdvözlettel, Gábriel Ákos -=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=- -=Tel/fax:+3612367353/200|Mobil:+36209278894=- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Debian 3.0 SPARC iso merre?
Nekem az 7 CD-n van meg. Behozzam? Letoltod? De mitol jobb a Woody regi gepekre, mint a Sarge? Rosszul jártam a Sarge-val (3.1r3). Hibák: 1. magyar nyelvet nem szereti, már az elején nem csinál semmit, CD-ROM meghajtó felirat lárszik és 0%. 2. SUN LANCE nem található. Shell-ben valami nem található szimbólumot mond a sunlance modul az insmodnál. 3. SILO install failed error=-1 Ebből a 2-3 eléggé fatális! Mehetek visszafelé a verziókban, ill. túrhatom a Guglit, hogy mi a megoldás. Üdv: Ruzsi _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos wrote: Andras HORVATH írta: A 25 diszknek elegnek kene lenni, az rpm edeskeveset szamit ebben a hatugye adottesetben meg a diszkek szama is mindegy lehet. hogyan csatlakozik a diszkdoboz a pcbe? Mert ha ad absurdum egy sima 32 bites pci, akkor helo :) mint mondtam, kulso u320 -as scsi diszkdoboz. lspci szerint: [..] Capabilities: [dc] PCI-X non-bridge device Command: DPERE- ERO+ RBC=512 OST=8 Status: Dev=03:04.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=8 DMCRS=32 RSCEM- 266MHz- 533MHz- udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH wrote: A 25 diszknek elegnek kene lenni, az rpm edeskeveset szamit ebben a helyzetben. Milyen konfiguracioban vannak a diszkek? Mennyit tud a diszkalrendszer (pl. iozone tesztekkel)? Milyen filerendszer, milyen parameterekkel? raid5, iozonet nemtudok rajta nezni, mert 0-24 kivan terhelve az egesz. amugy: [...] type xfs (rw,noatime,logbufs=8,logbsize=32768) otlet? :-) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Zoltan NAGY írta: raid5, iozonet nemtudok rajta nezni, mert 0-24 kivan terhelve az egesz. raid5-on streamelni, gratulalok. tessek raid1-re atalakitani, akkor talan... -- Üdvözlettel, Gábriel Ákos -=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=- -=Tel/fax:+3612367353/200|Mobil:+36209278894=- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos [EMAIL PROTECTED] wrote: raid5-on streamelni, gratulalok. miert, mi a baj vele? olvasashoz nem kell szamolni, es ha irnak ra, akkor csak arra kell vigyazni, hogy egesz tobbszoroset irjak a RAID chunk size-nak. (Mondjuk ez olvasasnal se hulyeseg.) A kerdezonek: ha nem tudsz hozzanyulni, tovabbi informacioval szolgalni, akkor nem fogunk tudni ennel tovabb segiteni sem. raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos wrote: Zoltan NAGY írta: raid5, iozonet nemtudok rajta nezni, mert 0-24 kivan terhelve az egesz. raid5-on streamelni, gratulalok. tessek raid1-re atalakitani, akkor talan... :) kicsit draga lenne, nem? ;) valamit csak lehet csinalni...? :) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH wrote: Gábriel Ákos [EMAIL PROTECTED] wrote: raid5-on streamelni, gratulalok. miert, mi a baj vele? olvasashoz nem kell szamolni, es ha irnak ra, akkor csak arra kell vigyazni, hogy egesz tobbszoroset irjak a RAID chunk size-nak. (Mondjuk ez olvasasnal se hulyeseg.) A kerdezonek: ha nem tudsz hozzanyulni, tovabbi informacioval szolgalni, akkor nem fogunk tudni ennel tovabb segiteni sem. barmi olyat megtudok csinalni, ami nem akadalyozza a felhasznalokat a rendszer hasznalataban, illetve ejszaka csak 100-200 mbit megy ki, akkor tudok ugy teszteket vegrehajtani. de teljesen leloni nemnagyon... mit javasolnal? udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH írta: miert, mi a baj vele? olvasashoz nem kell szamolni, es ha irnak ra, akkor csak arra kell vigyazni, hogy egesz tobbszoroset irjak a RAID chunk size-nak. (Mondjuk ez olvasasnal se hulyeseg.) attol fugg mennyi a read/write arany. ha ez eleg nagy, akkor a write baromi nagy reszet elviszi a diszkek idejenek a folos szamolgatashegyek miatt, es akkor kesz a lassu raid5. adatbazis ala is pont ezert nem javasoljak. fileservernek jo, oszt csokolom. -- Üdvözlettel, Gábriel Ákos -=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=- -=Tel/fax:+3612367353/200|Mobil:+36209278894=- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Zoltan NAGY írta: Gábriel Ákos wrote: Zoltan NAGY írta: raid5, iozonet nemtudok rajta nezni, mert 0-24 kivan terhelve az egesz. raid5-on streamelni, gratulalok. tessek raid1-re atalakitani, akkor talan... :) kicsit draga lenne, nem? ;) valamit csak lehet csinalni...? :) nem volna eleg az ugy letrejovo kapacitas? en amugy majdnem biztos hogy ugyanabbol a penzbol egy tobbgepes sata-s setupot csinaltam volna, sok raid10-be kotott sata vinyoval. tobbet fogyaszt, az igaz, de jobban es olcsobban skalazhato. -- Üdvözlettel, Gábriel Ákos -=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=- -=Tel/fax:+3612367353/200|Mobil:+36209278894=- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos wrote: Zoltan NAGY írta: Gábriel Ákos wrote: Zoltan NAGY írta: raid5, iozonet nemtudok rajta nezni, mert 0-24 kivan terhelve az egesz. raid5-on streamelni, gratulalok. tessek raid1-re atalakitani, akkor talan... :) kicsit draga lenne, nem? ;) valamit csak lehet csinalni...? :) nem volna eleg az ugy letrejovo kapacitas? nem, ez is televan. en amugy majdnem biztos hogy ugyanabbol a penzbol egy tobbgepes sata-s setupot csinaltam volna, sok raid10-be kotott sata vinyoval. tobbet fogyaszt, az igaz, de jobban es olcsobban skalazhato. lehet, de mostmar ezen nem tudok valtoztatni :-) SATA vs SCSI tapasztalatok? ;) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Gábriel Ákos [EMAIL PROTECTED] wrote: attol fugg mennyi a read/write arany. ha ez eleg nagy, akkor a write mennyit ir egy webszerver? (errol szol a subject is) baromi nagy reszet elviszi a diszkek idejenek a folos szamolgatashegyek miatt, es akkor kesz a lassu raid5. adatbazis ala is pont ezert nem nem, erre a megoldast izmos RAID CPU-nak hivjak. A raid5 akkor hal meg igazan, ha olvasni kell irashoz (tul kicsiket irsz). Adatbazisrol (ami kicsiket ir) nem is volt szo itt. Megoldasom nincs, komponensenkent kellene megmerni, hogy hol a szuk keresztmetszet. Szerintem a raid kartyaban vagy abban a csoda kulso diszktombben lesz de ugyebar ha egesz nap uzemel a cucc, akkor nem sok mindent tudsz csinalni. raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Andras HORVATH wrote: Gábriel Ákos [EMAIL PROTECTED] wrote: attol fugg mennyi a read/write arany. ha ez eleg nagy, akkor a write mennyit ir egy webszerver? (errol szol a subject is) baromi nagy reszet elviszi a diszkek idejenek a folos szamolgatashegyek miatt, es akkor kesz a lassu raid5. adatbazis ala is pont ezert nem nem, erre a megoldast izmos RAID CPU-nak hivjak. A raid5 akkor hal meg igazan, ha olvasni kell irashoz (tul kicsiket irsz). Adatbazisrol (ami kicsiket ir) nem is volt szo itt. Megoldasom nincs, komponensenkent kellene megmerni, hogy hol a szuk keresztmetszet. Szerintem a raid kartyaban vagy abban a csoda kulso diszktombben lesz de ugyebar ha egesz nap uzemel a cucc, akkor nem sok mindent tudsz csinalni. osszerakok egy ugyanilyen osszetetelu tesztkornyezetet, ott tudok merni, de mar csak jovohet elejen szerintem. ha osszeraktam jelentkezem :-) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Zoltan NAGY [EMAIL PROTECTED] wrote: SATA vs SCSI tapasztalatok? ;) streaming i/o-ra szerintem nagyon jo a sata is. (Persze itt rendes, 7x24-re hitelesitett sata diszkekre kell gondolni, nem a low-end asztali napi-ket-orat-porgok verziokra.) raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: asterisk + előkódos hívás
Thursday, October 26, 2006, 1:28:49 PM, Gyurman Attila wrote: Van egy asterisk központ pár darab mellékkel, jelenleg 9xx-el tárcsáznak kifelé. Azt kellene megoldani, hogy a 9-es helyett egy 4 jegyű PIN kódót tárcsáznának, hogy hónap végén lehessen listát csinálni, hogy ki mit hívott. Mivel csak 9 mellék van, ezért ha más nem lesz, minden PIN-re külön megadok egy 1234xx formátumú szűrést, de jobb lenne valami profibb megoldás. A legjobb az lenne, ha ezek a kódok mysql-ben lennének :-) Hát azért be kéne határolni a 4 jegyű pin kódok tartományát, és lehet írni rá egy szabályt. Mivel a híváslistába (legalábbis a master.csv-be) bekerül a teljes telefonszám azaz az 12340670123567 pl. így annak a megfelelő feldolgozásával ki lehet szűrni, hogy melyik pin-el milyen számot hívtak. Tehyük hozzá, hogy ha nem definiálsz külön szabályt az egyes elérhető PIN-ekre, akkor bárki bármilyen PIN-el fog tudni kifelé telefonálni. -- Best regards, Csibra Gergomailto:[EMAIL PROTECTED] _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: asterisk + előkódos hívás
Csibra Gergo írta: Thursday, October 26, 2006, 1:28:49 PM, Gyurman Attila wrote: Van egy asterisk központ pár darab mellékkel, jelenleg 9xx-el tárcsáznak kifelé. Azt kellene megoldani, hogy a 9-es helyett egy 4 jegyű PIN kódót tárcsáznának, hogy hónap végén lehessen listát csinálni, hogy ki mit hívott. Mivel csak 9 mellék van, ezért ha más nem lesz, minden PIN-re külön megadok egy 1234xx formátumú szűrést, de jobb lenne valami profibb megoldás. A legjobb az lenne, ha ezek a kódok mysql-ben lennének :-) Hát azért be kéne határolni a 4 jegyű pin kódok tartományát, és lehet írni rá egy szabályt. Mivel a híváslistába (legalábbis a master.csv-be) bekerül a teljes telefonszám azaz az 12340670123567 pl. így annak a megfelelő feldolgozásával ki lehet szűrni, hogy melyik pin-el milyen számot hívtak. Tehyük hozzá, hogy ha nem definiálsz külön szabályt az egyes elérhető PIN-ekre, akkor bárki bármilyen PIN-el fog tudni kifelé telefonálni. Alapból arra gondoltam, hogy minden PIN-re külön szabályt írok. Csak a 8 mellékre kb. 30 user van, ezért kicsit macerás lenne karbantartani. Viszont most ráleltem az asterisk Authenticate() programjára, amivel elvileg megoldható hogy egy szöveges file-ból vegye az elfogadható jelszavakat, és be is teszi azt az Accountcode változóba. Ez már használható megoldás lenne, most próbálgatom. De a mysql még mindíg csábtóbb lenne, ha működne. Attesz _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Kosa Attila wrote: Mitol streaming a streaming? :) Szerintem a scsi-t ilyen teruleten biztosan nem veri meg a sata, mert a sata megfogja a processzort is, mig a scsi (vagy raid) vezerlo fogadja a processzor utasitasait, nem kell varnia a processzornak a valaszra. Es szerintem 300 processz eseten mar nagy valoszinuseggel ugralnia kell a fejnek a diszkekben. oke, de ennyire? nyilvna random i/o kategoria, de nehogymar ne legyen kepes 14db 15krpm u320as scsi kiszolgalni 1gbitet... Mekkorak a fajlok? Mik a raid-vezerlo bios beallitasai? A smartarray-ekben (emlekeim szerint) lehet allitani mindenfele erdekes dolgot, amelyek gyorsithatjak a diszkek elereset a cache hasznalataval, csak vigyazni kell nemelyikkel, mert aramszunet eseten elofordulhat, hogy peldaul nem minden irodik ki a cache-bol (ezert szokott elem lenni a komolyabb vezerlokon). BBWC modul rajtavan az 512es ramon, of course :-) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
On Thu, Oct 26, 2006 at 06:12:40PM +0200, Zoltan NAGY wrote: Kosa Attila wrote: Mitol streaming a streaming? :) Szerintem a scsi-t ilyen teruleten biztosan nem veri meg a sata, mert a sata megfogja a processzort is, mig a scsi (vagy raid) vezerlo fogadja a processzor utasitasait, nem kell varnia a processzornak a valaszra. Es szerintem 300 processz eseten mar nagy valoszinuseggel ugralnia kell a fejnek a diszkekben. oke, de ennyire? nyilvna random i/o kategoria, de nehogymar ne legyen kepes 14db 15krpm u320as scsi kiszolgalni 1gbitet... Ezert mondjak a tobbiek is, hogy meg kellene vizsgalni a raid-vezerlo beallitasait, teszteket futtatni (kulonbozo fajlrendszerekkel), hogy kideruljon, mit tudnak a diszkek, nem-e megis az a szuk keresztmetszet. Ezen eredmenyek nelkul ennel nem nagyon lehet tobbet mondani... -- Udvozlettel Zsiga _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
I/O alrendszer teszteles [Volt: Nagyforgalmu web szerver...]
Kosa Attila wrote: On Thu, Oct 26, 2006 at 06:12:40PM +0200, Zoltan NAGY wrote: Kosa Attila wrote: Mitol streaming a streaming? :) Szerintem a scsi-t ilyen teruleten biztosan nem veri meg a sata, mert a sata megfogja a processzort is, mig a scsi (vagy raid) vezerlo fogadja a processzor utasitasait, nem kell varnia a processzornak a valaszra. Es szerintem 300 processz eseten mar nagy valoszinuseggel ugralnia kell a fejnek a diszkekben. oke, de ennyire? nyilvna random i/o kategoria, de nehogymar ne legyen kepes 14db 15krpm u320as scsi kiszolgalni 1gbitet... Ezert mondjak a tobbiek is, hogy meg kellene vizsgalni a raid-vezerlo beallitasait, teszteket futtatni (kulonbozo fajlrendszerekkel), hogy kideruljon, mit tudnak a diszkek, nem-e megis az a szuk keresztmetszet. Ezen eredmenyek nelkul ennel nem nagyon lehet tobbet mondani... akkor ezeket megfogom tenni mihamarabb, es kirakom publicba az eredmenyeket. most mar csak az kell, h dobjatok meg otletekkel, h miket nezzek :-) parameterezesek, filerendszer-opciok, barmi, es akkor megcsinalom a teszteket. szoval minden javaslatra nyitott vagyok :-) udv, Z _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
Kosa Attila [EMAIL PROTECTED] wrote: Mitol streaming a streaming? :) Szerintem a scsi-t ilyen attol, hogy folyamatosan olvasol, egymas utani blokkokat, nem pedig osszevissza. Azert ez nem ilyen sarkos, nehanyszor tiz stream-et meg eleg jol tud egy modern diszk+vezerlo (es/vagy az oprendszer) optimalizalni. teruleten biztosan nem veri meg a sata, mert a sata megfogja a processzort is, mig a scsi (vagy raid) vezerlo fogadja a ezt mire alapozod? Egy modern, NCQ-kepes SATA diszk (es vezerlo) es jo kernel (es VM-beallitasok) amugy csodakra kepesek. FYI amugy vannak nagyon komoly RAID vezerlok SATA diszkekhez is. A kerdes nem az volt, hogy megveri-e hanem hogy jo-e. Jo, annyira, hogy ne erje meg scsi-t (SAS-t, ugye, manapsag) venni, szerintem. processzor utasitasait, nem kell varnia a processzornak a valaszra. Es szerintem 300 processz eseten mar nagy valoszinuseggel ugralnia kell a fejnek a diszkekben. 300 az mar hatareset, en 100 alatti streamrol beszeltem kicsivel korabban, mint okolszabaly. (Bar ha iras nincs, 300-an (vagy ezren) olvasnak, azzal meg lehetne valamit kezdeni.) erdekes dolgot, amelyek gyorsithatjak a diszkek elereset a cache hasznalataval, csak vigyazni kell nemelyikkel, mert aramszunet Az olvasason (en ugy vettem ki az eredeti felvetesbol, hogy ezzel van a gond) a cache nem sokat fog segiteni, leven nagy file-ok es nagy forgalom - keves valoszinuseggel lesz benne a cache-ben, amit legkozelebb ker a gep. eseten elofordulhat, hogy peldaul nem minden irodik ki a cache-bol (ezert szokott elem lenni a komolyabb vezerlokon). amin van (bekapcsolt) write cache, es nincs akksi, az eletveszelyes. De ez a megjegyzes jelen esetben igaz, de nem relevans. A fajlrendszer is befolyasolhatja a sebesseget. Lehet mindenfele igy igaz. teszteket talalni a neten, de en ilyen meretnel mindenkeppen sajat teszteket is csinalnek (ami nem feltetlenul egyszeru). mint irta a kollega, ezen a gepen nem tud tesztelni, de majd osszerak egy masikat. Varjuk az eredmenyet. raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: I/O alrendszer teszteles [Volt: Nagyforgalmu web szerver...]
On Thu, Oct 26, 2006 at 06:33:59PM +0200, Zoltan NAGY wrote: akkor ezeket megfogom tenni mihamarabb, es kirakom publicba az eredmenyeket. most mar csak az kell, h dobjatok meg otletekkel, h miket nezzek :-) parameterezesek, filerendszer-opciok, barmi, es akkor megcsinalom a teszteket. Mintha Kissg csinalt volna egy tesztet, na, meg is van: http://gatling.ikk.sztaki.hu/~kissg/plan/terabyte/ -- Udvozlettel Zsiga _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nagyforgalmu web szerver...
On Thu, Oct 26, 2006 at 04:35:58PM +, Andras HORVATH wrote: Kosa Attila [EMAIL PROTECTED] wrote: teruleten biztosan nem veri meg a sata, mert a sata megfogja a processzort is, mig a scsi (vagy raid) vezerlo fogadja a ezt mire alapozod? Egy modern, NCQ-kepes SATA diszk (es vezerlo) es jo kernel (es VM-beallitasok) amugy csodakra kepesek. Szemelyes tapasztalatom az, hogy a sata megfogja a gepet, mig - ugyanolyan terhelesnel - a scsi nem. FYI amugy vannak nagyon komoly RAID vezerlok SATA diszkekhez is. Van nehany sata raid-vezerlos gepem, sokkal tobb gond van veluk, mint a scsi-s gepekkel. A kerdes nem az volt, hogy megveri-e hanem hogy jo-e. Jo, annyira, hogy ne erje meg scsi-t (SAS-t, ugye, manapsag) venni, szerintem. Azt mindenkinek maganak kell eldontenie, hogy mi eri meg. De ha a scsi tunik szuk keresztmetszetnek, akkor nem hiszem, hogy sata-ra valtani lenne ertelme. processzor utasitasait, nem kell varnia a processzornak a valaszra. Es szerintem 300 processz eseten mar nagy valoszinuseggel ugralnia kell a fejnek a diszkekben. 300 az mar hatareset, en 100 alatti streamrol beszeltem kicsivel korabban, mint okolszabaly. (Bar ha iras nincs, 300-an (vagy ezren) olvasnak, azzal meg lehetne valamit kezdeni.) A kerdezo 300-at emlitett, azert irtam annyit. erdekes dolgot, amelyek gyorsithatjak a diszkek elereset a cache hasznalataval, csak vigyazni kell nemelyikkel, mert aramszunet Az olvasason (en ugy vettem ki az eredeti felvetesbol, hogy ezzel van a gond) a cache nem sokat fog segiteni, leven nagy file-ok es nagy forgalom - keves valoszinuseggel lesz benne a cache-ben, amit legkozelebb ker a gep. Nem ismerem a fajlok nagysagat, es nem ismerem a forgalom jelleget sem. Mindenesetre 512M cache mar nem keves, plane ha sok rendszermemoriaval meg van tamogatva. teszteket talalni a neten, de en ilyen meretnel mindenkeppen sajat teszteket is csinalnek (ami nem feltetlenul egyszeru). mint irta a kollega, ezen a gepen nem tud tesztelni, de majd osszerak egy masikat. Varjuk az eredmenyet. En is kivancsi vagyok :) -- Udvozlettel Zsiga _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: asterisk + előkódos hívás
On Thursday 26 October 2006 13:28, Gyurman Attila wrote: Sziasztok! Van egy asterisk központ pár darab mellékkel, jelenleg 9xx-el tárcsáznak kifelé. Azt kellene megoldani, hogy a 9-es helyett egy 4 jegyű PIN kódót tárcsáznának, hogy hónap végén lehessen listát csinálni, hogy ki mit hívott. Mivel csak 9 mellék van, ezért ha más nem lesz, minden PIN-re külön megadok egy 1234xx formátumú szűrést, de jobb lenne valami profibb megoldás. A legjobb az lenne, ha ezek a kódok mysql-ben lennének :-) A PIN azonositas is megoldhato egy egyszeru perl/php/c/c++/java/stb programmal. Pl: allitsd be minden user-nel a callerid number-t hivaskor szedd ki a PIN-t a tarcsazott szambol, es mysql-bol mehet az auth. a callerid number + PIN -koddal AGI-n keresztul. A szamlazashoz pedig hasznald az accountcode-t, igy nem kell ugyeskedni, ha egy usernek megvaltozik a pin kodja. (En DISA auth.-ot csinaltam perl AGI-val + pgsql-el, frankon mukodik. :) ) Udv: G _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
