U svijetu hardvera i složenih aplikacija, zloglasna uska grla postala su gotovo mitska: svi o njima pričaju, ali nisu uvijek dobro shvaćena ili ispravno izmjerena. Mnogi ljudi pretpostavljaju da ako je nešto sporo, to je zbog ozbiljne greške ili konfiguracijske pogreške, dok je u stvarnosti, većinu vremena, riječ o neravnoteži između komponenti ili softverskoj arhitekturi koja se ne skalira onako dobro kako se očekivalo.
Ako vas zanima kako otkriti uska grla bez oslanjanja na sintetičke kriterije (bilo da se radi o igraćem računalu, masovnoj poslovnoj aplikaciji ili distribuiranim sustavima poput BizTalka), morate ići dalje od pukog gledanja na brojke korištenja CPU-a ili GPU-a. Morate promatrati ponašanje u stvarnom svijetu pod opterećenjem, točno interpretirati podatke iz alata poput Windows Performance Recordera i slijediti metodičan pristup, mijenjajući jednu stvar istovremeno i ponovno mjereći.
Što je stvarno usko grlo (u hardveru i softveru)
Jednostavno rečeno, usko grlo je točka gdje se sve sužava , komponenta ili dio sustava koji ograničava brzinu kojom ostatak može raditi. Na računalu to može biti CPU, RAM, GPU, disk ili čak mreža; u velikoj aplikaciji to može biti sloj orkestracije, preopterećena baza podataka, neučinkovit algoritam ili spora vanjska usluga.
U hardveru, klasičan primjer je kombiniranje vrlo moćne grafičke kartice sa skromnim procesorom : GPU bi mogao isporučiti puno više FPS-a, ali CPU nije sposoban dovoljno brzo generirati logiku igre, fiziku, umjetnu inteligenciju itd. Vrijedi i obrnuto: snažan CPU s osnovnim GPU-om ili sporim RAM-om uzrokuje da se procesor "dosađuje" jer ne prima podatke brzinom kojom bi mogao podnijeti.
U poslovnom softveru, uska grla mogu nastati zbog loše optimiziranih upita Entity Frameworka (EF) , teških izračuna koji se izvode u masivnim petljama, BizTalk usluga koje prekomjerno pišu u baze podataka ili noćnih batch procesa koji ostavljaju planinu nedovršenog posla. Čak i s moćnim hardverom, ako je arhitektura ili kod loše dizajniran, sustav će i dalje stagnirati.
Uobičajena je zabluda da je usko grlo uvijek ozbiljan problem . To nije nužno slučaj. U svakom stvarnom sustavu uvijek će postojati nešto što postavlja ograničenje. Važno je utvrditi je li to ograničenje prihvatljivo za vaš slučaj upotrebe (na primjer, stabilan i dovoljan FPS ili odgovarajuće vrijeme odziva) i, ako nije, utvrditi gdje se nalazi i što možete učiniti u vezi s tim.
Zašto nije dovoljno samo gledati postotke iskorištenosti CPU-a ili GPU-a
Mnogi ljudi pokušavaju otkriti uska grla jednostavnim gledanjem korištenja CPU-a i GPU-a u monitoru performansi . Ako vide grafičku karticu na 100%, a CPU na 50%, zaključuju da "grafička kartica stvara usko grlo" ili da postoji problem; ako je obrnuto, pretpostavljaju da je CPU krivac. Ovo pojednostavljeno tumačenje često dovodi do netočnih dijagnoza.
Stvarnost je takva da je, ovisno o opterećenju, sasvim normalno da jedna komponenta bude na 100%, dok druga nije . U zahtjevnoj igri na visokim rezolucijama, GPU može raditi punim kapacitetom dok CPU ima puno resursa. U igri koja je loše optimizirana za paralelizam, CPU može raditi vrlo visoko na jednoj ili dvije jezgre čak i ako GPU nije potpuno zasićen, a to ne mora nužno ukazivati na problem s konfiguracijom.
Ono što je zaista važno jest promatrati simptome abnormalnog ponašanja : nagli pad FPS-a bez vidljivog razloga, nestabilna brzina sličica u sekundi, zastajkivanje ili mikrozastajkivanje u određenim scenama, kratkotrajno zamrzavanje pri učitavanju novih područja, spori odgovori API-ja ili redovi poruka koji kontinuirano rastu. To su znakovi koji vam govore da nešto nedostaje ili da se nekim resursom loše upravlja.
Također je važno shvatiti da ne postoji savršena ravnoteža . Oni "kalkulatori uskih grla" koje pronađete na internetu mogu vam dati okvirnu ideju, ali temelje se na vrlo generičkim prosjekima i često zanemaruju ključne čimbenike poput razlučivosti igre, vrste opterećenja, arhitekture grafičkog motora ili načina na koji vaša aplikacija obrađuje podatke. Vaše stvarne metrike su one koje prikuplja vaš vlastiti sustav pod vašim specifičnim uvjetima korištenja.
Hardverske komponente koje često uzrokuju uska grla
Na računalu postoji nekoliko uobičajenih krivaca. Identificiranje onog koji je dominantan u svakom scenariju ključno je za izbjegavanje trošenja novca na nepotrebne nadogradnje i za točno dijagnosticiranje problema.
CPU: To je mozak stroja; pokreće programe, upravlja logikom igre, koordinira GPU, premješta podatke iz RAM-a, komprimira, šifrira, kompajlira… Ako je CPU star, spor ili jednostavno na granici svojih mogućnosti, primijetit ćete nespretne izbornike, beskrajna vremena kompajliranja, FPS koji se ne povećava čak ni kada smanjite rezoluciju ili zasićenost u igrama s mnogo NPC-ova ili složenom fizikom.
RAM: Glavna memorija drži podatke i instrukcije koje su CPU-u potrebne lako dostupnima. S nedovoljnim kapacitetom ili vrlo sporim modulima, CPU počinje čekati dolazak podataka , datoteke stranica se intenzivnije koriste, a dolazi do zastoja prilikom promjene scena, promjene aplikacija ili otvaranja velikih projekata. U modernim igrama, 16 GB je razuman minimum, a i propusnost i latencija su važni, posebno s Ryzen procesorima.
GPU i VRAM: Grafička kartica brine se za renderiranje i mnoge vizualne efekte; ako je preslaba, iskorištenost GPU-a stalno će dosezati 99-100% , a FPS neće biti onakav kakav očekujete za željenu rezoluciju i kvalitetu grafike. Količina VRAM-a ključna je pri visokim rezolucijama ili s puno tekstura: ako je nedovoljna, teksture će se učitavati kasno (pojavljivati) ili će se kvaliteta automatski smanjiti.
Pohrana: Mnogi ga podcjenjuju, ali mehanički tvrdi disk može biti prava glavobolja . Sporo vrijeme pokretanja sustava, igre koje se otvaraju cijelu vječnost, razine koje se sporo učitavaju ili otvoreni svjetovi u kojima disk stalno čita teksture, sve su to simptomi diska koji nije dorastao zadatku. SATA SSD uvelike poboljšava iskustvo, a brzi NVMe disk gotovo je neophodan ako imate vrlo zahtjevne naslove ili ogromna učitavanja podataka.
Mreža i upravljački programi: U mrežnim okruženjima, spora ili nestabilna veza dovodi do velike latencije i slabih brzina prijenosa; pregled vaše LAN topologije pomaže u prepoznavanju uskih grla u mreži. Osim toga, zastarjeli ili loše optimizirani upravljački programi mogu značajno smanjiti performanse, posebno upravljački programi za GPU. Ponekad jednostavno ažuriranje firmvera ili upravljačkog programa pruža potpuno besplatno poboljšanje performansi.
Matična ploča, iako važna za stvari poput broja memorijskih kanala ili podrške za određene tehnologije, rijetko je izravni uzrok uskog grla sve dok ste odabrali model koji je u skladu s vašim CPU-om i vašim potrebama.
Uska grla u velikim aplikacijama bez testiranja jedinica
Što se tiče poslovnog softvera, mnoge se organizacije suočavaju s masovnim aplikacijama koje su rasle bez strategije testiranja : bez jediničnih testova, bez integracijskih testova i bez jasno definiranih scenarija performansi. Kada je sustav već gigantski, prepisivanje od nule ne dolazi u obzir, ali performanse počinju alarmantno opadati.
U tim slučajevima važno je točno odrediti, bez prepisivanja aplikacije, gdje proces zapravo zapinje . Često otkrivamo pretjerano zahtjevne EF upite koji su trebali biti pretvoreni u optimizirane SQL prikaze, algoritme koji se mogu riješiti u milisekundama, ali troše apsurdne količine CPU-a i memorije ili batch procese koji akumuliraju posao dok ne zasite redove čekanja i baze podataka.
Otkrivanje uskih grla ovdje uključuje kombiniranje praćenja brojača performansi (korištenje CPU-a, memorija, I/O diska, mreža, redovi poruka, vrijeme odziva) s alatima za profiliranje poput Visual Studio Profilera ili ANTS Performance Profilera. Ovi alati omogućuju vam da identificirate koja klasa, metoda ili upit troši najviše vremena CPU-a ili memorije.
Ključno je razumjeti da profiliranje iskrivljuje metrike performansi jer dodaje vlastito opterećenje. Stoga ove brojke nisu korisne kao globalno mjerenje, već samo za izoliranje i sužavanje problematičnih dijelova koda. Prvo identificirate vruću točku pomoću profilera, zatim uklanjate profiler i ponavljate "čiste" testove opterećenja kako biste potvrdili poboljšanje.
Iterativni pristup istraživanju i rješavanju uskih grla
Koliko god primamljivo bilo "popraviti sve", najučinkovitiji način za pronalaženje i ublažavanje uskih grla jest slijediti iterativni i strukturirani pristup . Mijenjate parametar, ponavljate isti test, mjerite rezultate. I tek tada prelazite na sljedeću moguću promjenu.
To se odnosi i na hardverske postavke (frekvencije, broj jezgri, memoriju, vrstu diska) i na softverske postavke (konfiguracijske parametre, veličine serija, konkurentnost niti, EF opcije, indekse baze podataka itd.). Ako prilagodite dvije ili tri stvari odjednom, izgubit ćete trag koje su postavke zapravo imale utjecaj, a koje su uvele negativnu nuspojavu.
Zamislite da istovremeno mijenjate i parametar veličine serije i ograničenje konkurentnosti : jedno bi moglo poboljšati performanse, ali drugo bi ih moglo pogoršati, i mogli biste završiti s neutralnim rezultatom. Ovo je pogrešan zaključak: mislit ćete da nijedna promjena nije korisna, dok je u stvarnosti jedna bila korisna. Stoga je razuman pristup izolirati promjene, ponoviti potpuno isti testni scenarij i zabilježiti rezultate.
Drugi ključni aspekt je da uklanjanje jednog uskog grla može stvoriti novo . Na primjer, nadogradite bazu podataka i odjednom se usko grlo prebacuje na kapacitet diska ili nadogradite CPU i sada mreža nije dovoljna. Proces je inkrementalan i nikada "konačan", posebno u sustavima koji se s vremenom razvijaju.
Nadalje, testiranje se mora provoditi dovoljno dugo da bi sustav dosegao stabilno stanje: predmemorije se pune, tablice baze podataka se prilagođavaju, protok poruka se regulira, nedovršeni poslovi se brišu... Tek tada ćete vidjeti stvarne održive performanse, a ne zavaravajući početni skok.
Kako osigurati dosljednost u testiranju performansi
Da bi mjerenja bila smislena, bitno je održavati dosljedne uvjete ispitivanja . Ako svaki put mijenjate okruženje ili opterećenje, bit će nemoguće usporediti rezultate i izvući jasne zaključke.
Prvo, pokušajte osigurati da je hardver što stabilniji i reprezentativniji za produkcijsko okruženje. Testiranje sustava za integraciju s velikim poduzećem na skromnom prijenosnom računalu, na primjer, dat će vam vrlo netočne rezultate. Idealno bi bilo koristiti strojeve ekvivalentne onima u produkciji ili barem okruženje koje se pridržava iste osnovne topologije.
Drugo, postavite minimalno trajanje za svaki test i vrstu opterećenja: broj istovremenih korisnika, veličinu poruke, složenost mape, vrste izvršenih upita itd. Ako jedan dan testirate s malim dokumentima, a sljedeći s ogromnim, razlike koje vidite mogu biti posljedica samo te varijacije, a ne promjene vaše konfiguracije.
Također je ključno započeti svaki test iz razumno čistog stanja . U okruženjima poput BizTalka, na primjer, postoje postupci čišćenja baze podataka poruka kako bi se sustav vratio u gotovo novo stanje između testiranja. To sprječava nakupljanje povijesnih podataka i iskrivljavanje rezultata, nešto što se može dogoditi i s punim predmemorijama, zaglavljenim vezama ili neispravnim nitima.
Konačno, svi testovi usmjereni na pronalaženje maksimalnih održivih performansi (MST) moraju se provoditi u okruženju s aktivnim uslugama praćenja, antivirusnim programima i drugim korporativnim agentima, baš kao što će biti i u produkciji. U suprotnom, mjerit ćete idealan svijet koji neće odražavati svakodnevnu stvarnost.
Performanse naspram latencije: realna očekivanja
Često se zanemaruje činjenica da performanse i latencija djeluju u suprotnim smjerovima . Povećanje performansi (više obrađenih poruka, više zahtjeva u sekundi, više FPS-a) obično znači veće opterećenje CPU-a, memorije, diska, mreže i zaključavanja dijeljenih resursa, što zauzvrat može povećati latenciju pojedinačnih operacija.
U dobro podešenom sustavu, razuman cilj je težiti dobrim performansama s prihvatljivom latencijom , a ne maksimizirati oboje istovremeno, jer je ta kombinacija fizički nemoguća na gotovo svakoj platformi u stvarnom svijetu. Kako se opterećenje povećava, neizbježno se javljaju sukobi, redovi čekanja i vremena čekanja.
Tipičan primjer: U BizTalku ili drugim integracijskim programima, dovršene instance se akumuliraju u bazi podataka i ne brišu se dovoljno brzo. Vremenom to usporava upite i operacije na MessageBoxu, stvara uska grla i smanjuje ukupne performanse. Može doći do točke u kojoj se, bez da se sustavu da vremena za "disanje" i čišćenje, nikada neće u potpunosti oporaviti od vršnog opterećenja prije nego što dođe sljedeće.
Kako bi se razumjela ograničenja platforme, korisno je izmjeriti njezinu sposobnost oporavka od vršnih opterećenja . Analiza njezinog ponašanja tijekom i nakon velikih noćnih serija, na primjer, pomaže u pravilnom dimenzioniranju hardvera, veličine međuspremnika i prostora u redu čekanja potrebnog za scenarije preopterećenja.
U ovom kontekstu, brojači performansi su vaši najbolji prijatelji: korištenje CPU-a, vrijeme diska, duljina reda čekanja, poruke čekanja, prosječno i maksimalno vrijeme odziva... sve to prikazuje obrazac korištenja koji vam omogućuje da prepoznate koji dio sustava zaostaje i kada.
Praktično otkrivanje uskih grla u računalu bez sintetičkih mjerila
Ako se usredotočimo na računalo (na primjer, igranje ili intenzivan rad) i želimo izbjeći sintetičke benchmarkove, možemo koristiti alate za praćenje u stvarnom vremenu i same igre ili aplikacije kao prave "testne klupe".
Osnovni alati poput Windows Task Managera omogućuju vam pregled CPU-a, GPU-a (na kompatibilnim karticama), RAM-a i korištenja diska. Za detaljniju dijagnostiku, uslužni programi poput MSI Afterburnera, HWiNFO64 ili sličnih programa, zajedno s lokalnom telemetrijskom nadzornom pločom, omogućuju vam prikazivanje podataka o korištenju, temperaturama i frekvencijama na zaslonu dok igrate igre ili radite.
Ideja je jednostavna: pokrenite zahtjevnu igru ili aplikaciju koja intenzivno koristi resurse, aktivirajte sloj i promatrajte kako se komponente ponašaju. Ako je GPU gotovo uvijek na 99-100% iskorištenosti, a CPU se kreće oko umjerenih vrijednosti, usko grlo je obično povezano s grafikom; ako je CPU zaglavljen na 80-100% iskorištenosti, a GPU radi puno slabije, ograničenje je obično procesor.
Za RAM, obratite pozornost na to je li sva dostupna memorija popunjena i je li tvrdi disk počeo intenzivno raditi (datoteka stranice). Uzrok bi mogao biti kašnjenje pri prebacivanju zona, kartica ili prozora. Na kraju, provjerite tvrde diskove: ako su na 90-100% iskorištenosti tijekom učitavanja igara, instalacija ili stalnih operacija čitanja/pisanja, imate potencijalno usko grlo u pohrani.
Sve ovo možete učiniti bez pokretanja ijednog sintetičkog benchmarka, jednostavnim korištenjem svojih svakodnevnih programa kao testne platforme. To je puno reprezentativnije za iskustvo iz stvarnog svijeta od bilo kojeg 3DMark ili Cinebench rezultata, koliko god oni bili korisni kao referenca.
Čitanje i tumačenje simptoma u igrama i drugim opterećenjima
U okruženju za igranje, najčešći simptom je pad FPS-a, ali postoje i druge nijanse. Sustav koji je uistinu ograničen na CPU često će pokazivati značajno zastajkivanje u scenama s mnogo likova , intenzivnom fizikom ili složenom umjetnom inteligencijom, čak i ako smanjite rezoluciju. Korištenje CPU-a vrtoglavo raste, a GPU ostaje čekati podatke.
Ako je problem u GPU-u, FPS će obično biti nizak, ali stabilan , a smanjenje kvalitete grafike ili rezolucije imat će vrlo jasan utjecaj na glatkoću. GPU će stalno raditi na svom maksimalnom kapacitetu, a CPU se neće činiti toliko opterećenim. Ovo je naj"prihvatljivije" usko grlo u igraćem računalu, jer znači da gurate grafičku karticu do njezinih granica.
Problemi s RAM-om lako se otkrivaju kratkim zamrzavanjem, odgođenim učitavanjem tekstura, usporavanjem pri pritisku tipke Alt-Tab ili istovremenom otvaranju više aplikacija. Na sustavima s 8 GB RAM-a, na primjer, otvaranje AAA igre, preglednika s mnogo kartica i alata za streaming može biti recept za zastoje.
Kod problema s pohranom, najvidljiviji simptomi su izuzetno dugo vrijeme učitavanja i iskakanje tekstura ili scena. U igrama otvorenog svijeta koje stalno čitaju podatke s diska, spori tvrdi disk može uzrokovati pad FPS-a u prometnim područjima jednostavno zato što protok podataka ne stiže do RAM-a i GPU-a na vrijeme.
Izvan igara, znakovi se mijenjaju, ali logika je ista: API koji reagira sve sporije i sporije kako se opterećenje povećava, sustav čekanja čiji se broj poruka na čekanju nikada ne smanjuje, procesi koji se akumuliraju u bazi podataka ili korištenje CPU-a i diska na 100% satima bez uspjevanja obrisati nedovršene zadatke.
Optimizirajte prije nadogradnje: softver, konfiguracija i skaliranje
Prije nego što se požurite kupiti novi hardver, vrijedi istražiti mogućnosti optimizacije i konfiguracije softvera . Često možete postići značajnu učinkovitost finim podešavanjem onoga što već imate.
Na računalima to uključuje ažuriranje upravljačkih programa (posebno upravljačkih programa za GPU i čipset), omogućavanje XMP/DOCP profila u RAM-u, konfiguriranje plana napajanja na način rada visokih performansi i zatvaranje pozadinskih aplikacija koje se čine kao da troše resurse (učitani preglednici, alati za snimanje, procesi sinkronizacije itd.). Male promjene mogu osloboditi CPU, RAM i prostor na disku bez trošenja ijedne lipe.
U igrama je korisno prepoznati koje su postavke više vezane za CPU, a koje za GPU . Parametri poput udaljenosti crtanja, gustoće naseljenosti, fizike i složenosti simulacije obično opterećuju CPU; rezolucija, kvaliteta tekstura, sjene i anti-aliasing opterećuju GPU. Prilagođavanje ovih postavki omogućuje vam bolje uravnoteženje opterećenja prema vašem hardveru.
U poslovnim sustavima postoji mnogo prostora za konfiguraciju: promjena veličine paketa poruka, podešavanje parametara konkurentnosti, optimizacija indeksa baze podataka, pregled vremenskih ograničenja, onemogućavanje prekomjernih zapisnika ili dijagnosticiranje prilagođenih komponenti s prekomjernom upotrebom CPU-a.
Nakon što je sve to fino podešeno, vrijeme je razmisliti o vertikalnom ili horizontalnom skaliranju . Vertikalno skaliranje znači nadogradnju stroja: više CPU-a, više memorije, bolje diskove itd. To je korisno kada postoji očito usko grlo u određenom resursu, a dodavanje većeg kapaciteta jednoj instanci pomaže u bržoj obradi zahtjevnih zadataka (na primjer, transformacije velikih poruka).
Horizontalno skaliranje uključuje dodavanje više čvorova i raspodjelu opterećenja . To ima smisla kada je jedan poslužitelj preopterećen CPU-om, memorijom ili I/O-om, a aplikacija je dizajnirana za paralelni rad. Manje očita strana je da na platformama poput BizTalka dodavanje čvorova može povećati sukob u središnjoj bazi podataka poruka, pa je i ovaj aspekt potrebno pratiti.
Prilikom odlučivanja što učiniti, razmislite o trenutnom uskom grlu i kako će se sustav promijeniti kada ga uklonite: ponekad želite ubrzati pojedinačne zadatke (vertikalno skaliranje), a ponekad jednostavno želite rasporediti volumen na više strojeva (horizontalno skaliranje) kako biste povećali maksimalnu održivu propusnost bez vršnih latencija.
U konačnici, otkrivanje uskih grla bez pribjegavanja sintetičkim mjerilima uključuje promatranje sustava u akciji, točno tumačenje signala i izvršavanje samo potrebnih prilagodbi u svakoj iteraciji. Bilo da se radi o igraćem računalu, masovnoj aplikaciji bez testiranja jedinica ili okruženju za integraciju poduzeća, ključ ostaje isti: stvarni podaci, metodologija, strpljenje i informirane odluke o ulaganju vremena i novca samo tamo gdje je to zaista potrebno.
