Erindringer: Wait-interfacet

Wait-interfacet

Jeg tror, jeg tidligere har fortalt, at jeg var så heldig at komme på et såkaldt internals-kursus hos Oracle, mens jeg arbejdede der. Kurset blev afholdt i Colorado Springs i et kursuscenter, som Oracle havde dér. Jeg var derovre i alt fire gange for at tage de fire moduler. Kurset var lavet specielt til folk i supportorganisationen, så de kunne lære, hvordan Oracles kildekode så ud og få indsigt i avancerede metoder til fejlfinding.

På nærmest en bagtanke nævnte en af underviserne – en gut ved navn Lawrence Toe – at han var faldet over nogle statistikker i nogle interne tabeller i databasen, som så ud til at vise, hvad en bruger, en rapport eller en proces havde ventet på undervejs, mens den kørte. Det vil sige, at systemet kunne registrere, om der på et tidspunkt blev ventet på en lås, senere måske på adgang til hukommelse, og andre gange på data fra disken.

Jeg prøvede det, da Michael Thomsen – IT-chef på Færøske Tele – havde et mystisk problem: Alt blev langsommere, efter at han havde installeret en ekstra og kraftig CPU i sin maskine. Jeg begyndte at skrive om det her på en intern mailingliste i Oracle – en stor mailingliste med måske 5-6.000 deltagere. En amerikaner, Kyle Haley, der arbejdede i Oracle i Frankrig, kontaktede mig, fordi han også havde arbejdet med de her wait statistics. Det gik op for mig, at kun en håndfuld mennesker i hele Oracle faktisk brugte det her.

Samtidig underviste jeg i den daværende metode for performance tuning, hvor man gennemgik en lang tjekliste og justerede på alt muligt ud fra tommelfingerregler. Senere kaldte jeg det gæt og grimasser-metoden, eller på engelsk gas and grimacing. Jeg begyndte så at holde kurser i wait-interface-analyse, fordi jeg kunne se, at det gav mulighed for at identificere præcis, hvor tiden blev brugt, når f.eks. en rapport blev kørt.

Det betød, at man kunne finde ud af, om tiden gik med CPU-arbejde eller ventetid – og handle på det. Det nytter jo ikke noget at installere en hurtigere CPU, hvis ventetiden samtidig bliver fordoblet – hvilket netop var tilfældet hos Færøske Tele.

Med wait-interfacet kunne man se det klart, hvorimod det med de traditionelle metoder krævede held og erfaring at udlede noget af forholdstal og statistikker. Det begyndte at gå op for folk, efterhånden som jeg turnerede rundt, holdt foredrag og skrev artikler, at den hidtidige metode ikke var en valid, videnskabelig fremgangsmåde.

Jeg insisterede dengang på, at hvis to eksperter fik de samme data, skulle de helst nå frem til samme, verificerbare konklusion. Hvis ikke – ja, så var det gæt og grimasser. På kurserne i Colorado lærte vi også metoden DDR – Detect, Diagnose, Repair – som en struktureret tilgang til fejlfinding.

Jeg har selv undervist i denne metode på 4-5 dages kurser rundt om i verden. Det var en befrielse at finde en metode, hvor man på få sekunder eller minutter kunne finde ud af, hvad der gjorde noget langsomt – fremfor at bruge uger hos kunden.

Men det vakte modstand. Konsulenter og firmaer, som levede af at lave dyre analyser over lang tid, følte sig truet. Med wait-interfacet kunne kunderne i mange tilfælde selv finde fejlen – og konsulenter kunne løse problemer på få timer i stedet for uger.

Det minder faktisk lidt om i dag, hvor AI truer fagfolk med lange uddannelser – fordi almindelige mennesker nu selv kan lave meget af det, som før krævede specialister.

En af dem, der skrev om wait interfacet, var Virak Saxena fra Special Performance Group i USA – som i dag ejer et whiskydestilleri. Jeg mistænker, at han stjal noget af mit og Anjo Kolks arbejde. Men SPG tog aldrig metoden til sig. De blev ved med gæt og grimasser, selv da jeg holdt foredrag for dem. Det var jo deres levebrød.

Senere, da vi startede Miracle, bragte Annette – som jeg senere blev gift med – os også lidt ind i Microsoft-verdenen. Vi brugte naturligvis wait-interface-metoden, som vi havde lært og brugt i Oracle Premium Services. Hun introducerede mig for Mark Souza, der ledede Microsofts svar på Oracles performance-team.

Mark og jeg talte sammen over årene, og jeg foreslog, at de indførte wait interface i SQL Server, for der brugte man stadig gæt og grimasser. Det lykkedes at få tre af mine folk – Johannes, Raoul, Elis og muligvis Peter Gramm – over til Microsofts hovedkvarter i Redmond. De talte med seks af arkitekterne bag SQL Server. Og i 2012 blev noget, der lignede wait interface, indført. Det blev dog aldrig rigtig udbredt. I dag, hvor alt kører i skyen, er det måske heller ikke så vigtigt længere.

Men det har haft stor betydning for mig – både professionelt og personligt. Blandt andet havde James Morle og jeg et møde i København med folkene bag MySQL, for at overtale dem til at implementere et wait interface. De sagde nej – de frygtede performance-overhead, hvilket er forkert. Jeg har også forsøgt at overbevise andre om at indbygge den slags diagnoseværktøjer i software, f.eks. operativsystemer.

Der, hvor man ikke registrerer, hvad tiden bruges på, er man tvunget til at gætte. Heldigvis begyndte folk hos Sun Microsystems at lave værktøjer i SunOS, der kunne måle dette – og det spredte sig.

Men morsomt nok, så har de gamle IBM-mainframes altid haft det. IBM vidste, at hvis man skulle kunne drifte kritiske systemer, skulle man have instrumentering i alle lag – styresystem, database og så videre. Og det byggede de ind allerede i 60’erne eller 70’erne. Det er derfor, mainframe-folk i dag ryster på hovedet ad nyere systemer.

Hvis en rapport kører langsommere på en mainframe, kan man se i loggen, hvad der forårsagede det. Systemet gemmer alt i et repository og har værktøjer til at analysere det i detaljer. Den slags findes stadig ikke bredt uden for mainframe-verdenen.

---

Wait-interfacets oprindelse i Oracle

Nogle år efter, at jeg havde opdaget wait interfacet, tog jeg kontakt til Juan Loaiza, chef for databaseudvikling i Oracle. Han har altid været venlig og imødekommende. På det tidspunkt var der et kapløb blandt databaseproducenterne – hvem kunne vise, at deres nye version var den hurtigste?

Oracle skulle lancere version 7.0, som var radikalt anderledes end version 6. Men uanset hvad udviklerne gjorde, kunne de ikke få den til at performe godt. Den kørte, som englænderne siger, like a three-legged yellow dog.

I desperation bad Juan en nyansat inder om at lægge målepunkter ind i kildekoden – hvilket egentlig ikke var tilladt, da koden officielt var låst. De indsatte fire målepunkter og lavede en intern memory-tabel til at måle, hvor meget og hvor længe der blev ventet.

De kompilerede koden om i en weekend og kørte benchmarken. Nu viste den præcis, hvor flaskehalsen var – en latch på en memory-struktur. Det kunne de så justere med parametre. Nu kørte databasen hurtigere end konkurrenternes.

Det var et hemmeligt projekt – et stealth project – og derfor blev wait interfacet ikke kommunikeret ud bredt. Men uden den ændring var version 7 aldrig blevet klar. Det var altså i al hemmelighed, at wait interfacet blev født.

Juan og hans team brugte to uger uden at finde problemet. Da selv de dygtigste fejlede, viser det tydeligt, at gæt og grimasser og mavefornemmelser ikke slår reel data og måling.

Juan har senere sagt – og flere har bakket op – at det nok var mig, der navngav det wait interface. Jeg har en vag erindring om at have hørt udtrykket første gang på kurset i Colorado Springs, hvor Lawrence Toe kort nævnte den interne tabel, som den unge inder havde lavet.

Det var noget af historien om wait interfacet.