| Linuxové noviny | 09/99 | ||
|
| |||
V současné době probhěhly a probíhají testy rychlostí navzájem konkurenčních systémů. Tento článek se pokusí osvětlit zákulisí některých testů a popsat část vývoje Linuxu, která byla těmito testy ovlivněna. V březnu 1999 pověřil Microsoft firmu Mindcraft, aby provedla výkonnostní srovnávací testy systémů NT a Linux. 13. dubna tohoto roku uveřejnila firma Mindcraft výsledky svých rychlostních testů serverů běžících na NT a na Linuxu. K jakému dospěla výsledku? Microsoft Windows NT 4.0 server je dvaapůlkrát rychlejší než Linux jako souborový server a 3,7 krát rychlejší jako webový server. Tento výsledek může být pro mnoho lidí velice překvapující a tak se podíváme, o co přesně šlo, jakými testy servery prošly, za jakých podmínek a o čem tedy vlastně výsledky vypovídají.
Mindcraft - testyTestovány byly souborové a webové servery systémů Microsoft Windows NT 4.0 a RedHat 5.2 s upgradovaným kernelem 2.2.2 na serveru Dell PowerEdge 6300/400. Na Linuxu byla jako souborový server použita Samba 2.0.3 a Apache 1.3.4 jako webový server. Na NT to byla vestavěná podpora SMB jako souborový server a Internet Information Server 4.0 jako webový server.
Konfigurace Dell PowerEdge 6300/400
CPU 4 x 400 MHz Pentium II Xeon
Cache: L1: 16 KBI + 16 KB D; L2:1 MB
RAM 4 GB 100 MHz SDRAM ECC
Disk
PowerEdge RAID II Adapter, 32 MB cache,
RAID 0, BIOS v1.47, stripe
size = 64 KB, write policy = writeback,
read policy = adaptive, cache
policy = directIO, raid across two channels,
with two logical drives:
Drive C/OS: 1 x 9 GB Seagate Cheetah,
Model ST39102LC, 10,000 RPM;
two partitions - one for each OS
Drive D/Data: 8 x 4 GB Seagate Barracuda,
Model ST34573WC, 7,200 RPM;
two partitions - one
data partition for each OS
Cílem bylo prozkoušet oba systémy při různých zátěžích, především při těch extrémních. Souborový server na NT byl schopen poskytovat až 286.7 Mbitů za sekundu (průměrně) oproti linuxovému, který skončil na hranici 114.6 Mbitů za sekundu. Webové servery byly podrobovány zátěži množstvím HTTP GET žádostí za sekundu - měřena byla kvalita a kvantita odpovědí. NT server byl schopen odpovídat na 3771 žádostí za sekundu a vydával data 22.4 Mbitů za sekundu, Linux zvládl 1000 žádostí a při tomto zatížení poskytovaljen 5.9 Mbitů za sekundu. K testování byly použity Ziff-Davisovy NetBench 5.01 (soubory) a WebBench 2.0 (web).
Podrobnější údajeNetBench 5.01 benchmarkDokumentace NetBench 5.01 definuje propustnost jako "počet bytů, které server doručil klientu a převzal od klienta za jednu sekundu". Testy byly prováděny přibližně tím způsobem, že postupně čím dál tím víc klientů se pokoušelo připojovat na server a stahovat soubory. Přibližně od 1-30 klientů se oba systémy chovaly stejně, Linux trochu lépe (asi o 20-25%), při vyšší zátěži (až do 110 klientů) Linux stagnoval na 114 Mbitech za sekundu a NT zvyšovaly výkon až na 286 Mbitů za sekundu při 112 testovacích systémech. Při vyšší zátěži (115-144 klientů) oba systémy ztrácejí výkon, přesto NT s trojnásobně vyšší propustností. Výsledek je tedy takový, že NT server zvládne obsloužit i při velké zátěži podstatně větší množství klientů než Linux, navíc s vyšší propustností.
WebBench 2.0 benchmarkTento test pracuje tak, že velké množství testovacích systémů (klientů) požaduje od webového serveru nějaká různá URL (stránky/soubory). Každý klient může být navíc nastaven tím způsobem, že může požadovat několik URL najednou - komunikace běží ve více vláknech (multiple worker threads). Tímto způsobem je možné vyvolat na webovém serveru obrovské zatížení a sledovat, jak se bude chovat. Pro zátěžový test je tedy spíše než počet klientů důležitější počet takovýchto vláken. Oba systémy byly porovnávány se stejným počtem klientů i vláken a pro výsledek testů byly srovnávány počty vláken (ne počty klientů) a následná propustnost při zátěži. Jak tedy funguje WebBench? Každé vlákno vyšle HTTP žádost a čeká na odpověď. Pokud přijde, okamžitě vyšle novou žádost - tímto způsobem na několika málo systémech (počítačích/klientech) simuluje zátěž odpovídající stovkám reálných uživatelů.A jak test dopadl? NT server zvládá vzrůstající počet žádostí (až 3771 za sekundu) s lineárním nárůstem počtu vláken (až na 288) s propustností 22.4 Mbitů za sekundu při 3771 žádostech za sekundu. A Linux? 160 vláken vzniká již při 1000 žádostech za sekundu a větší zátěž již nezvládá - počet vláken roste a propustnost se snižuje na minimum (žádosti odmítá). Maxima 5.9 Mbitů za sekundu dosáhl při 160 vláknech.
DodatekSpolečnost Mindcraft si také postěžovala, že dokumentace a návody, jak nakonfigurovat kernel pro takovéto účely, se velice těžko shání - je potřeba prohledávat newsgroups, zkoušet, překompilovávat kernel a že nedostaly požadované informace od linuxové komunity, firmy Red Hat, nesehnaly žádné knihy atd. Naopak si pochválily Sambu, že se lehko instaluje a konfiguruje, dokumentace je dobrá a instruktivní. Oproti tomu Apache se choval velmi nestabilně, při zkolabování negeneroval chybové hlášky do logu a při extrémním zatížení potřeboval restart, aby se vrátil k lepšímu výkonu.
Hlasy z "druhé strany"A co na to svět Linuxu? Čím vysvětlit tyto výsledky? Jak je možné, že byl Linux takto výrazně poražen? Především je nutno uvést, že Linux byl původně vyvíjen pro jednoprocesorové architektury a dodnes je to na něm dost znát. Na druhou stranu se na multiprocesorové implementaci nějakou dobu intenzivně pracuje, ale není to záležitost jednoho nebo dvou patchů - je potřeba přepsat značnější část kódu, vše pečlivě otestovat, než se to propustí do stabilních jader. S největší pravděpodobností se multiprocesorová podpora bude v jádrech objevovat pozvolna, resp. už se objevuje, nejsou obvyklé příliš velké změny během jedné či dvou třech následujících verzí. Oproti tomu NT byly už od počátku vyvíjeny s multiprocesorovou podporou, naprostá většina hlavního systémového kódu je psána pro multiprocesorové architektury a je tedy v některých ohledech modernější než Linux. Také mnoho věcí, které s danou problematikou souvisejí, je přímo v jádře operačního systému NT a odpovídající implementace u Linuxu podle filosofie systému do kernelu nepatří a řeší je až software využívající systémová volání. Výsledkem je větší variabilita, menší závislost software na OS, kompatibilita, i když na druhou stranu ztrácíme na rychlosti. Nebudu se příliš rozepisovat do porovnávání obou systémů (nebyl bych objektivní - preferoval bych Linux, i kdyby byl evidentně horší, než jakýkoliv ne-OpenSource systém).
Dosavadní vývoj a opravyOd testů uplynuly již 2 měsíce (píšu tento článek 1. července 1999) a (docela nenápadně) už se podařilo některé problémy identifikovat a většinu z nich i odstranit - vývojáři Linuxu neberou výsledky na lehkou váhu a intenzivně na tom pracují. Neodpustím si poznámku, že podobného přístupu bychom se od Microsoftu asi nedočkali (asi bychom si museli počkat si na nový systém atd.), ale na druhou stranu - ten, kdo prohrál, je Linux, a ne NT. Celé to považuji za do jisté míry přínosnou a přirozenou soutěž. Na druhou stranu jsem si jist, že pozitivní výsledky Microsoft Windows se šíří a propagují v mnohem větších rozměrech, než úspěchy Linuxu - a těch je nemálo. Zde jsem sesbíral některé konkrétnější chyby a opravy. Jistě to není úplné a vyčerpávající, spíše mi jde o princip a demonstraci vývoje kernelu.
Výhrady k testůmTři problémy, které způsobily pomalost Apache na Linuxu, byly nalezeny a částečně opraveny. Výkon sestavy Linux/Apache je stejný jako NT/ISS při mírné zátěži a dostatečně srovnatelný při velké zátěži. Další problém byl identifikován, ale zatím nevyřešen. Vezmeme to trochu podrobněji.Linuxová komunita se především ohrazuje proti tomu, že nereagovala na žádosti, aby poskytla informace o správné konfiguraci linuxových serverů. Mindcraft například údajně nereagoval na žádost Erica Greena, aby mu poskytli více informací o testovacím serveru a charakteru testů. Navíc některé známé chyby a opravy, které byly již zveřejněné a běžně dostupné na Usenetu, emailové konferenci linux-kernel a bug tracking databázi Apache, nebyly brány v potaz. Navíc testy byly sponsorovány Microsoftem a Mindcraft měl k dispozici nejvyšší možnou úroveň podpory systému NT přímo z firemních laboratoří. Mindcraft nezkusil získat (např. koupit) podporu Linuxu, např. Linux Care nebo Red Hat, i když obě z těchto firem komerční podporu nabídly. Mindcraft tedy pravděpodobně nakonfiguroval NT výborně a Linux nedostatečně. Spíše než kritizování testů se ale raději věnujme ostatním věcem, které byly objeveny a zjištěny. Zaměříme se především na webové testy, k souborovým se mi nepodařilo získat tolik informací a některé poznatky jsou společné pro oboje.
Předchozí testyPřestože Apache byl vyvíjen především jako přenositelný, flexibilní a bezpečný server, s menší prioritou pro rychlost a výkonnost, ukázal se jako velmi rychlý v lednových Ziff-Davisových testech roku 1999. Konkrétně, Linux s Apache porazil NT 4.0 s ISS. Navíc, dnes poráží v testech SpecWeb96 Apache ISS na jednoprocesorové architektuře - na druhou stranu ale se speciálním cache-ovacím software.Fakt, že Apache má problémy (chyby) při obsluhování většího množství klientů (více než 125-150) byl již nějakou dobu znám a nebyla to záležitost jen Linuxu, stejné problémy nastávaly i na Solarisu (s Apache). Lednové Ziff-Davisovy testy byly prováděny nad 64MB RAM, nebylo tedy možné udržovat najednou v paměti kód serveru i 60MB testovacích dokumentů WebBench 2.0 (Mindcraft použil 960MB). To vysvětluje rozdílné výsledky obou testů. Všechny tyto testy jsou prováděny nad statickými stránkami, tedy nevyužívají některé inteligentní metody generování dynamických stránek u Apache. Testy, při kterých bylo dosahováno velkých zátěží, odpovídají serverům s více než miliónem přístupů za den. Takto velké servery typicky používají převážně dynamické stránky, při testech byly použity pouze statické stránky, což NT zvýhodňuje. Navíc přesně neodráží skutečnost, kdy je 500 až 1000 klientů najednou připojeno a každý omezen na 28 nebo 56 Kbps, tedy ne 100 klientů se 100 Mbps jako v testech. Test, který toto bere v úvahu, se jmenuje SPECWeb99, ale oficiální výsledky takového testu ještě nebyly zveřejněny.
Chyba č. 1Proč se výkon Apache rapidně sníží při překročení hranice 160 vláken? Bylo objeveno pár chyb v kódu Apache, po jejich opravení se výkon Apache zlepšil třikrát (!). Tyto změny byly laděny na systému IRIX. Později byl tento opravený Apache zkompilován na Linuxu 2.2.5 a zjistilo se, že mezi každým spojením byla potřeba 200 ms prodleva (stejné u Linuxu 2.2.0-2.2.6), tedy Linux umožňoval maximálně 5 spojení za sekundu. Chyba byla analyzována a v kernelu 2.2.7 je opravená (soubory tcp.h a tcp_ipv4.c). Testy SPECWeb 96 potvrdily trojnásobně vyšší výkonnost a odstraněný propad při překročení hranice 160 vláken. Ziff-Davisovy testy také a v neposlední řadě i zkušenosti mnoha administrátorů, kteří konstatovali prudké zlepšení výkonu při přechodu na Apache 1.3.6 a kernel 2.2.7.
Problém č. 2Další problém spočívá v tom, jak Linux a Apache vzájemně spolupracují. Bylo zjištěno, že při velkém počtu vláken a přístupů je 18% času stráveno v plánovači (scheduleru), což znamená, že něco je špatně. Podrobněji, pokud přijde signál, všechny procesy jsou probuzeny (což je velmi náročné) a ten, který se do fronty dostane jako první, dostane procesor a ostatní jsou zase uspány. Řešením je probouzet pouze jeden proces, a ne všechny (wake-one versus wake-all). Navíc Apache používá zamykání souborů k tomu, aby serializoval přístup k volání accept, což na mnoha systémech může způsobovat znatelné zpomalení.Wake-one systém byl zkoušen kupříkladu v patchích na jádra 2.2.8 (Andrea Arcangeli) a stal se součástí jader 2.3.1 a vyšších. S touto úpravou se Apache na Linuxu urychlil a dosáhl stejného výkonu jako na ostatních jednoprocesorových systémech. Na dvouprocesorových se požadovaného zlepšení nedosáhlo. Kernel 2.2.10 má ještě verzi wake-all (soubor kernel/sched.c), na tomto problému se intensivně pracuje, zatím je součástí vývojových 2.3.X jader, na oficiální stabilní verzi si musíme ještě počkat.
Problém č. 3Co způsobuje, že Apache na multiprocesorové architektuře pod Linuxem dosahuje tak slabých výsledků? Jedním z důvodů je ten, že kopírování dat pro posílání protokolem TCP se děje kompletně sériovým způsobem (procesory na sebe musí navzájem čekat). Toto lze bez újmy opravit jednoduchým způsobem - v souboru tcp.c a funkci tcp_do_sendmsg připsat před sledovaný zápis dat unlock_kernel(); a za něj lock_kernel();. Tímto způsobem bychom neměli porušit žádné zamykací požadavky kernelu. Některé connection refused errors problémy odstraní zvýšení konstant v /proc/sys/fs/file-max a /proc/sys/fs/inode-max (na 32768 a 65536).Srovnal jsem jádra 2.2.10 a 2.3.8, (velmi dlouhá) funkce tcp_do_sendmsg se liší pouze v tom, že v 2.3.8 na (úplném) začátku volá unlock_kernel(); a na konci (těsně před return) lock_kernel();. Je tedy potřeba počkat si na stabilní kernel s touto podporou a pro tento kernel navíc zkompilovat Apache s -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT - tímto způsobem se dosáhne požadovaného urychlení pro multiprocesorové systémy.
Problém č. 4Bylo zjištěno, že použitím čtyř 100 Mbitových síťových karet (Fast ethernet) společně se čtyřprocesorovou architekturou se projeví jistý problém (bottleneck) s obsluhou přerušení v Linux kernelu. (Použitím jedné gigabitové karty by se problém obešel). Na opravě se nyní pracuje v rámci vývojové řady kernelu.
Následné rychlostní testyZD laboratoře zopakovaly testy Mindcraftu, ke kterým firma Red Hat poskytla výpomoc na správnou instalaci linuxového serveru (Zacha Browna a Douga Ledforda). Výsledkem testů (jednoprocesorových i víceprocesorových) byl fakt, že NT a Linux mají stejné parametry při lehké zátěži a NT stále porážejí Linux při velké zátěži (1.5-násobně na jednoprocesorových systémech a 2.2-násobně na multiprocesorových systémech). Rozdíl mezi systémy se oproti dubnovým testům snížil, především při extrémní zátěži výkon Linuxu neklesá, ale zůstává konstantní. Jako zajímavost z testů vyplynulo, že Solaris 7 je na multiprocesorových systémech bezkonkurenční - stejný rozdíl, jaký je mezi NT a Linuxem, je v podstatě mezi Solarisem a NT.c't magazin provedl v červnu další testy Linux/Apache a NT/IIS na systému quad Pentium 2 Xeon. Narozdíl od testů z Mindcraftu, tyto obsahovaly i generování dynamických stránek a stromy testovacích stránek, které se nevejdou do operační paměti a je tedy nutno je i číst z disku. Ve všech testech, když byla použita jen jedna ethernetová karta, Linux porazil NT. Po přidání druhé karty NT porazila Linux.
Co na závěr?Pokud někdo chce v budoucnosti provádět seriózní zátěžové testy webových serverů a operačních systémů, měl by především použít nějaké moderní testy, jako je SPECWeb99 spíše než jednoduché a úzce zaměřené, které použil Mindcraft. Pokud se testují dynamicky generované stránky, neměl by se používat starý model, kdy každou žádost obsluhuje separovaný proces - tento systém se u velkých webovských serverů nepoužívá, protože je to příliš pomalé. Vždy by měl použít nějaký moderní systém generování dynamického obsahu stránek (např. mod_perl pro Apache).V kernelu Linuxu je ještě potřeba udělat mnoho změn, aby byl srovnatelný s ostatními systémy na multiprocesorových architekturách. Objevily se i pokusy, že by jednoduchý statický HTTP server byl i součástí kernelu (volitelnou samozřejmě), ale toto jistě není primární řešení. Je potřeba prodělat změny v kernelovém scheduleru, opravit obsluhu přerušení a doladit ostatní související charakteristiky. Myslím, že po několika dalších stabilních verzích kernelu bude Linux porážet NT i na multiprocesorových systémech s více ethernetovými kartami a jeho výkon bude na úrovni Solarisu. Navíc zde nezmiňuji pověstnou stabilitu a bezpečnost UN*Xových a linuxových serverů. V tomto ohledu mají NT ještě mnoho nedostatků, které se navíc obtížně opravují.
Zdroje a související URLhttp://www.mindcraft.com/http://www.zdnet.com/ http://www.kegel.com/ http://www.spec.org/ http://www.acme.com/ http://www.linuxhq.com/ http://kernelnotes.org/ http://bugs.apache.org/ http://www.apache.org/ http://winntmag.com/ ftp://ftp.suse.com/pub/people/andrea/kernel/ http://linuxtoday.com/ 
|
|||