Meg par szo arrol a hires Sys Admin magazin tesztrol

[Miklos Niedermayer]

Sziasztok,

kb most jutottam el odaig, hogy megneztem, mit is csinaltak ezek a sracok.

Hatterinfo:  volt egy teszt, amiben a FreeBSD igencsak veszteskent kerult
ki, mire kaptak egy csomo emailt, hogy hogy kellett volna beallitani a
FreeBSD gepeket, mire beallitottak ugy, es akkor orul a community.

Probaltak korrektek lenni, irtak egy kis bevezetot a FreeBSD
megbizhatosagarol, meg hogy defaultbol megbizhatosag, meg ilyesmi, es hogy
oruljetek nepek, megcsinaltuk ujra a tesztet.

Van az a hires file-letrehozasi-olvasasi tesztjuk, a tuningolt FreeBSD mar
kapasbol kenterbe verte az osszes tobbit 8k-16k-32k-64k meretu fileoknal -
128k-nal pedig lassabb volt a Linuxnal es a Win2000-nel.  Ez mar nem
hangzik olyan rosszul (sot), de erdemes tudni, hogy ha valoban egy
hozzaerto allitja be, akkor ott is nyertunk volna.  Hogy miert gondolom
azt, hogy egy hozzaerto sem volt ott?

``Rather, most FreeBSD systems administrators tune the operating system by
reading "man tune"...''

"man tune" marpedig nincs. :)  A kovetkezo tuningolasokat vegeztek el:

-softupdates bekapcsolasa a particiokra
-maxusers 512
-hw.ata.wc=1
-kern.ipc.nmbclusters=60000
-async mount opcio minden particiohoz

Plusz meg nehany sysctl, amit ugyan helyesen belottek, de az eddig
leirtaknal nem buzlik valami? Valami nagyon?

Mindenki leflammelte oket a hw.ata.wc ugyeben, elmagyarazva, hogy mit
miert, erre ok fogtak es bekapcsoltak az ata.wc-t.  Csakhogy nem ATA
diszkeket hasznaltak(!) hanem SCSI-t!  Az SCSI write cache beallitasokhoz
a FreeBSD nem nyul, ezt a diszk firmwarejeben kell allitani, jobb
vinyoknal gyarilag *tiltva* van a write cache, de a Linux es a Windows is
automatikusan bekapcsolja.  Na ez volt az egyik.

A masik:  ezek bekapcsoltak a softupdates-t es az async-et is.  Errol
ennyit.

Reklamalnak meg, hogy bajuk volt >3000 TCP kapcsolatnal.  Errol meg
annyit, hogy aki akkora gepet fog csinalni, hogy >3000 kapcsolattal
dolgozzon, annak valoszinuleg lesz embere arra, hogy beallitsa a
FreeBSD-t, nekik a feladatuk valami olyasmi lett volna, hogy bemutassak,
melyik OS a legjobb ilyen erosebb megprobaltatasokra.  Tovabbra is
allitom: a cikkben szereplo operacios rendszerek kozul a FreeBSD es a
Solaris a legjobb (az elso tesztuk szerint a ket leglassabb)  Azt nem
tudtak tesztelni, milyen az, amikor a rendszer tobb honapon at eroteljes
terhelesnek van kiteve (es nem "mennyi ido alatt tudunk letrehozni 10000
filet")... 

A cikk *javasolja* az async opcio hasznalatat az erosebb diszk terhelest
kovetelo alkalmazasokhoz.  Nem, nem stripingolni kell, nem tobb cache-t a
RAID kartyaba, nem jobban beallitani a newfs parametereket, es nem
softupdates-t hasznalni.  A softupdates csaknem hozza az async sebesseget,
viszont a ketto megbizhatosaga osszehasonlithatatlan, kulonosen abban az
esetben, amirol beszelnek, a sok diszk muveletnel.  Gondolom ha valaki
ramutatott volna, siman bekapcsoljak az SCSI write cache-t is tagged
queuingnel, es javasoljak ezt az opciot is a "nagy diszk terhelesu"
alkalmazasokhoz...  (tagged queuing nelkul meg elmegy az SCSI write cache,
SCSI vinyokkal nem nagyon volt olyan gond, mint az IDE-sekkel, viszont
tagged queuingnal mar magara vessen az illeto, ha hasznalja).

A >3000 TCP kapcsolatos problemahoz meg annyit: ilyeneket allitgattak:
net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 Ez kicsit soknak
tunik nekem!  Szivesen megneztem volna nehany parametert futas kozben.
Mondjuk egy fileszervernel a kuldo iranyt lehet, hogy en is felraknam
ilyen magasra, de ha sok kapcsolatom van, akkor a bejovo iranyt levennem
(persze, ha szukseges).  Namost az o tesztjuk abbol allt, hogy irtak egy
kis programot, amire ha kapcsolodtak, visszaadott egy "450 server busy"
jellegu uzenetet.  Tehat rohadt sok, rohadt kicsi kapcsolat.  Ehhez nem
kell 65535-os sendspace, sot!  Ha jol szamolom, ebben az esetben olyan 400
mega memoriat igenyelnek a network bufferek, amiben ezek a 128k-nyi
lefoglalasok rohadt gyorsan tortennek (sok kis kapcsolat).  Nem jo ez
igy...  Vajon hogy nezett ki a netstat -m output 3000 kapcsolatnal, ha az
nmbclusters=60000 volt?  Meg szep, hogy nem ment 3000 kapcsolat fole.
(Nem, nem az nmbclusterst kellett volna feljebb rakni.)


Na csa'


Mico