Buvo akivaizdu, kad yra problema ir atrodė, kad diske buvo daug veiklos, bet ką ta veikla pasiekė? Stebėdamas su dtrace sužinojau, kad Apple Mail per vieną failą suaktyvino labai daug veiklos: pasirodo, kad Paštas naudoja atvirojo kodo SQL duomenų bazės modulį, vadinamą SQLite, kad galėtų sekti savo pašto pranešimus, o manasis buvo žymiai mažesnis nei optimalus. Greitai patikrinus „Google“, kad gautumėte daugiau informacijos apie šį failą, gauta komanda jį optimizuoti ir dar kartą galėjau perskaityti savo el. laiškus – uraa!
Antrasis mano pavyzdys susijęs su daug didesne problema. Mano įmonė valdo svetainių rinkinį iš dviejų prieglobos centrų, kurie yra sujungti 100 Mb/sek ryšiu. Prieglobos centre yra subalansuota apkrova žiniatinklio serverių ferma, kuri palaiko ryšį su galinio duomenų bazės serveriu, tai keturių lizdų „Opteron Sun“ su daug atminties ir dviejų valdiklių EMC pluošto kanalo RAID masyvas. Šie serveriai veikia „MySQL“ ir yra dubliuojami, todėl viename centre esantis naujinimas nukopijuojamas į kitą centrą ir ten taip pat veikia.
Prieš kelias savaites vienos iš šių sistemų našumas įprastai pradėjo kristi nuo uolos, o tinklalapiai, kurių kūrimas paprastai užtruktų dešimtąsias sekundžių, užtruktų kelias sekundes. Visi priekiniai žiniatinklio serveriai buvo puikūs, vos liejo prakaitą, o galinės duomenų bazės taip pat atrodė gerai. Akivaizdūs įrankiai, tokie kaip „top“, nesuteikė jokios naudingos informacijos ir pagerino „MySQL“ našumą kintamieji nedavė jokių esminių patobulinimų, ypač dėl to, kad problemos atkūrimas buvo labai didelis sunku. Turėjo būti kita priežastis. Labiausiai įtaigus problemos aspektas buvo tai, kad ji paveikė tik vieną prieglobos centrą, todėl viename centre kažkas vyko, o kitame ne. Tiesa, skirtingose svetainėse pritrūko skirtingų centrų, tačiau visos duomenų bazės rašymo operacijos buvo pasikartojančios.
Ironiška, bet pirmoji užuomina kilo iš nuolankaus „iostato“, kurį kritikavau anksčiau. Tai man parodė, kad vienas konkretus įrenginys buvo labai užimtas – iki 90 % apkrova – ir kad vidutinis laukimo laikas buvo ilgesnis nei norėčiau. Buvo tikras netikėtumas, kad išnaudojome visą 2 Gb/sek skaidulų kanalo ir RAID pralaidumą. Be dtrace dabar būtume buvę beveik vieni, tik spėliodami. Mums reikėjo subalansuoti įvesties / išvesties apkrovą tarp RAID bloko valdiklių, bet kaip mes tai padarėme? Ir ar tikrai galime būti tikri, kas tai sukėlė?
Čia dtrace iš tikrųjų atsirado. Pirmas dalykas, kurį bandžiau naudoti „rfileio“ iš „dtrace“ įrankių rinkinio, kad išsiaiškinčiau tikrai užimtų failų tapatybę. pasakė, kad tam tikro tipo lentelės duomenų bazėse nukentėjo labai dažnai, bet koks srautas buvo paveiktas? Įvedęs scenarijų iš „MySQL dtrace“ įrankių rinkinio (galima rasti adresu www.pcpro.co.uk/links/163open), leiskite stebėti konkretų skambutį MySQL duomenų bazėje serveryje (naudodamas aukščiau minėtą proceso teikėją) ir todėl man pasakė, kokias SQL užklausas vykdo duomenų bazė – ir joje buvo vykdoma daug juos. Netrukus atsirado modelis, pagal kurį mačiau, kad buvo konkretus atvejis, kai buvo vykdomos dvi užklausos, kurios būtų atliktos viena, ir tai taip pat atskleidė logikos problemą.
Dėl šių dviejų užklausų, kurias galima pakeisti viena, kūrėjas nekaltas. Atsitiko tai, kad buvo pateikta užklausa gauti vieną stulpelį iš lentelės, o tada – labai greitai – kitą stulpelį iš tos pačios lentelės. Mačiau, kad abi šios užklausos vykdomos viena šalia kitos, todėl galėjau jas sujungti. Tai metodas, panašus į akutės optimizavimą kompiliatoriuose, kur galima pašalinti perteklinius teiginius. Atlikdamas šį darbą, galėjau visiškai pakeisti momentinį programos našumą (kaip ji veikia įprastai), be našumo esant didelei apkrovai. Viena konkreti operacija, kuri įprastai užtrukdavo ilgiau nei sekundę, dabar nuolat atliekama mažiau nei 0,4 sekundės arba maždaug tris kartus greičiau. Tai taip pat parodė kai kuriuos programos trūkumus, kurie leis man ją patobulinti.
