Omegapoint

2009-08-11

DTrace och Java

Efter flådig middag (snittar! man kan aldrig få för många snittar!) och rafflande lotteridragning — Peter vann en fin klocka från den schweiziska armén (och om det är några som kan hålla tiden så är det den schweiziska armén!) och jag slapp vinna en otroligt ful Sun-läderjacka (prisa gud!) — så gick vi på en kvällsdragning om Solaris DTrace och Java. Tyvärr var det väldigt lite folk där och det var synd för det var en mycket bra presentation och demo av DTrace idag och hur man antagligen kommer kunna debugga Java 7-program sedan.

Jag har kört Solaris 10 och OpenSolaris privat ett längre tag (och de senaste månaderna även på Omegapoint) och är mycket imponerad av många av nyheterna. ZFS revolutionerar ens syn på filsystemet, Zones (lättviktsvirtualisering — bara solaris som gästoperativsystem) och xVm (xen-virtualisering) verkar lovande som virtualiseringstekniker och så då DTrace.

Lite kortfattat är DTrace ett ramverk för att undersöka vad operativsystemet och datorn håller på med. I kärnan till Solaris finns numera över 60 000 mätpunkter ("probes") inbyggda. Dessa kan slås av och på med hjälp av ett enkelt skriptspråk, D. Ett en-rads D-skript skulle kunna t ex vara "Räkna vilken process som just nu gör flest systemanrop" eller "Visa processer med många öppna filer". Jämfört med att använda verktyg som truss har dessa mätpunkter i princip ingen påverkan för prestandan hos systemet och eftersom D-skripten exekveras i en sandbox kan man utan oro köra dessa på produktionssystem under drift.

Med andra ord: DTrace kan vara stor hjälp med att svara på den svåra frågan: "Varför fungerar inte systemet bra när vi kör i riktig produktion under hårt tryck?" Glädjande för alla oss som desperat försökt titta på stacktrace-dumpar eller, ännu värre, försökt koppla på JProfiler på en jvm i produktion ...

DTrace är licenserat under Suns CDDL-licens som inte är kompatibel med GPL därav ingen enkel portning till Linux. Dock finns det i både FreeBSD och MacOS X Leopard.

Presentationen hölls av Sun-ingenjörerna Phil Hartman och Jon Haslam. De var mycket underhållande och duktiga. Många intressanta DTrace-exempel skrivna live uppblandade med lustiga anekdoter från ett ingenjörsliv i serverhallen. (En personlig favorit var att Hartman drog det här skämtet: Heisenberg is pulled over for speeding: 'Do you know how fast you were going?' the police officer asks, incredulously. 'No,' replies Heisenberg, 'but I know exactly where I am!' — jag var också den enda som skrattade rakt ut i hela publiken ... )

Detta skulle också visa sig vara problemet med presentationen: publiken. Förutom Peter och jag var det kanske tio stycken andra där. De verkade mest ha virrat in i salen, dåsiga och snurriga från alla snittarna och vinet (antar jag), utan att ha något större intresse av presentationen i sig. Frågorna blev många och stundtals mycket plågsamma att bevittna. Speciellt jobbiga var de som inte hade en susning om vad DTrace är för något samtidigt som de krävde att få svar på exakt hur det skulle lösa det specifika problem de just nu hade med datorer. Tråkigt på en annars så väl utförd presentation.

Jag tog chansen och frågade lite om det jag tycker det stora problemet med DTrace är: man måste kunna något om datormaskiner. Eller som jag formulerade det: "I'm a Java developer so I don't know anything about computers ... " Därför blir det ganska svårt att ställa frågor till operativsystemet om vilka systemanrop som utförs. Hur ska jag veta vart jag ska börja leta liksom? Phil skrattade lite nervöst och försökte besvara frågan med att det egentligen inte är så komplicerat och att det är några få handgrepp man behöver lära sig för att förstå ungefär vart man ska börja.

Mätpunkterna som DTrace tittar på finns inte bara i själva operativsystemet. Andra program som Apache (hela AMP-stacken), MySQL, Firefox m fl har också försetts med probes. Phil och Jon gick sedan igenom grunderna för vad man behöver göra i C-kod för att skapa egna mätpunkter (gäsp!).

Ok, men Java då?

För J2SE 5.0 är DTrace ganska begränsat. Man kan titta på stack traces och om man startar om jvm:en med vm-agenten dvm, så finns ett antal probes att tillgå (gc start och finish t ex). Att behöva starta om jvm:en blir i sig rätt dumt eftersom en stor del med hela poängen var ju att DTrace skulle kunna alltid vara närvarande och kunna användas i exempelvis ett produktionssystem. Detta är för att de även de icke-påslagna mätpunkterna har en märkbar prestandapåverkan.

Situationen i Java SE 6 är mycket mer intressant. De flesta DTrace-mätpunkerna är första klassens medborgare i Java (när man kör i ett Solaris 10-system) och finns med i jvm:en utan att man behöver göra något. Detta gäller för i princip alla mätpunkter, men inte riktigt alla. De java-mätpunkter som handlar om sånt som är svårt att hålla koll på på grund av just-in-time-kompileringen, t ex in- och utgång i en java-metod, de måste slås på med en flagga till jvm:en.

De mätpunkter som finns i jvm:en inkluderar när en klass laddas eller tas bort, när skräpinsamlingen börjar eller slutar, in- eller utgång ur en metod och när en tråd startar eller stannar. Alla dessa mätpunkter kan användas för att med små, enkla D-skript berätta vad ett java-program håller på med.

Betyg: 4

Presentationen avslutades med att visa vad som händer med DTrace i Java 7. När JDK 7 släpps kommer man med stor säkerhet kunna sätta ut egna mätpunker i java-koden (med hjälp av markera t ex en metod med en annotation). Ungefär lite som hur folk använder JMX i dagsläget alltså.

1 kommentar:

John Wilander sa...

Låter mycket intressant. Särskilt med egna mätpunkter.

Gällande Heisenberg: Hur kunde polisen veta var han var?

Skicka en kommentar

Om Omegapoint

Omegapoint AB är ledande rådgivare och experter inom Systemarkitektur, Säkerhet och IT-ledning.

Twitter uppdateringar

Omegapoints kvitterström:

    Andra Omegapointbloggar