At 21:08 17.10.2004 +0300, you wrote: >On Sun, 17 Oct 2004, Nemesis wrote: > > > Cineva de pe aici a avut problema si a reusit sa o rezolve ? > > 1. sapa rabla sa nu aiba placi care sa faca irq sharing si sa >fie solicitate en-gros (2 placi de retea, o placa de retea si una video, >o placa ISA si o placa de retea pci, etc). E preferabil ca nici una >dintre placile de retea sa nu faca sharing cu nimic altceva, indiferent >daca acel altceva sta degeaba sau nu;
Nu fac shareing pe acelasi IRQ. > 2. daca faci nat prin zona si nu ai cum sa renunti la asta >atunci ia-ti un cpu mai puternic. Altfel da jos tot ce tine de nat >(rmmod la tot, iptable_nat si ip_conntrack + tot ce depinde de ele); Nu fac NAT. Le-am dat jos fara imbunatatiri vizibile. > 3. daca ai compilat kernelul cu suport de APM si "make cpu calls >when idle" sau ceva de genul asta atunci debifeaza optiunea cu pricina >si recompileaza. Daca ai bifat APM doar pentru ca tu stii ca bios-ul tau >stie apm, fara sa stii ce face fiecare dintre optiunile bifate atunci e >mai safe sa scoti suportul de apm pina te documentezi (oricum nu ai >nevoie de apm pe o masina care face treaba in continuu); Nu este bifat suportul pt. APM. > 4. daca ti-ai compilat in kernel tot felul de minuni si ai avut >proasta inspiratie sa le mai compilezi si built-in atunci fie le pui >modul si le activezi doar daca ai nevoie de ele fie nu le mai bifezi in >nici un fel; Tot ce este posibil doar ca modul este bifat. > 5. daca ai 700 de mii de reguli prin firewall atunci vezi cum >le agregi sau cum renunti la ele; Buna idee... practica ma omoara :( > 6. daca pentru a bloca diverse lucruri ai puse regulile >toporistic prin forward sau imprastiate prin toate chainurile si >tabelele atunci rescrie toate regulile si plaseaza-le omeneste in >mangle/PREROUTING - asta e chainul dinaintea tuturor chainurilor, daca >blochezi timpeniile aici atunci n-or sa mai traverseze o tona de tabele, >mai ales nu-ti vor mai ajunge in nat (daca esti obligat sa ai tabela >asta, daca nu, asa cum ti-am spus, rmmod la tot ce tine de ea); Ok. > 7. daca ai pachete care stii ca-ti vin doar pe o interfata sau >care pleaca doar pe o interfata atunci la regulile din firewall >foloseste, acolo unde este posibil, -i interfata sau -o interfata. E mai >simplu sa se compare doar interfata decit sa se desfaca pachetul pina la >layer 70 pentru a vedea daca e tcp, udp sau icmp, daca e pe portul ala >sau al'lalt, daca e tos cutare, daca e dst cutare sau src cutare, daca e >mark cutare, daca string matches cutare, etc etc etc etc; Nu stiam ca treaba per interfata poate mari viteza.... notat si voi aplica. > 8. daca ai kernel 2.4 atunci compileaza-l cu gcc 2.9x (2.95 sau >2.96). Codul rezultat de pe urma lui gcc3 se preteaza mai bine pentru >servere de aplicatii si-ti iar pe routere iti maninca cu 30-50% mai mult >cpu pentru aceleasi lucruri. Daca ai kernel 2.6 atunci compileaza-l cu >gcc 3.4.x (e ok si pentru servere si pentru routere); Am sa incerc sa-mi instalez un gcc mai nou. > 9. mai spune-ne tu in ce stare ti-e masina aia: are praf pe ea, >se incalzeste cpu-ul, o tii in cada sau in buda si e uda permanent, etc. Temperatura constanta 24C, UPS, umiditate in limitele normale, praf ? pun aspiratorul pe el, CPU-ul nefiind overclock-at si cu un ditamai cooler-ul nu cred sa ai probleme nici daca merge non-stop la 100%. > In principiu, ca sa ajunga la idle 0 pe cpu un P][/400 cu 2 >placi de retea (100Mbps FD) poate sa care cam 40-60Mbps si/sau >25-40kPktps (upload + download), cu tot cu reguli de qos pe el (cu >limite largi, intre 512Kbps si 2Mbps sa zicem, si iarasi, sa zicem, 200 >de clase) si ceva reguli in firewall (nu cine stie ce, sa zicem doar >pentru a bloca netbios atit tcp cit si udp). Fara qos si reguli in >firewall se duce pe la 100-120-150Mbps si 60-80kpktps, urmind ca in >starea asta (idle cpu 0) sa se apropie mai mult sau mai putin de maxim. > Aceeasi configuratie de mai sus cu limite in qos de 256Kbps sau >mai putin (acelasi numar de clase, 200 sa zicem) incepe sa ajunga la >idle 0 pe la 8-12-16Mbps (si aici depinde de multi parametri). > Statisticile prezentate mai sus sint orientative, limita la care >se ajunge la idle 0 pe cpu depinde de mai multi parametri (de unii chiar >foarte tare): chipsetul placilor de retea, calitatea switchurilor, tipul >traficului, media bytes/pachet, chipsetul placii de baza (chiar si >producatorul), FSB, clock ram chiar, numarul cozilor qos, limitele lor, >burst, etc (cu cit limitele sint mai mici si, in principiu, burst-ul mai >mic incrcarea pe cpu creste pentru acelasi numar de clase). > > Ti-am dat si aceste statistici ca sa ai un punct de orientare cu >privire la situatia pe masina ta. Ele sint orientative, repet. Ca sa >vezi cum arata situatia ta ar trebui sa testezi, dar pina atunci tre' >sa-ti pui la punct masina aia. Cred ca te-ai mai plins si saptamina >trecuta de ea. Schimb-o draq'! Am in vedere schimbarea. Sper ca un Athlon la 2600+ sa fie suficent. > Sa-mi fut una, cit timp am pierdut cu mailul asta! 12 minute! >Dai o bere (cu camion si restul de baxuri de bere cu tot), stimabile, >daca cel putin unul dintre sfaturile mele iti creste idle-ul pe cpu! --- Detalii despre listele noastre de mail: http://www.lug.ro/
