En Java proces har et lineart stigende hukommelsens forbrug. En uheldig arkitektur beslutning afstedkommer en konstant øgning af hukommelses forbrug ved eksekvering af processen. Beslutningen resulterer i en begrænset køretid afhængigt af den valgte mængde af hukommelse hvori processen eksekveres. En proces med ca. 4000 enheder optager ca. femhundrede megabytes. Et anslået estimat på ca. 10.000 enheder vil optage ca. femtenhundrede megabytes og så fremdeles. Det betyder at man skal bruge virkeligt meget hukommelse for at køre programmet færdig. Kan det lade sig gøre og hvad er hukommelse? Alle Java processer eksekveres i en JVM, container, som har automatisk hukommelsesstyring. Den allokerede mængde hukommelsen som er afsat til at indeholde programmet kaldes Heap Memory. Denne container kan dekoreres med flag som bestemmer fordelingen mellem de enkelte hukommelsesområder der allokeres til hver applikation. Der findes forskellige områder eller pools under den fælles betegnelse Heap Memory. Nogle af disse områder holder på nye objekter og andre på gamle. Heap er delt op omkring to hovedområder, heap space og non heap space. * Eden Space - Pulje, hvorfra hukommelse er oprindelig blev tildelt for de fleste objekter. * Survivor Space - Pool indeholder objekter, der har overlevet GC for Paradis rummet. * Tenured generation - Pool indeholder objekter, der har eksisteret i nogen tid i den overlevende plads * Faste Generation - Besidder alle de reflekterende data i den virtuelle maskine selv, såsom klasse og metode objekter. Med JVMs at bruge klasse deling af data, denne generation er opdelt i read-only og read-write områder. * Code cache - Memory anvendes til udarbejdelse og opbevaring af native kode * Perm Gen – Stak eller information om alle de objekter som er placeret i hukommelsen. Den fælles samlede mængde hukommelse er den vigtigste faktor. Men hukommelsen har også direkte indvirkning på garbage collection. GC er den proces som administrer hukommelsen og sikre at de programmører som skriver Java kode ikke behøver at vide noget om allokering af hukommelse. Ydeevnen ved garbage collection hænger tæt sammen med hukommelsen. Når hukommelsen når en vis udfyldings grænse kaldes GC af systemet med jævne mellemrum. Under en garbage collection re-allokeres alle objekter i heap. Nogle objekter flyttes mellem forskellige pools mens andre fjernes helt. Heap vokser eller falder ved hver GC for at bibeholde forholdet mellem fri plads og de levende objekter. Fx indeholder Perm information om objekter i Eden og dermed kan man begynde at ane et mønster om relationer mellem de enkelte rum. Normalt er det god skik at stille JVM MIN til 512m og MAX til det samme. Ved denne indstilling kan systemet starte hurtigt og bruger ikke tid på store re-allokeringer af hukommelse ved GC. <pre> -Xms512m -Xmx512m </pre> Hvis applikationen hænger eller får en ”java.lang.OutOfMemoryError” har man et heap problem. Typisk vil applikationer blot standse helt eller delvist. Hvis man angiver for stor hukommelse vil det tager langt tid at køre GC og derved vil applikationen opleve ”stop and go” funktionalitet med alvorlig forringelse i ydeevne. Applikationer med dynamisk kode og mange klasser som fx GEN, JSP, groovy osv kan blive nødt til at øge MaxPermSize. Den default JVM størrelse for stakken er 64 megabyte. <pre> -Xms512m -Xmx1024m -XX:MaxPermSize=128m </pre> Hukommelsen gemmer objekter og stakken holder styr på oplysninger om objekter. Derfor, jo flere objekter, der findes, jo mere information finder der og jo større stak skal gennemløbes ved hver GC. Efter denne logik fyldes Perm hurtigere hvis din applikation indeholder mange små class-filer frem for få store class-filer. Hvordan sikre man at disse opstarts parameter rent faktisk virker? I Java 5.0 findes et omfattende overvågnings og ledelsesmæssig værktøj. Jconsole er en grænseflader indtil Java Virtual Machine men giver også out-of-the-box fjernbetjening, overvågning og forvaltning. Den bruger omfattende instrumentering af JVM for at give oplysninger om ressource forbrug af applikationer ved hjælp af Java Management Extension (JMX) teknologi.. Man kan lave sine egne beans til overvågning og styring af selvbyggede processer i JVM. En bean skal følger og opfylde JMX design mønstre. En bean kan repræsentere et program eller en ressource som skal forvaltes. Intern i bean findes læse og skrive attributter samt metoder til invokation. En bean kan også udsende meddelelser ved at foruddefinerede begivenheder. Hvis man vil monitorere en remote proces i en JVM kan man tilføje disse –D parameter. <pre> -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=[port] -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false </pre> Derefter er at blot at starte Jconsole og connected under remote fanen. Der findes en række parameter man kan overføre til JVM via -D argument. Men måske må du ser realiteten i øjne og erkende at din applikation har alvorlige fejl som bør løses. * Xmx1500m # Heap size på 1500 MB * Xincgc # Incremental low pause collector. Løbende oprydning af tenured space. * XX:GCTimeRatio=24 # lad JVM selv bestemme sit footprint ud fra en målsætning om at bruge 4% af tiden på GC * Xmn1g # newsize på 1GB, svarer til ratio på 2/3 på jespers server (?) * Xss128k # reducerer størrelsen af stakken ifht. det vi kører med nu mhp. at skabe mere plads til hoben. * XX:+UseConcMarkSweepGC # Concurrent mark sweep collector * XX:SurvivorRatio=10 # Survivor space 1:10 * XX:TargetSurvivorRatio=90 # Bedre pladsudnyttelse af survivor space * XX:MaxTenuringTreshold=15 # Objekter kan overleve flere sweeps førend de bliver flyttet til tenured 2008-10-14T03:32:26Z 123 123 true 30 2008-10-22T22:32:12Z I disse grønne miljø tider må man som udvikler tænke på mange ting. Denne gang vil jeg først og fremmest tænke på strømforbrug og etiske regelsæt når man konstruere og drifter systemer. Det ville være fedt at have små super hurtige systemer som kan fungere ved at minimalt energiforbrug. Jeg har i mange år haft mine egen dedikeret serverer men i lange tider står de faktisk næsten ubenyttet hen. Nu behøver jeg ikke et top moderen drift center til mine små webapplikationer og EDI udveksling men jeg har alligevel sat et par mål. * Hardwaren må ikke bruge mere en 10 Watt. * Hardwaren må ikke være hørbar på en meter. * Inge service må tage mere end et halvt sekund. Normalt vil de fleste bare have maksimal hastighed men det er faktisk ikke særligt sjovt, og det forbruger en masse strøm og udvikler dermed også en masse varme. Jeg har fx en Dell Laptop der bliver så varm at jeg ikke kan se film og samtidig ha den på lårene. Ved at gå lidt ned i CPU hastighed og i stedet indføre multi-core chiplevel Multi Processor(CMP) kan man opnår en betragtelig udnyttelsesgrad men næsten ingen øgning i strømforbrug. Nu er det selvfølgelig sådan at næsten ingen applikationer kan udnytte flere CPU kerner til fulde. Fx kan man se en Java proces udnytte den ene proces 100% på en dual core maskine mens den anden står ubenyttet i dvale. Jeg har købt en linutop. Det er en lille box med superlavt strømforbrug og den er lydløs fordi der ikke er bevægelige dele i den. Reelt set er det kun et stykke printplade med nogle chips samlet i en aluminiums kasse. Den har ikke nogen harddisk eller andet som æder strøm eller skaber varme, kun CPU'en laver lidt varme. Boxen har en AMD Geode LX700 processor med 256 MB RAM og 4x USB 2.0 porter, audio og 10/100baseT Ethernet og VGA output. Den forbruger 5W. Der findes ikke et operativ i boxen men jeg vil have linux på den. Derfor har jeg prepereret en USB nøgle med Mandriva, mit favorit linux styresystem gennem mange år. Mandiva kan installeres som fuld desktop eller server installation. <a href="http://store.mandriva.com"> <img width="100" src="http://store.mandriva.com/images/Mandriva-linutop2.jpg"></a> Når Linutop’en modtager en bootable USB med et operativsystem starter den en lille fin distribution op med linux kernel 2.6.22.9-desktop586-1mdv med grafisk KDE 3.5 grænseflade. USB'en køre perfekt på alle mine computere så længe den bruger de respektive interne ressource men på linutop er problemet den lille AMD processor og de kun 256 MB RAM. Mandriva booter ikke default med sshd installeret og derudover er firewallen hermetisk lukket. Af gammel vane og for lidt ram skifter jeg ved samme lejlighed til et lavere runlevel i /etc/inittab, jeg har ikke brug for at logge grafisk ind over X. Så er det ssh til boxen og installere noget software. Da softwaren er en fuldfed desktop udgave med 100vis af processer kørende og det tager lidt tid at finde alle de processer som jeg kan slukke uden det betyder noget for serveren. Her er resultatet, ca. 50 processer tilbage og lige over 60 MB fri mem. Når man ssh til boxen kan man fx starte drakconf, applikationen køre lynhurtige og kaster sit images på på den box hvor jeg er logget ind fra. <pre> top - 01:45:20 up 45 min, 1 user, load average: 0.00, 0.00, 0.07 Tasks: 52 total, 1 running, 51 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 235792k total, 171112k used, 64680k free, 15904k buffers Swap: 0k total, 0k used, 0k free, 131304k cached </pre> Så er min lydløse USB computer ved at være parat til at få installeret software, jeg vil køre med ruby on rails, en webserver instans, en database og nogle kontrolstrukture til vedligehold og genstart af serverne. <pre> frank@linutop www]# free -m total used free shared buffers cached Mem: 230 176 53 0 16 110 -/+ buffers/cache: 49 181 Swap: 0 0 0 </pre> Når det hele køre må det helst ikke fylder mere end ca. 40MB mem. Ruby er standard på mandiva men rubygems og ruby on rails er ikke. På samme måde skal der vælges en database. hmmm gerne en med lille footprint. Normalt ville jeg benytte Apaches httpd server som webserver men da RAM er lidt begrænset vil jeg udskifte den med noget andet. Ofte fylder et kald til en apache instans op til ca. 20MB og det ville hurtigt slukke serveren. Min andet bud på en webserver er lighttpd, den er kendt for et specielt lille foodprint. Mongrel er en hurtig HTTP server for Ruby som benytter ren HTTP fremfor FastCGI som de to andre bruger. Da alt software ligger på en USB nøgle vil jeg gerne undgå at compliere yderligere pakker som fx fcgi. Thin er en ret ny og ret uprøvet webserver men da den er udviklet i ren ruby vil jeg alligevel forsøge mig med den. Den skulle være endnu hurtigere end Mongrel men jeg har også erfaret at den mister en tråd en gang i mellem. Det betyder at operativsystemet fanger en tråd som bruger en 10 til 15 procent af CPU’en. Efter 1 min bliver den piggybacked. Mongrel serveren bruger ca. 25 til 40MB i min opstilling her og det overrasker mig en smule at Thin bruger lidt mere. Om den i virkeligheden er hurtigere ved jeg ikke. Som database vægler jeg Sqlite. Rails 2 vælger den som default og jeg er med på noget nyt, eneste rigtige showstopper med sqlite er for mange clienter til samme database men det er ikke et problem her. Migrate af data fra mine gamle databaser til sqlite bliver også håndteret af ruby. Se post Mutible ActiveRecord. Som det ses er databasen på lige over 3 GB. Lidt sejt når der også er et linux system på flash nøglen. <pre> [frank@linutop db]$ ll -h total 332K -rw-r--r-- 1 frank frank 10K 2007-01-25 01:09 dev.sqlite3 drwxr-xr-x 2 frank frank 4.0K 2008-01-02 23:04 migrate/ -rw-r--r-- 1 frank frank 3,6G 2008-01-04 15:04 production.sqlite3 -rw-r--r-- 1 frank frank 1.6K 2008-01-03 14:56 schema.rb </pre> Så er det tid til at starte hele dynen. Jeg har lavet nogle scrips til start og stop af serveren og sat cron til at checke om den køre og hvis ikke starte den. I første omgang vil jeg bare køre en enkelt instans men det ser ud til jeg kan køre flere hvis det behøves. Underligt nok fylder en enkelt instans ca. 35 MB mens to fylder kun lidt mere? Ulempen er hastigheden grunden den relativt lille mænge RAM. Stabiliteten har indtil videre være utrolig høj. Her er en kørsel efter næsten 4 døgn. Man kan se kthreadd har være aktiv, nok en tabt tråd fra Thin. Thin serveren bruger 33M og ser aktiv ud. <pre> top - 21:54:36 up 9 days, 2:16, 1 user, load average: 0.12, 0.04, 0.01 Tasks: 57 total, 1 running, 55 sleeping, 1 stopped, 0 zombie Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 235792k total, 231660k used, 4132k free, 22328k buffers Swap: 0k total, 0k used, 0k free, 133180k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 1652 564 492 S 0.3 0.2 0:16.59 init 10899 root 20 0 42596 37m 3088 S 0.3 16.3 89:30.20 thin 11576 frank 20 0 2160 972 796 R 0.3 0.4 0:00.09 top 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:01.61 ksoftirqd/0 </pre> h5. Update <pre> top - 18:46:21 up 43 days, 23:07, 1 user, load average: 0.06, 0.06, 0.01 Tasks: 57 total, 1 running, 55 sleeping, 1 stopped, 0 zombie Cpu(s): 0.3%us, 0.7%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 235792k total, 231824k used, 3968k free, 16220k buffers Swap: 0k total, 0k used, 0k free, 117904k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17282 frank 20 0 2160 976 796 R 0.7 0.4 0:01.71 top 12344 root 20 0 56464 51m 3092 S 0.3 22.2 713:56.60 thin 1 root 20 0 1652 564 492 S 0.0 0.2 1:06.82 init 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 4 root 15 -5 0 0 0 S 0.0 0.0 0:02.68 ksoftirqd/0 5 root 15 -5 0 0 0 S 0.0 0.0 2:54.08 events/0 6 root 15 -5 0 0 0 S 0.0 0.0 0:00.04 khelper 29 root 15 -5 0 0 0 S 0.0 0.0 0:00.82 kblockd/0 30 root 15 -5 0 0 0 S 0.0 0.0 0:00.05 kseriod </pre> Hvis du kan læse denne blog køre min linutop :-) Fascinerede lydløst "Linutop":http://linutop.com/ "Mandriva store":http://store.mandriva.com/ 6 2008-01-09T22:18:00Z 90 90 false 30 2008-03-10T01:40:50Z Hvad er en entreprise service bus og hvad skal en ESB gøre? Heldigvis findes ingen konkret industri definition på en ESB. Nogle definere en ESB som værende en arkitektur komponent, andre definere ESB med udgangspunkt i hardware platforme og andre igen definere ESB som arkitektoniske mønstre. ESB definitionen betyder forskellige ting for forskellige mennesker desværre. Hvis man søger informationer om ESB gennem brochure, på web eller hos udbyder af løsninger får man endnu flere forskellige rettede oplysninger. Reklamerne er fulde af buswords som workflow, BPEL server og applikation extensions osv osv. Svært at forstå hvad det i virkeligheden er og mange bruge masser af tid på at prøve at forstår Man kan vende det lidt på hoved og prøve at definere en bus udefra hvilken egenskaber den udfylder og hvad som skal erstatte den ifald den fjernes. ESB er en implementering af SOX som er en eksekverings kontekst. Med andre ord, i SOA har vi en klient som er en forbruger af services og vi har en server som er en udbyder af services. ESB har til hoved opgave at forbinde de to på den mest simple måde, hurtigt og let. Ud fra et definitions standpunkt passer ESB’en perfekt. Hvor kan man med fordel bruge en ESB og hvornår skal man ikke? Et godt eksempel er når der findes flere delte services på flere klient applikationer. Dette er et typisk SOA scenario hvor en ESB performere virkeligt godt. Et dårligt eksempel er en single silo applikation med få dedikeret services. Skal man have et ESB produkt for at implementere en SOA applikation? Det er et trick spørgsmål. Nej. Der er tre ting man kan bruge i stede, en hardware plan, en software produkt eller man kan bruge et mønster men det som er pointen her er at når vi implementere SOA der er bestemte egenskaber som skal være til stede som fx ruting, besked udveksling, besked transformation, besked protokol, osv. Disse egenskaber skal være et sted i en SOA applikation og forhåbentlig er det ikke klientens ansvar, heller ikke sevices, og heller ikke middelware. Så svaret er stadig nej, men så må man selv implementere de egenskaber som en ESB løser. ESB implementere ikke direkte en service orienteret arkitektur (SOA) men tilbyder svar på mange forskellige løsninger. Det er en fælles overbevisning at en ESB kun er til web services men der kan benyttes mange protokoller. ESB bør være standart baseret, fleksible og supportere mange transport media. Baseret på EAI frem for SOA mønstre prøver det at fjerne den tætte kobling mellem service kalder og selve transport medium. Er der nogen ting som man kan undvære i en ESB? Hvis man kigger på en ESB som en arkitektur komponent ud fra et objekt orienteret synsvinkel er der klart egenskaber som procenterne smider med I pakken som ikke nødvendigvis tilhører en effektiv messing bus. Analogi til Java sproget. Vi taler ikke mere om Java som sprog men mere som en platform. Vi inddrage en masse komponenter under det samme ord. Og sådan er det også med en ESB. En ESB som komponent bør hurtig, let og funger som middelware messing bus men vi begynder at fylde mere og mere adfærd på den, nogle gange er det nødvendigt og andre gange er det bare flof. Ting som efter min mening ikke hører hjemme i en ESB er fx process choreography, services orchestration og meget andet gejl. Måske mangler der en rå super hurtig beskeds bus som kan binde klienter og server samme. 6 2007-03-21T09:08:00Z 29 29 false 30 2008-04-08T07:17:32Z The single biggest hardware issue affecting web server performance is RAM. A webserver should never ever have to swap memory! Swapping increases the latency of each request beyond a point that users consider "fast enough". This causes users to hit stop and reload, further increasing the load. You can, and should, control the MaxClients setting so that your server does not spawn so many children it starts swapping. The procedure is simple: determine the size of your average Apache process, by looking at your process list via a tool such as top, and divide this into your total available memory, leaving some room for other processes. This issue becomes major when you realize that after each process has done its job, the bloated process sits and spoon-feeds data to the client, instead of moving on to bigger and better things. This problem is compounded by a bit of essential info that should really be more common knowledge: If you serve 100% static files with Apache, each httpd process will use around 2-3 megs of RAM. If you serve 99% static files and 1% dynamic files with Apache, each httpd process will use from 3-20 megs of RAM (depending on your MOST complex dynamic page). This occurs because a process grows to accommodate whatever it is serving, and NEVER decreases until that process dies. Unless you have very few dynamic pages and major traffic fluctuation, most of your httpd processes will soon take up an amount of RAM equal to the largest dynamic script on your system. A very smart web server would deal with this automatically. As it is, you have a few options to manually improve RAM usage. Beyond that the rest is mundane: get a fast enough CPU, a fast enough network card, and fast enough disks, where "fast enough" is something that needs to be determined by experimentation. 6 2007-01-27T00:40:00Z 2 2 false 30 2008-08-20T09:30:04Z