„Úzké místo“ je úžasně popisný termín. Popisuje umělé omezení určité formy komunikace, interakce nebo přenosu informací. A vede člověka k přesvědčení, že nějaká magická kombinace štěstí, peněz a vynalézavosti může toto úzké místo rozbít a nechat plynout všechny dobré věci.
Potíž s úzkými místy výkonu spočívá v tom, že je obtížné je identifikovat. Je to CPU? Síť? Neohrabaný kousek kódu? Nejviditelnějším viníkem je často něco po proudu většího a záhadnějšího. A když hádanky o výkonu zůstanou nevyřešeny, může vedení IT čelit Hobsonově volbě mezi přiznáním nevědomosti a vymýšlením výmluv.
Naštěstí, stejně jako u lékařských diagnóz nebo detektivních prací, pomáhají zkušenosti. Na základě našich let spánku a experimentování jsme shromáždili 15 nejpravděpodobnějších onemocnění - a navrhli jsme nápravu - abychom pomohli vaší IT operaci vystopovat a prolomit problémy s výkonem.
Některé z těchto úzkých míst jsou zjevnější než jiné. S největší pravděpodobností máte co říci o některých svých záludných spoilerech (a rádi bychom o nich vyprávěli). Ale díky identifikaci běžných zabijáků rychlosti napříč IT disciplínami doufáme, že nastartujeme vaši snahu o vytvoření nejvýkonnější infrastruktury, kterou vaše zdroje umožní.
Ne. 1: Pravděpodobně to nejsou servery
Upgradování serverů se používalo k tomu, aby se změnilo, a proto dnes přetrvává stará pila „Když všechno ostatní selže, hodí na to více hardwaru“. V některých případech to stále platí. Kolik IT je ale opravdu výpočetně náročné? Obecně můžete ušetřit spoustu času a peněz otočením chlupaté oční bulvy od hardwaru serveru. Dolní konec spektra serverů má více než dostatečný výkon pro zvládnutí každodenních úkolů.
Zde je jeden konkrétní příklad. V síti více než 125 uživatelů se zdálo, že je starší řadič domény Windows zralý na výměnu. Tento server původně používal Windows 2000 Server a před nějakou dobou byl upgradován na Windows Server 2003, ale hardware zůstal nezměněn. Tento HP ML330 s 1 GHz procesorem a 128 MB paměti RAM fungoval jako řadič domény služby Active Directory nesoucí všechny role služby AD FSMO, provozující služby DHCP a DNS i provozující IAS (Internet Authentication Services).
Melasa, že? Ve skutečnosti to vlastně zvládlo dobře. Jeho náhradou byl HP DL360 G4 s procesorem 3Ghz, 1 GB RAM a zrcadlovými 72 GB SCSI disky. Díky všem těmto službám běží téměř bez jakékoli zátěže - a rozdíl ve výkonu je nepostřehnutelný.
Je snadné identifikovat aplikace, které pojí celý váš procesor a paměť, ale bývají docela specializované. U téměř všeho ostatního bude stačit skromná komoditní krabice.
Č. 2: Urychlete tyto dotazy
Můžete vytvořit nejchytřejší aplikaci na světě, ale pokud přístup k back-endovým databázovým serverům vytvoří úzké místo, vaši koncoví uživatelé nebo zákazníci nebudou spokojeni. Takže tyto databázové dotazy dolaďte a maximalizujte výkon.
Tři základní opatření vám mohou pomoci zlepšit výkon dotazů. Nejprve většina databázových produktů zahrnuje nástroje (jako je například DB2 UDB for iSeries 'Visual Explain), které mohou během vývoje rozčlenit váš dotaz a poskytnout zpětnou vazbu o syntaxi a přibližném načasování různých částí příkazů SQL. Pomocí těchto informací vyhledejte nejdelší části dotazu a rozdělte je dále, abyste zjistili, jak můžete zkrátit dobu provádění. Některé databázové produkty zahrnují také nástroje pro poradenství v oblasti výkonu, jako je automatický diagnostický monitor Oracle, který poskytuje doporučení (například navrhování vytvoření nového indexu) pro urychlení dotazů.
Dále zapněte nástroje pro monitorování databáze na přípravném serveru. Pokud vaše databáze postrádá podporu monitorování, můžete použít monitorovací produkt jiného výrobce, například NetVigil od společnosti Fidelia. Se zapnutými monitory generujte provoz proti databázovému serveru pomocí skriptů pro testování zatížení. Prohlédněte si shromážděná data, abyste zjistili, jak vaše dotazy fungovaly při načítání; tyto informace vás mohou vést k dalšímu vyladění dotazu.
Pokud máte dostatek serverových prostředků k tomu, abyste poměrně úzce napodobili své produkční prostředí pro smíšené pracovní vytížení, můžete provést třetí kolo ladění dotazů pomocí nástroje pro testování zátěže, jako je OpenSTA, plus monitorování databáze, abyste viděli, jak vaše dotazy fungují společně s jinými aplikacemi, které zasáhly databáze.
Jak se mění podmínky databáze - s růstem objemu, mazáním záznamů atd. - pokračujte v testování a ladění. Často to stojí za námahu.
Č. 3: Jaké náklady, antivirová ochrana?
Virová ochrana na kritických serverech je základním požadavkem, zejména pro servery Windows. Dopad však může být bolestivý. Některé antivirové programy jsou rušivější než jiné a mohou výrazně snížit výkon serveru.
Zkuste provést testy výkonu se spuštěným antivirovým programem a bez něj, abyste zjistili dopad. Pokud zaznamenáte výrazné zlepšení bez skeneru, je čas hledat jiného dodavatele. Zkontrolujte také konkrétní funkce. Zakažte skenování v reálném čase a často zvýšíte výkon.
Bez ohledu na to, jak dobře je vaše obchodní logika napsána, když ji nasadíte na střední vrstvu, budete muset vyladit běhové prostředí aplikačního serveru, abyste maximalizovali výkon.
Aplikační servery od dodavatelů, jako jsou BEA, IBM a Oracle, dodávají závratnou sadu ovládacích prvků, jako je stereofonní stereofonní zvuk s knoflíky pro vylepšení kvality zvuku. Trik spočívá v otočení knoflíků správným způsobem, v závislosti na atributech vaší aplikace.
Č. 4: Maximalizace střední úrovně
Bez ohledu na to, jak dobře je vaše obchodní logika napsána, při nasazení na střední vrstvu budete muset vyladit běhové prostředí aplikačního serveru, abyste maximalizovali výkon.
Aplikační servery od dodavatelů, jako jsou BEA, IBM a Oracle, dodávají závratnou sadu ovládacích prvků, jako je stereofonní stereofonní zvuk s knoflíky pro vylepšení kvality zvuku. Trik spočívá v otočení knoflíků správným způsobem, v závislosti na atributech vaší aplikace.
Pokud je vaše aplikace například servlet těžká, budete chtít povolit ukládání servletů do mezipaměti. Podobně, pokud vaše aplikace používá mnoho příkazů SQL k podpoře velké uživatelské základny, budete chtít povolit ukládání do mezipaměti připravených příkazů a nastavit maximální velikost mezipaměti, aby byla dostatečně velká, aby podporovala zamýšlenou zátěž.
Jednou z hlavních oblastí, kde může ladění výkonu opravdu pomoci, je fond připojení k databázi. Nastavte minimální nebo maximální počet připojení příliš nízko a je jisté, že vytvoříte úzké místo. Nastavte je příliš vysoko a pravděpodobně uvidíte zpomalení vyplývající z přidané režie potřebné k udržení většího fondu připojení.
Pokud znáte zamýšlenou pracovní zátěž, vyladěte běh aplikačního serveru zapnutím nástrojů pro sledování výkonu, jako je IBM Tivoli Performance Viewer pro WebSphere, na připravovaném aplikačním serveru. Pomocí nástroje pro generování zátěže vytvořte očekávané množství pracovní zátěže, poté uložte výsledky monitorování a přehrajte je zpět, abyste mohli analyzovat, které knoflíky je třeba upravit.
Ve výrobě je dobré zapnout pasivní monitorování s nízkou režií, abyste měli přehled o době běhu. Pokud se vaše pracovní zátěž v průběhu času mění, budete chtít provést novou kontrolu výkonu.
Č. 5: Optimalizace síťového připojení
Většina podnikových serverů střední úrovně má nyní duální gigabitové síťové karty - ale většina z nich nepoužívá druhý kanál. Ceny gigabitových přepínačů navíc klesly až na dno. Díky odkazu na váš souborový server o rychlosti 120 Mb / s může řada 100megabitových klientů dosáhnout přístupu k souborům bezdrátovým připojením současně.
I bez gigabitového přepínání by mělo být propojení NIC základem. Nejjednodušší je, že propojení dvou síťových karet vám poskytne redundanci, ale přidejte rozložení zátěže přenosu a můžete efektivně zdvojnásobit odchozí šířku pásma. Stejný účinek na příchozí provoz poskytne použití týmů podporovaných přepínači. Téměř každý hlavní prodejce serverů nabízí ovladače sdružování NIC - a existují také nástroje třetích stran. Je to velká a levná podpora šířky pásma.
Č. 6: Ukončení vašich webových serverů
Existuje opravdu tolik, co můžete udělat pro vyladění webového serveru a maximalizaci výkonu? Ve skutečnosti existuje - hlavně úpravou několika kritických nastavení tak, aby odpovídaly produkčnímu provozu, který očekáváte.
U webových serverů, které jsou již ve výrobě, začněte shromažďováním statistik webového serveru v reálném čase (většina hlavních webových serverů má tuto funkci zabudovanou). Poté přejděte na fázování, abyste zjistili, které parametry, pokud existují, je třeba upravit.
Aktivujte nástroje pro sledování výkonu webového serveru na pracovním serveru. Proveďte zátěžový test a zkontrolujte příslušné parametry, jako je doba odezvy, odeslané a přijaté bajty a počet požadavků a odpovědí.
Mezi klíčové parametry, které budete chtít vyladit v závislosti na objemu provozu, patří ukládání do mezipaměti, vytváření vláken a nastavení připojení.
Povolit ukládání do mezipaměti pro často používaný obsah; některé webové servery umožňují dynamicky ukládat soubory do mezipaměti podle využití, zatímco jiné vyžadují, abyste určili, co se bude ukládat do mezipaměti. Ujistěte se, že vaše maximální velikost mezipaměti je dostatečná pro provoz, který očekáváte. A pokud váš webový server podporuje akceleraci mezipaměti, povolte to také.
Pro nastavení vláken a připojení nastavte minima a maxima v souladu s očekávanou pracovní zátěží. U připojení budete také muset definovat maximální počet požadavků na připojení a nastavení časového limitu připojení. Nenastavujte žádnou z těchto hodnot příliš malou nebo příliš velkou, mohlo by dojít ke zpomalení.
Č. 7: Běda WAN
Myslíte si, že potřebujete získat zpět šířku pásma WAN? Můžete snadno utratit balíček za zařízení určující provoz nebo ukládání do mezipaměti ve snaze znovu využít využití šířky pásma WAN. Ale co když to není dýmka?
Nejdříve nejdříve: Než si něco koupíte, získejte solidní představu o tom, jaký provoz prochází sítí WAN. Nástroje pro síťovou analýzu, jako je Ethereal, ntop, Network Instrument's Observer nebo WildPacket's EtherPeek NX, vám mohou poskytnout nový pohled na to, co ve skutečnosti je.
Možná zjistíte, že časy replikace pro vaši službu Active Directory jsou nastaveny příliš nízko a jednoduchá konfigurace delších intervalů replikace vám může během pracovního dne nabídnout dýchací místnost. Mapují někteří uživatelé ve vzdálených umístěních sdílené složky na nesprávné servery a tahají velké soubory přes WAN, aniž by si to uvědomovali? Stále se vznášejí pozůstatky dlouhodobě deaktivované sítě IPX? Některé problémy s WAN se snižují na nesprávnou konfiguraci aplikací, kdy je provoz směrován přes WAN, když měl zůstat místní. Pravidelné zprávy o vzorcích provozu WAN ušetří peníze a bolesti hlavy.
Č. 8: Hrajme si pěkně
Příliš často aplikace, webové služby a weby z různých oddělení v rámci podniku soutěží o prostředky serveru. I když každá z těchto komponent může být dobře vyladěna sama o sobě, aplikace z jiného oddělení, která také používá stejné produkční klastry, může mít špatně vyladěný dotaz nebo nějaký jiný problém, který zase ovlivní vaše uživatele nebo zákazníky.
V blízké budoucnosti můžete pouze pracovat se správci systému a oddělením, které má problém s výkonem, aby bylo možné získat řešení pro vaše uživatele nebo zákazníky. Z dlouhodobého hlediska vytvořte komunitu napříč všemi odděleními, která používají produkční klastry, kde jsou nasazeny vaše objekty. Pracujte napříč týmy a zajistěte, aby existovalo dostatečné financování pro pracovní prostředí, které je skutečně reprezentativní pro produkční prostředí smíšené pracovní zátěže. Nakonec budete chtít vyvinout řadu srovnávacích testů, které lze použít k ověření výkonu smíšeného pracovního vytížení v pracovním prostředí.
Č. 9: Ukládání do mezipaměti, tvarování, omezování, ach můj bože!
Pokud je vaše WAN skutečně poddimenzovaná - a vy si nemůžete dovolit síť dálkových přenosů rámců - utváření provozu a ukládání do mezipaměti vám může pomoci uvolnit potrubí.
Konfigurace ovlivňující provoz jsou více uměním než vědou. Stanovení priorit aplikací je často političtější než technické, ale může mít obrovský dopad na vnímaný výkon sítě.
Ukládání do mezipaměti je úplně jiné zvíře. Vyžaduje méně práce než utváření provozu, ale dopad bude pravděpodobně menší. Cachingové motory ukládají a obsluhují místní kopie běžně přístupných dat, aby se snížil provoz WAN. Nevýhodou je, že dynamický obsah nelze skutečně ukládat do mezipaměti, takže e-mail nebude mít stejný nárůst výkonu.
Č. 10: Prediktivní oprava
Do práce dorazíte v pondělí, jen abyste se dozvěděli, že je zavěšena spousta desktopů nebo že výkon kritické aplikace zpomalil na procházení. Po prošetření zjistíte, že příčinou je oprava, která byla použita o víkendu.
Proto potřebujete nástroje, které podporují vrácení oprav. Ještě lepší je zahrnout testování oprav jako součást vaší strategie správy oprav. Nejprve musíte pravidelně provádět inventarizaci aplikací a technologií ve hře na počítačích a serverech. Většina nástrojů pro správu systémů, jako je Microsoft SMS, má schopnost automaticky za vás inventarizovat.
Dále replikujte aplikace a technologie do pracovního prostředí. Pokud váš operační systém a software pro infrastrukturu neobsahují nástroje pro testování oprav, pořiďte si nástroj jiného výrobce, jako je FLEXnet AdminStudio nebo Wise Package Studio.
Alternativně můžete napsat několik skriptů pro funkční procvičení platformy nebo technologie s nejnovějšími opravami ve hře. Tento scénář budete muset opakovat (a upravovat skripty), jakmile přijdou nové opravy a budou provedeny změny softwaru.
