"Pudeļu kakls" ir lieliski aprakstošs termins. Tas apraksta mākslīgu ierobežojumu kāda veida saziņai, mijiedarbībai vai informācijas nodošanai. Un tas liek domāt, ka kāda maģiska veiksmes, naudas un atjautības kombinācija var sagraut šo sastrēgumu un ļaut plūst visām labajām lietām.
Problēmas ar veiktspējas sastrēgumiem ir tās, ka tās var būt grūti identificēt. Vai tas ir centrālais procesors? Tīkls? Neveikls koda gabals? Bieži vien visredzamākais vaininieks patiesībā ir kaut kas lielāks un mistiskāks. Un, ja veiktspējas mīklas paliek neatrisinātas, IT vadība var saskarties ar Hobsona izvēli starp nezināšanas atzīšanu un attaisnojumu izdomāšanu.
Par laimi, tāpat kā ar medicīniskām diagnozēm vai detektīvdarbu, palīdz arī pieredze. Balstoties uz mūsu gadiem ilgo slepkavošanu un eksperimentēšanu, mēs esam apkopojuši 15 visdrīzāk sastopamās kaites un ieteiktos līdzekļus, lai palīdzētu jūsu IT darbībai izsekot un novērst veiktspējas problēmas.
Daži no šiem trūkumiem ir acīmredzamāki nekā citi. Visticamāk, jums ir kaut kas sakāms par dažiem saviem viltīgajiem spoileriem (un mēs labprāt dzirdētu jūsu pasakas par viņiem). Bet, identificējot kopīgus ātruma slepkavas visās IT disciplīnās, mēs ceram sākt jūsu centienus izveidot visaugstākās veiktspējas infrastruktūru, ko jūsu resursi ļaus.
Nr. 1: iespējams, tie nav serveri
Serveru jauninājumi, kas tika izmantoti, lai panāktu visu atšķirību, tāpēc vecais zāģis "Kad viss pārējais neizdodas, mest vairāk aparatūras" joprojām pastāv. Dažos gadījumos tas joprojām ir taisnība. Bet cik daudz IT patiesībā ir tik intensīvs, lai aprēķinātu? Parasti jūs varat ietaupīt daudz laika un naudas, novēršot mataino acs ābolu no servera aparatūras. Servera spektra apakšējā galā ir vairāk nekā pietiekami daudz zirgspēku ikdienas uzdevumu veikšanai.
Šeit ir viens konkrēts piemērs. Tīklā, kurā bija vairāk nekā 125 lietotāji, vecāka gadagājuma Windows domēna kontrolleris, šķiet, bija gatavs nomaiņai. Šis serveris sākotnēji darbināja Windows 2000 Server un pirms kāda laika tika jaunināts uz Windows Server 2003, taču aparatūra palika nemainīga. Šis HP ML330 ar 1 GHz procesoru un 128 MB RAM darbojās kā Active Directory domēna kontrolleris, kas veica visas AD FSMO lomas, darbināja DHCP un DNS pakalpojumus, kā arī IAS (interneta autentifikācijas pakalpojumus).
Melase, vai ne? Patiesībā tas faktiski paveica darbu tikai lieliski. Tās nomaiņa bija HP DL360 G4 ar 3Ghz procesoru, 1 GB RAM un spoguļattēlu 72 GB SCSI diskdziņiem. Veicot visus šos pakalpojumus, tas gandrīz nemaz nerada slodzi - un veiktspējas atšķirība nav pamanāma.
Ir viegli noteikt lietojumprogrammas, kas apēdīs visu jūsu procesoru un atmiņu, taču tās parasti ir diezgan specializētas. Gandrīz par visu pārējo pazemīgā preču kaste izdarīs triku.
Nr. 2: paātriniet šos vaicājumus
Jūs varat izveidot visskaistāko lietojumprogrammu pasaulē, taču, ja piekļuve aizmugures datu bāzes serveriem rada vājo vietu, jūsu lietotāji vai klienti nebūs apmierināti. Tāpēc precīzi noregulējiet šos datubāzes vaicājumus un palieliniet veiktspēju.
Trīs pamata pasākumi var palīdzēt uzlabot vaicājumu veiktspēju. Pirmkārt, lielākā daļa datu bāzes produktu ietver rīkus (piemēram, DB2 UDB for iSeries ’Visual Explain), kas izstrādes laikā var sadalīt jūsu vaicājumu, sniedzot atgriezenisko saiti par sintaksi un aptuveno dažādu SQL paziņojumu sadaļu laiku. Izmantojot šo informāciju, atrodiet garākās vaicājuma daļas un sadaliet tās tālāk, lai redzētu, kā jūs varētu saīsināt izpildes laiku. Daži datu bāzes produkti ietver arī veiktspējas padomu rīkus, piemēram, Oracle automātisko datu bāzes diagnostikas monitoru, kas sniedz ieteikumus (piemēram, ierosina izveidot jaunu indeksu), lai paātrinātu vaicājumus.
Pēc tam iestudēšanas serverī ieslēdziet datu bāzes uzraudzības rīkus. Ja jūsu datu bāzē trūkst uzraudzības atbalsta, varat izmantot trešās puses uzraudzības produktu, piemēram, Fidelia NetVigil. Ja monitori ir iespējoti, ģenerējiet datplūsmu pret datu bāzes serveri, izmantojot slodzes testēšanas skriptus. Pārbaudiet apkopotos datus, lai redzētu, kā jūsu vaicājumi veicās, kamēr esat noslogots; šī informācija var novest pie vēl kāda vaicājuma uzlabošanas.
Ja jums ir pietiekami daudz servera resursu, lai diezgan precīzi atdarinātu jauktās slodzes ražošanas vidi, varat izpildīt vaicājumu regulēšanas trešo kārtu, izmantojot slodzes testēšanas rīku, piemēram, OpenSTA, kā arī datu bāzes uzraudzību, lai redzētu, kā jūsu vaicājumi darbojas līdzās citām lietojumprogrammām, kuras skāra datu bāzē.
Mainoties datu bāzes apstākļiem - palielinoties apjomam, ierakstu dzēšanai utt. - turpiniet testēšanu un regulēšanu. Tas bieži vien ir vērts pūļu.
Nr. 3: Cik maksā aizsardzība pret vīrusiem?
Aizsardzība pret vīrusiem kritiskos serveros ir pamatprasība, īpaši Windows serveriem. Trieciens tomēr var būt sāpīgs. Daži vīrusu skeneri ir uzmācīgāki nekā citi un var ievērojami samazināt servera veiktspēju.
Mēģiniet veikt veiktspējas testus, darbojoties vīrusu skenerim un bez tā, lai noteiktu ietekmi. Ja bez skenera redzat ievērojamu uzlabojumu, ir pienācis laiks meklēt citu pārdevēju. Pārbaudiet arī īpašās funkcijas. Atspējojiet reāllaika skenēšanu, un bieži jūs uzlabosiet veiktspēju.
Neatkarīgi no tā, cik labi uzrakstīta jūsu biznesa loģika, izvietojot to vidējā līmenī, jums būs jāpielāgo lietojumprogrammu servera izpildlaika vide, lai maksimizētu veiktspēju.
Tāpat kā vintage stereo ar daudzām pogām skaņas kvalitātes uzlabošanai, arī tādu pārdevēju kā BEA, IBM un Oracle lietojumprogrammu serveri piegādā galvu reibinošu vadības komplektu. Viltība ir pagriezt pogas tieši pareizi, atkarībā no lietojumprogrammas atribūtiem.
Nr. 4: vidējā līmeņa maksimizēšana
Neatkarīgi no tā, cik labi uzrakstīta jūsu biznesa loģika, izvietojot to vidējā līmenī, jums būs jāpielāgo lietojumprogrammu servera izpildlaika vide, lai maksimizētu veiktspēju.
Tāpat kā vintage stereo ar daudzām pogām skaņas kvalitātes uzlabošanai, lietojumprogrammu serveri no tādiem pārdevējiem kā BEA, IBM un Oracle piegādā galvu reibinošu vadības komplektu. Viltība ir pagriezt pogas tieši pareizi, atkarībā no lietojumprogrammas atribūtiem.
Piemēram, ja jūsu lietojumprogramma ir sarežģīta ar servletu, ieteicams iespējot servletu kešatmiņu. Tāpat, ja jūsu lietojumprogramma izmanto daudz SQL priekšrakstu, lai atbalstītu lielu lietotāju loku, vēlēsities iespējot sagatavoto izrakstu kešatmiņu un iestatīt kešatmiņas maksimālo lielumu, lai tas būtu pietiekami liels, lai atbalstītu paredzēto darba slodzi.
Viena no galvenajām jomām, kur veiktspējas regulēšana patiešām var palīdzēt, ir datu bāzes savienojumu kopa. Iestatiet minimālo vai maksimālo savienojumu pārāk zemu, un jūs noteikti izveidosiet sašaurinājumu. Uzstādiet tos pārāk augstu, un jūs, visticamāk, redzēsit palēninājumu, ko rada pievienotā pieskaitāmā summa, kas nepieciešama, lai uzturētu lielāku savienojuma kopu.
Ja zināt paredzēto darba slodzi, noregulējiet lietojumprogrammu servera izpildlaiku, iestatot lietojumprogrammu serveri, ieslēdzot veiktspējas uzraudzības rīkus, piemēram, IBM Tivoli Performance Viewer for WebSphere. Izmantojot slodzes ģenerēšanas rīku, izveidojiet sagaidāmo noslodzi, pēc tam saglabājiet uzraudzības rezultātus un atskaņojiet tos, lai analizētu, kuras pogas ir jāpielāgo.
Ražošanas laikā ieteicams ieslēgt pasīvu zemu pieskaitāmo līmeni, lai saglabātu cilnes izpildlaikā. Ja darba slodze laika gaitā mainās, vēlēsities veikt jaunu veiktspējas pārskatu.
Nr. 5: optimizējiet tīkla savienojamību
Lielākajai daļai vidēja līmeņa uzņēmumu serveru tagad ir divu gigabaitu NIC, taču lielākā daļa no tiem neizmanto otro vadu. Turklāt gigabita slēdža cenas ir pazeminājušās. Izmantojot 120 MB / s saiti uz jūsu failu serveri, vairāki 100 megabitu klienti vienlaicīgi var piekļūt ātrdarbīgiem failiem.
Pat bez gigabaita pārslēgšanas NIC savienošanai vajadzētu būt pamatprincipam. Vienkāršāk divu NIC sasaistīšana dod jums liekumu, taču pievienojiet pārraides slodzes līdzsvarošanu, un jūs varat efektīvi dubultot izejošo joslas platumu. Komandu komandas ar pārslēgšanos palīdz nodrošināt tādu pašu efektu uz ienākošo datplūsmu. Gandrīz katrs lielākais serveru pārdevējs piedāvā NIC komandas draiverus - un ir arī trešo pušu utilītas. Tas ir liels, lēts joslas platuma palielinājums.
Nr. 6: Tīmekļa serveru likvidēšana
Vai tiešām jūs varat darīt tik daudz, lai pielāgotu tīmekļa serveri un palielinātu veiktspēju? Faktiski ir - galvenokārt pielāgojot nedaudzus kritiskos iestatījumus, lai tie atbilstu jūsu sagaidāmajai produkcijas datplūsmai.
Tiem tīmekļa serveriem, kas jau tiek ražoti, vispirms apkopojiet reāllaika tīmekļa serveru statistikas datus (lielākajai daļai galveno tīmekļa serveru ir iebūvēta šī funkcionalitāte). Pēc tam pārejiet uz iestudējumu, lai noteiktu, kuri parametri, ja tādi ir, jāpielāgo.
Pakāpiena serverī aktivizējiet tīmekļa servera veiktspējas uzraudzības rīkus. Veiciet slodzes pārbaudi un pārbaudiet attiecīgos parametrus, piemēram, reakcijas laiku, nosūtītos un saņemtos baitus, kā arī pieprasījumu un atbilžu skaitu.
Galvenie parametri, kurus vēlaties pielāgot atkarībā no datplūsmas apjoma, ir kešatmiņa, pavedieni un savienojuma iestatījumi.
Iespējot kešatmiņu bieži izmantotam saturam; Daži tīmekļa serveri ļauj dinamiski kešatmiņā saglabāt failus, pamatojoties uz lietojumu, turpretī citi pieprasa norādīt, kas tiks saglabāts kešatmiņā. Pārliecinieties, vai maksimālais kešatmiņas lielums ir pietiekams gaidāmajai datplūsmai. Un, ja jūsu tīmekļa serveris atbalsta kešatmiņas paātrināšanu, iespējojiet to arī.
Vītņu un savienojuma iestatījumiem iestatiet minimumus un maksimumus atbilstoši paredzamajai slodzei. Savienojumiem ir jānosaka arī maksimālais pieprasījumu skaits vienam savienojumam un savienojuma taimauta iestatījums. Neiestatiet nevienu no šīm vērtībām par mazu vai par lielu, pretējā gadījumā var rasties palēnināšanās.
Nr. 7: WAN bēda
Vai domājat, ka jums ir jāatgūst WAN joslas platums? Jūs varat viegli iztērēt paketi satiksmes veidošanas ierīcēm vai kešatmiņas dzinējiem, mēģinot ierobežot WAN joslas platuma izmantošanu. Bet ja nu tā nav pīpe?
Pirmās lietas vispirms: pirms kaut ko pērkat, pārliecinieties, vai satiksme šķērso WAN. Tīkla analīzes rīki, piemēram, Ethereal, ntop, Network Instrument’s Observer vai WildPacket's EtherPeek NX, var sniegt jaunu ieskatu tajā, kas patiesībā ir vadā.
Jums var šķist, ka jūsu Active Directory replikācijas laiki ir iestatīti pārāk zemu un vienkārši konfigurējot lielākus replikācijas intervālus, darbadienā var nopirkt elpošanas telpu. Vai daži attālās vietās esoši lietotāji kartē koplietošanu nepareizajiem serveriem un velk lielus failus pa WAN, nemanot? Vai ilgstoši invalīdu IPX tīkla paliekas joprojām peld apkārt? Dažas WAN problēmas noved pie nepareizas lietojumprogrammu konfigurēšanas, kur satiksme tiek virzīta pāri WAN, kad tai vajadzēja palikt lokālai. Regulāri ziņojumi par WAN trafika modeļiem ļaus ietaupīt naudu un galvassāpes.
Nr. 8: Spēlēsim jauki
Pārāk bieži lietojumprogrammas, tīmekļa pakalpojumi un vietnes no vairākiem uzņēmuma departamentiem sacenšas par servera resursiem. Lai gan katrs no šiem komponentiem var būt pats par sevi labi noregulēts, citas nodaļas lietojumprogrammai, kas arī izmanto tās pašas ražošanas kopas, var būt slikti noregulēts vaicājums vai kāda cita problēma, kas savukārt ietekmē jūsu lietotājus vai klientus.
Tuvākajā laikā viss, ko jūs varat darīt, ir sadarboties ar sistēmas administratoriem un nodaļu, kurai ir veiktspējas problēma, lai iegūtu izšķirtspēju jūsu lietotājiem vai klientiem. Ilgākā laika posmā izveidojiet kopienu visos departamentos, kas izmanto ražošanas kopas, kur izvietoti jūsu objekti. Strādājiet komandās, lai nodrošinātu pietiekamu finansējumu iestudējuma videi, kas patiešām pārstāv jauktās slodzes ražošanas vidi. Galu galā jūs vēlaties izstrādāt virkni etalonu, kurus var izmantot, lai apstiprinātu jauktas slodzes veiktspēju iestudējuma vidē.
Nr. 9: kešatmiņa, veidošana, ierobežošana, ak, mans!
Ja jūsu WAN ir patiešām maza izmēra - un jūs nevarat atļauties tālsatiksmes rāmja releju tīklu - satiksmes veidošana un kešatmiņa var palīdzēt aizsprostot cauruli.
Satiksmes veidošanas konfigurācijas ir vairāk māksla nekā zinātne. Lietotņu prioritāšu noteikšana bieži ir vairāk politiska nekā tehniska, taču tam var būt milzīga ietekme uz uztverto tīkla veiktspēju.
Kešatmiņa ir pavisam cits zvērs. Tas prasa mazāk darba nekā satiksmes veidošana, taču ietekme, iespējams, būs mazāka. Kešatmiņas dzinēji glabā un apkalpo kopīgi pieejamo datu vietējās kopijas, lai samazinātu WAN trafiku. Negatīvie ir tādi, ka dinamisko saturu patiesi nevar saglabāt kešatmiņā, tāpēc e-pasts neizbaudīs to pašu sniegumu.
Nr. 10: Paredzama lāpīšana
Pirmdien ierodaties darbā tikai tāpēc, lai uzzinātu, ka ir pakārts ķekars galddatoru vai ka kritiskās lietojumprogrammas veiktspēja ir palēninājusies līdz pārmeklēšanai. Pēc izmeklēšanas jūs nosakāt, ka cēlonis ir plāksteris, kas tika uzlikts nedēļas nogalē.
Tāpēc jums ir nepieciešami rīki, kas atbalsta plāksteru atcelšanu. Vēl labāk iekļaujiet plāksteru testēšanu kā daļu no plāksteru pārvaldības stratēģijas. Pirmkārt, jums regulāri jāveic inventarizācija par darbvirsmā un serveros spēlētajām lietojumprogrammām un tehnoloģijām. Lielākā daļa sistēmu pārvaldības rīku, piemēram, Microsoft īsziņas, spēj automātiski veikt inventarizāciju.
Pēc tam atkārtojiet lietojumprogrammas un tehnoloģijas iestudējumu vidē. Ja jūsu operētājsistēmā un infrastruktūras programmatūrā nav ielāpu testēšanas rīku, iegūstiet trešās puses rīku, piemēram, FLEXnet AdminStudio vai Wise Package Studio.
Varat arī uzrakstīt dažus skriptus, lai funkcionāli izmantotu platformu vai tehnoloģiju, izmantojot jaunākos ielāpus. Jums būs jāatkārto šis scenārijs (un jāpielāgo skripti), tiklīdz nāk jauni ielāpi un tiek veiktas programmatūras izmaiņas.
