„Butelio kaklelis“ yra nuostabiai apibūdinantis terminas. Jis apibūdina dirbtinį tam tikros formos bendravimo, sąveikos ar informacijos perdavimo suvaržymą. Tai verčia manyti, kad koks nors stebuklingas sėkmės, pinigų ir sumanumo derinys gali sugadinti tą kliūtį ir leisti plisti visam geram.
Našumo trūkumų yra ta, kad juos sunku nustatyti. Ar tai procesorius? Tinklas? Nerangus kodo bitukas? Dažniausiai akivaizdžiausias kaltininkas iš tikrųjų yra kažkas didesnio ir labiau mistifikuojančio. Kai veiklos mįslės lieka neišspręstos, IT valdymas gali susidurti su Hobsono pasirinkimu - pripažinti nežinojimą ir pasiteisinimus.
Laimei, kaip ir atliekant medicinines diagnozes ar atliekant detektyvinį darbą, patirtis padeda. Remdamiesi daugelio metų slaptumo ir eksperimentų rezultatais, mes surinkome 15 labiausiai tikėtinų negalavimų ir siūlomų priemonių, kad padėtų jūsų IT veiklai atsekti ir išspręsti našumo problemas.
Kai kurie iš šių trūkumų yra akivaizdesni nei kiti. Labiausiai tikėtina, kad turite ką pasakyti apie kai kuriuos savo klastingus spoilerius (ir mes norėtume išgirsti jūsų pasakas apie juos). Bet nustatydami įprastus greičio žudikus visose IT srityse, mes tikimės, kad pradėsime jūsų užduotis sukurti kuo efektyvesnę infrastruktūrą, kurią leis jūsų ištekliai.
Nr. 1: tai tikriausiai nėra serveriai
Serverio atnaujinimai, naudojami viskam pakeisti, todėl šiandien išlieka senas pjūklas „Kai visa kita nepavyksta, meskite daugiau aparatūros“. Kai kuriais atvejais tai vis dar tiesa. Bet kiek iš tikrųjų IT yra tiek daug skaičiuoti? Paprastai galite sutaupyti daug laiko ir pinigų, nukreipdami plaukuotą akies obuolį nuo serverio aparatūros. Apatinis serverio spektro galas turi daugiau nei pakankamai arklio galių kasdieninėms užduotims atlikti.
Štai vienas konkretus pavyzdys. Daugiau nei 125 vartotojų tinkle vyresnio amžiaus „Windows“ domeno valdiklis pasirodė subrendęs pakeisti. Šis serveris iš pradžių veikė „Windows 2000 Server“ ir prieš kurį laiką buvo atnaujintas į „Windows Server 2003“, tačiau aparatinė įranga nepakito. Šis „HP ML330“ su 1 GHz procesoriumi ir 128 MB RAM veikė kaip „Active Directory“ domeno valdiklis, turintis visus AD FSMO vaidmenis, vykdantis DHCP ir DNS paslaugas, taip pat vykdantis IAS (interneto autentifikavimo paslaugas).
Melasa, tiesa? Tiesą sakant, jis iš tikrųjų atliko savo darbą puikiai. Jį pakeitė „HP DL360 G4“ su 3Ghz procesoriumi, 1 GB RAM ir veidrodiniais 72 GB SCSI diskais. Teikdamas visas tas paslaugas, jis beveik nekrauna nieko, o našumo skirtumas yra nepastebimas.
Lengva nustatyti programas, kurios suvalgys visą jūsų procesorių ir atmintį, tačiau jos dažniausiai būna gana specializuotos. Beveik viskam, kukli prekių dėžutė padės apgauti.
Nr. 2: paspartinkite šias užklausas
Galite sukurti puikiausią programą pasaulyje, tačiau jei prieiga prie vidinių duomenų bazių serverių sukuria kliūtį, jūsų galutiniai vartotojai ar klientai nebus patenkinti. Taigi tiksliai sureguliuokite tas duomenų bazės užklausas ir padidinkite našumą.
Trys pagrindinės priemonės gali padėti pagerinti užklausos našumą. Pirma, daugumoje duomenų bazės produktų yra įrankių (pvz., „DB2 UDB for iSeries’ Visual Explain “), kurie gali išskaidyti jūsų užklausą kūrimo metu, teikdami atsiliepimus apie sintaksę ir apytikslį įvairių SQL sakinių skyrių laiką. Naudodamiesi šia informacija, suraskite ilgiausias užklausos dalis ir suskirstykite jas toliau, kad sužinotumėte, kaip galite sutrumpinti vykdymo laiką. Kai kurie duomenų bazės produktai taip pat apima našumo patarimų įrankius, pvz., „Oracle“ automatinį duomenų bazių diagnostikos monitorių, kurie teikia rekomendacijas (pvz., Siūlo sukurti naują indeksą), kad paspartintų užklausas.
Tada sustojimo serveryje įjunkite duomenų bazės stebėjimo įrankius. Jei jūsų duomenų bazėje nėra stebėjimo palaikymo, galite naudoti trečiosios šalies stebėjimo produktą, pvz., „Fidelia“ „NetVigil“. Kai monitoriai įjungti, generuokite srautą į duomenų bazės serverį naudodami apkrovos tikrinimo scenarijus. Išnagrinėkite surinktus duomenis, kad pamatytumėte, kaip jūsų užklausos pasirodė esant apkrovai; ši informacija gali paskatinti dar labiau pakoreguoti užklausą.
Jei turite pakankamai serverio išteklių, kad gana tiksliai imituotumėte mišrų darbo krūvio gamybos aplinką, galite atlikti trečią užklausų derinimo etapą naudodami apkrovos tikrinimo įrankį, pvz., „OpenSTA“, ir duomenų bazės stebėjimą, kad pamatytumėte, kaip jūsų užklausos veikia kartu su kitomis programomis, kurios pasiekia duomenų bazė.
Keičiantis duomenų bazės sąlygoms - didėjant apimčiai, įrašų ištrynimams ir pan. - toliau bandykite ir derinkite. Tai dažnai verta pastangų.
Nr. 3: Kokia apsauga nuo virusų?
Kritinių serverių apsauga nuo virusų yra pagrindinis reikalavimas, ypač „Windows“ serveriams. Tačiau poveikis gali būti skausmingas. Kai kurie virusų skaitytuvai yra labiau įkyrūs nei kiti ir gali žymiai sumažinti serverio našumą.
Pabandykite atlikti našumo testus veikdami virusų skaitytuvu ir be jo, kad nustatytumėte poveikį. Jei be skaitytuvo matote pastebimą patobulinimą, laikas ieškoti kito pardavėjo. Taip pat patikrinkite specifines savybes. Neleiskite tikralaikio nuskaitymo ir dažnai padidinsite našumą.
Nesvarbu, kaip gerai parašyta jūsų verslo logika, ją pritaikę viduriniajam lygiui, turėsite suderinti programų serverio vykdymo aplinką, kad maksimaliai padidintumėte našumą.
Kaip senovinis stereofonas su daugybe mygtukų garso kokybei patobulinti, tokių pardavėjų, kaip „BEA“, „IBM“ ir „Oracle“, programų serveriai teikia svaiginančius valdiklius. Apgaulė yra pasukti rankenėles teisingu keliu, atsižvelgiant į jūsų programos atributus.
Nr. 4: maksimaliai padidina vidurinę pakopą
Nesvarbu, kaip gerai parašyta jūsų verslo logika, ją pritaikę viduriniajam lygiui, turėsite suderinti programų serverio vykdymo aplinką, kad maksimaliai padidintumėte našumą.
Kaip senovinis stereofonas su daugybe mygtukų garso kokybei patobulinti, tokių pardavėjų, kaip „BEA“, „IBM“ ir „Oracle“, programų serveriai teikia svaiginančius valdiklius. Apgaulė yra pasukti rankenėles teisingu keliu, atsižvelgiant į jūsų programos atributus.
Pvz., Jei jūsų programa yra sunki servletui, turėsite įgalinti servleto talpyklą. Panašiai, jei jūsų programa naudoja daug SQL sakinių, kad palaikytų didelę vartotojų bazę, turėsite įgalinti parengtą sakinių talpyklą ir nustatyti didžiausią talpyklos dydį, kad jis būtų pakankamai didelis, kad palaikytų numatytą darbo krūvį.
Viena iš pagrindinių sričių, kur našumo derinimas tikrai gali padėti, yra duomenų bazės ryšio telkinys. Nustatykite mažiausią arba maksimalų ryšį per mažai ir tikrai sukursite kliūtį. Nustatykite juos per aukštai ir greičiausiai pamatysite sulėtėjimą dėl pridėtinių pridėtinių išlaidų, reikalingų palaikyti didesnį ryšio baseiną.
Jei žinote numatomą darbo krūvį, sureguliuokite programų serverio vykdymo laiką, įjungdami našumo stebėjimo įrankius, pvz., „IBM“ „Tivoli Performance Viewer for WebSphere“, pakopinių programų serveryje. Naudodami apkrovos generavimo įrankį sugeneruokite tikėtiną darbo krūvį, tada išsaugokite stebėjimo rezultatus ir atkurkite juos, kad išanalizuotumėte, kurias rankenėles reikia koreguoti.
Vykdant gamybą, verta įjungti pasyvų, mažą pridėtinę kainą, stebėjimą, kad skirtukai būtų rodomi vykdymo metu. Jei laikui bėgant jūsų darbo krūvis keičiasi, norėsite atlikti naują našumo apžvalgą.
Nr. 5: optimizuokite tinklo ryšį
Daugelyje vidutinio lygio įmonės serverių dabar yra dvigubo gigabito NIC, tačiau dauguma jų nenaudoja antrojo vamzdžio. Be to, gigabito jungiklio kainos sumažėjo. Turėdami 120 MB / s nuorodą į failų serverį, keli 100 megabitų klientai vienu metu gali pasiekti laidų spartą.
Net be gigabito perjungimo, NIC klijavimas turėtų būti pagrindinis. Paprasčiausias dviejų tinklų sujungimas suteikia jums perteklių, tačiau pridėkite perdavimo apkrovos balansavimą ir galite efektyviai padvigubinti išeinantį pralaidumą. Naudojant perjungimą palaikomą komandą, tas pats poveikis bus gaunamam srautui. Beveik kiekvienas pagrindinis serverių pardavėjas siūlo NIC komandų tvarkykles - taip pat yra ir trečiųjų šalių komunalinių paslaugų. Tai didelis, pigus pralaidumo padidinimas.
Nr. 6: Interneto serverių likvidavimas
Ar tikrai tiek daug galite padaryti, kad sureguliuotumėte interneto serverį ir padidintumėte našumą? Tiesą sakant, yra - daugiausia koreguojant keletą svarbių parametrų, kad jie atitiktų jūsų tikėtiną gamybos srautą.
Jau gaminamiems žiniatinklio serveriams pirmiausia rinkite realaus laiko žiniatinklio serverio statistiką (dauguma pagrindinių žiniatinklio serverių turi šią funkciją). Tada pereikite prie etapo, kad nustatytumėte, kuriuos parametrus, jei tokių yra, reikia koreguoti.
Sujungimo serveryje suaktyvinkite žiniatinklio serverio našumo stebėjimo įrankius. Atlikite apkrovos testą ir patikrinkite svarbius parametrus, tokius kaip atsakymo laikas, išsiųsti ir gauti baitai, užklausų ir atsakymų skaičius.
Pagrindiniai parametrai, kuriuos norite sureguliuoti, atsižvelgiant į srauto apimtį, yra talpyklos talpinimas, gijų išdėstymas ir ryšio nustatymai.
Įgalinti dažnai naudojamo turinio talpyklą; Kai kurie žiniatinklio serveriai leidžia dinamiškai talpinti failus pagal naudojimą, o kiti reikalauja nurodyti, kas bus talpinama. Įsitikinkite, kad jūsų maksimalus talpyklos dydis yra pakankamas laukiamam srautui. Ir jei jūsų žiniatinklio serveris palaiko talpyklos spartinimą, įgalinkite ir tai.
Norėdami nustatyti sriegimo ir ryšio parametrus, nustatykite mažiausias ir didžiausias vertes pagal numatomą darbo krūvį. Norėdami prisijungti, taip pat turėsite apibrėžti maksimalų užklausų skaičių kiekvienam ryšiui ir ryšio skirtojo laiko nustatymą. Nenustatykite nė vienos iš šių verčių per mažos ar per didelės, nes gali sulėtėti.
Nr. 7: WAN vargas
Manote, kad jums reikia susigrąžinti WAN pralaidumą? Norėdami lengvai sutvarkyti WAN pralaidumo naudojimą, galite lengvai išleisti rinkinį eismo formavimo prietaisams ar talpyklų varikliams. Bet ką daryti, jei tai ne vamzdis?
Pirmiausia pirmiausia: prieš ką nors įsigydami, gerai supraskite, koks srautas kerta WAN. Tinklo analizės įrankiai, tokie kaip „Ethereal“, „ntop“, „Network Instrument's Observer“ ar „WildPacket's EtherPeek NX“, gali iš naujo pažvelgti į tai, kas iš tikrųjų yra laide.
Galite pastebėti, kad „Active Directory“ replikacijos laikas yra nustatytas per mažai ir paprasčiausiai sukonfigūravus ilgesnius replikavimo intervalus, galite nusipirkti kvėpavimo kambarį darbo dieną. Ar kai kurie atokiose vietose esantys vartotojai bendrina bendrinimus su netinkamais serveriais ir traukia didelius failus per WAN to nesuprasdami? Ar seniai neįgalaus IPX tinklo liekanos vis dar sklando? Kai kurios WAN problemos virsta netinkama programos konfigūracija, kai srautas nukreipiamas per WAN, kai jis turėjo likti vietinis. Reguliarūs pranešimai apie WAN srauto modelius leis sutaupyti pinigų ir galvos skausmo.
Nr. 8: žaiskime gražiai
Pernelyg dažnai programos, žiniatinklio paslaugos ir svetainės iš kelių įmonės padalinių varžosi dėl serverio išteklių. Nors kiekvienas iš šių komponentų gali būti tinkamai sureguliuotas, kito departamento, taip pat naudojančio tuos pačius gamybos klasterius, programoje gali būti prastai sureguliuota užklausa ar kita problema, o tai savo ruožtu turi įtakos jūsų vartotojams ar klientams.
Artimiausiu metu viskas, ką galite padaryti, yra dirbti su savo sistemos administratoriais ir skyriumi, kuriam kyla našumo problema, kad gautumėte sprendimą vartotojams ar klientams. Ilgainiui sukurkite bendruomenę visuose departamentuose, kurie naudoja gamybos grupes ten, kur yra jūsų objektai. Dirbkite komandose, kad užtikrintumėte tinkamą finansavimą scenos aplinkai, kuri tikrai atspindi mišrų darbo krūvio gamybos aplinką. Galų gale norėsite sukurti daugybę etalonų, kuriuos būtų galima naudoti norint patvirtinti mišrų darbo krūvį etape.
Nr. 9: Talpinimas, formavimas, ribojimas, oi!
Jei jūsų WAN yra tikrai per mažas - ir jūs negalite sau leisti tolimųjų rėmų-relių tinklo - eismo formavimas ir talpinimas gali padėti atkimšti vamzdį.
Eismo formavimo konfigūracijos yra daugiau menas nei mokslas. Prioritetų nustatymas programoms dažnai yra labiau politinis nei techninis, tačiau tai gali turėti didžiulį poveikį suvokiamam tinklo našumui.
Talpykla yra visai kitas žvėris. Tam reikia mažiau darbo nei formuojant eismą, tačiau poveikis greičiausiai bus mažesnis. Talpyklos varikliai saugo ir teikia vietines dažniausiai pasiekiamų duomenų kopijas, kad sumažintų WAN srautą. Neigiama yra tai, kad dinaminio turinio tikrai negalima išsaugoti talpykloje, todėl el. Paštas nepatiks to paties našumo.
Nr. 10: Nuspėjamas lopymas
Pirmadienį į darbą atvykstate tik sužinoję, kad pakabinta krūva darbalaukių arba kad kritinės programos našumas sulėtėjo. Ištyrę nustatote, kad priežastis yra pleistras, kuris buvo uždėtas savaitgalį.
Štai kodėl jums reikia įrankių, kurie palaiko pleistro grįžimą. Dar geriau, įtraukite pleistro testavimą kaip savo pleistro valdymo strategijos dalį. Pirmiausia turite reguliariai inventorizuoti darbalaukiuose ir serveriuose veikiančias programas ir technologijas. Dauguma sistemų valdymo įrankių, pvz., „Microsoft“ SMS, gali automatiškai atlikti atsargų inventorizaciją.
Tada pakartokite programas ir technologijas į scenos aplinką. Jei jūsų operacinėje sistemoje ir infrastruktūros programinėje įrangoje nėra pleistro testavimo įrankių, gaukite trečiosios šalies įrankį, pvz., „FLEXnet AdminStudio“ arba „Wise Package Studio“.
Arba galite parašyti keletą scenarijų, kad funkcionaliai pritaikytumėte platformą ar technologiją naudodamiesi naujausiais pleistrais. Turėsite pakartoti šį scenarijų (ir pakoreguoti scenarijus), kai atsiras naujų pataisų ir atlikus programinės įrangos pakeitimus.
