Linux 2.4 vs Linux 2.6 vs. FreeBSD 5.1 vs. NetBSD 1.6.1 vs. OpenBSD 3.4

Linux

Benchmarking BSD and Linux

A legjobb a Linux 2.6, második a FreeBSD 5.1. A NetBSD átlagos, az OpenBSD pedig katasztrófa.



Egy nagyon érdekes tanulmány bukkant fel az Interneten a minap. A tanulmány célja az volt, hogy kivizsgálja a napjaink Unix alapú (és Unix-szerű) operációs rendszereinek a hálózatos skálázhatóságát egy általános célú PC hardveren.

A vizsgálódás arra irányult, hogy hogyan lehet egy webszervert úgy létrehozni, hogy az a legskálázhatóbb legyen. Melyik operációs rendszert kell ahhoz választani, hogy túl lehessen élni akár a Slashdot Effektust is.

Lássuk:A tesztekben az alábbi operációs rendszerek vettek részt:

  • Linux 2.4.22
  • LInux 2.6.0-test7
  • OpenBSD 3.4-Current
  • FreeBSD 5.1-RELEASE
  • NetBSD 1.6.1-RELEASE

    A tesztek alatt számos izzasztó próba várt az operációs rendszerekre. Például a socket meghívása tízezer alkalommal, megadott porthoz bindelés, fork, mmap benchmark, fragmentáció mérés, kapcsolódási latency mérése, HTTP latency mérése.

    A tesztgép egy Dell Inspiron 8000 volt, 900 MHz-es Pentium 3 processzorral és 256 MB RAM-mal. A hálózati csatoló egy MiniPCI Intel eepro100 kártya volt, amely jól támogatott mindegyik operációs rendszer alatt.

    Az eredmények:

    A Linux 2.6-os kernel minden tesztben jól teljesített. A tesztet készítő arc szerint ha 2.4-es Linux kernelt használsz, akkor itt az ideje, hogy válts 2.6-ra.

    A FreeBSD is meglehetősen jó eredményeket produkált. A tesztet végzők meglepődtek, hiszen azt hitték, a BSD bizniszben az összes szereplő hasonlóan fog majd teljesíteni. Nem így lett. A NetBSD és az OpenBSD gyengébbek voltak. Az OpenBSD lett a abszolút utolsó. A FreeBSD majdnem olyan jól teljesített, mint a Linux 2.6. A készítők szerint ha BSD-t használsz, akkor FreeBSD-t kell választanod.

    A Linux 2.4 sem rossz, viszont rosszul skálázódik az mmap és a fork hívásoknál.

    A tesztek szerint a NetBSD jól teljesített, de van még mit javítani a skálázhatóságán. A tesztelő a stabil verziót tesztelte, így nem tudja, hogy milyen eredményeket produkálhat a NetBSD jelenlegi fejlesztői kódja.

    Az abszolút vesztes az OpenBSD 3.4 lett. A tesztelő szerint telepítési procedúra rossz, a diszk teljesítmény rossz, a kernel instabil és a hálózatos teljesítményét felülmúlta a nagypapi NetBSD 1.6.1. A tesztelő véleménye: ha OpenBSD-t használsz, itt az ideje váltani.

    A tesztek alatt használt kódokat ki lehet nyerni CVS-ből:

    % cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co libowfat

    % cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co gatling

    ha Liuxot használsz kell a következő is

    % cvs -d :pserver:cvs@cvs.fefe.de:/cvs -z9 co dietlibc

    A teszteredményeket, grafikonokat megtalálod itt. (ez nem az eredeti hely, a dolog iróniája, hogy az eredeti weboldal lepukkant a /. effektus alatt).

    • ( Névtelen (nem ellenőrzött) | 2003. 10. 19., v – 12:53 )

    Nem tudom ez az OpemBSd instabbilsag szerintem nem allja meg a helyet :P

    Lagalabbis jelenleg en Gateway nek hasznalom (ujra mert egy darabig debian volt). Szerintem sokkal jobb eredmenyt produkal mint a linux... (FreeBSD vel meg nem kezdek mert nagyon ne bizok benne. Nem tudom mennyit valtoott 2000 ota de akkoriban nagyon is insecure volt)

    Ehem, es gateway-eden mekkora forgalom van? Az a szokasos irc? Mert az nem is fogja a kernelt elpusztitni. Itt nem is arrol volt szo, hogy melyik jobb adsl router, vagy irc gateway, hanem melyik skalazhatobb jobban, es melyik bir ki olyan szelsoseges korulmenyt, mint mondjuk egy slashdot aradat.

    ( fifteen | 2003. 10. 19., v – 13:17 )

    Azert az okostojasok elolvashattak volna az 5.x-es FreeBSD kiadashoz csapott leirast. Meg koran sem olyan gyors, mint a 4.x, sok helyen tele van meg debug cuccokkal, nincs optimalizalva, etc, etc, ugyhogy egy linux 2.x.y vs FreeBSD 4.x azert mashogy nezett volna ki.

    ( Hijaszu | 2003. 10. 19., v – 14:23 )

    Az jo, hogy ezeket osszehasonlitottak, de jo volna, ha folyamatosan osszehasonlitgatnak - es nem csak webszerver szolgaltatas eseteben :) Szerintem meg a fejlesztok is latnak, hogy hol van meg teendojuk

    Hijaszu

    ( netchan | 2003. 10. 19., v – 17:38 )

    I ended up reinstalling OpenBSD in the swap partition from my Linux installation. In the end I had so little space that I had to copy the logs over to my desktop box after each benchmark, otherwise the filesystem would be full.

    Ha jol ertelmezem, az OpenBSD-t egy majdnem 100%-osan telitett particiora sikerult felrakni, bar nem tudom, hogy ez mennyire befolyasolja az itt elvegzett mereseket, mindenesetre a disk performance sucks-hoz valami koze biztos lehet.

    A masik kerdes meg, hogy mennyi ertelme van full default beallitasokkal tesztelni. Zope-nal volt az a gondom, hogy a http feltoltes fix 40k/sec volt, akarmit is csinaltam (lefele 1.5M/sec). Kb egy het szenvedes (eletem elso unix installacioja volt ez) utan feljebb vittem az egyik tcp puffer erteket, ami megoldotta a problemat. Nem kizart, hogy a tesztben szereplo meres is maskepp nezett volna ki, ha a feladathoz hangolt beallitasokkal vegezte volna el a szerzo.

    Ettol fuggetlenul teny, hogy az obsd nem egy sebessegbajnok, dehat nem is ezert szeressuk ;-)

    netchan

    Disk performance-t irtak, nem FS performance-t.

    Egyebkent van benne igazsag, altalaban nem nagyon szeretik a file

    systemek ha mar tele vannak (nehezebb szabad blockot talalni,

    olvasasnal nehezebb megtalalni a sok adat kozul amelyik kell).

    ext2-nel biztosan ez a helyzet, ReiserFS-nel is tapasztalat szerint

    ez van (epp tegnap tesztelgettem ilyesmit), a tobbinel n/a.

    Aztan lehet hogy az obsd csak a halokatyat nem szerette es azert

    szerepelt le.

    ( Hunger | 2003. 10. 20., h – 10:03 )

    OpenBSD: "The installation routine sucks, the disk performance sucks".

    Eleve nevetséges az aki egy tesztben ilyen értékelést ad, hogy mindenre csak annyit tud mondani, hogy sucks, másrészről ha valaki az OpenBSD telepítőjét szidja, azt nagyon letudom sajnálni. Az OpenBSD telepítőjénél egyszerűbb, hatékonyabb, gyorsabb megoldást még sehol nem láttam... Egyszerűen tökéletes! ;-)

    ( aga | 2003. 10. 20., h – 10:05 )

    Nekem egyetlen bajom van ezzel a teszttel... Ki a banat hasznal egy gyenge notebookot apache szervernek?

    Jo lenne a fenti tesztet eletszeru kornyezetben megismetelni... 256M ram eseten amit a fenti eredmeny tesztelt az szerintem a winchester sebessege a swap miatt :p

    A mai filleres RAM arak mellett nem sok szervert lattam 512M/1G alatti memoriaval nagy terheles alatt.

    Aga

    ( vili | 2003. 10. 22., sze – 09:49 )

    ,,I couldn't find out how to increase FreeBSD's system limit on the number of processes (sysctl said the value was read-only).''

    aki ilyen lama az mit tesztelget?