Mysteriet opklaret: Rengøring i hukommelsen gav lange svartider på folketinget.dk

De ofte alenlange svartider på Folketingets hjemmeside skyldes, at serveren har brugt for meget CPU-tid på at frigøre hukommelse. Det har en særlig arbejdsgruppe nu slået fast.

En lidt for hyppig hovedrengøring i server-hukommelsen har vist sig at være hovedårsag til de problemer med lange svartider, Folketingets hjemmeside i perioder har kæmpet med siden relanceringen i oktober sidste år.

Det fortæller Folketingets webmaster Jørn Sjøstrøm, efter at en særlig task force nu mener at have analyseret sig frem til problemets årsag.

Serveren har ganske enkelt brugt for meget tid på at skulle frigøre hukommelse gennem garbage collection. Det formodes at være den primære årsag til svartidsproblemet.

»Garbage collection er meget CPU-krævende og er nogle gange blevet udført for ofte. Når folketinget.dk ikke har svaret i perioder, skyldes det, at serveren har kørt med stort set 100 procent belastning af CPU'en på grund af garbage collection,« siger Jørn Sjøstrøm.

Ændrede tærskelværdi for garbage collection

Garbage collection er en mekanisme, der på visse tidspunkter frigiver hukommelse ved at fjerne 'døde' objekter, der ikke længere er i brug af applikationen.

Det relancerede folketinget.dk kører på version 5.0 af CMS'et Sitecore, som er baseret på Microsofts .Net-teknologi. I Sitecore er der derfor mulighed for at sætte tærskelværdien for, hvornår garbage collector'en skal på banen for at rydde op i hukommelsen.

I tilfældet folketinget.dk har loftet altså været sat for lavt.

»Derfor har vi nu ændret tærskelværdierne for, hvornår vi er oppe på at have opbrugt hele hukommelsen,« siger Jørn Sjøstrøm.

Så I forventer ikke, at der bliver flere problemer med lange svartider fremover?

»Man kan aldrig vide sig sikker i denne verden, men det håber vi ikke,« siger Jørn Sjøstrøm.

Sitecore 5.0 er en 32-bit applikation, og også serverstyresystemet bag folketinget.dk, Windows 2003 Server, kører 32-bit. Styresystemet er derfor lige nu kun i stand til at allokere op til cirka tre gigabyte hukommelse, samtidig med at det sluger halvanden gigabyte til sig selv.

På længere sigt forventer Jørn Sjøstrøm, at et ryk fra 32 bit til 64 bit af både CMS og styresystem vil sætte hukommelsesproblemet på plads en gang for alle. Jørn Sjøstrøm forventer, at skiftet fra 32 til 64 bit kan ske rimeligt smertefrit i Folketingets virtualiserede servermiljø.

Fremover skal også en load balancing-komponent i form at et cluster på flere webservere sørge for bedre at aflaste folketinget.dk.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Flemming Bach

Undrer mig faktisk også.
Hvordan har de kunne finde på at køre så stort et site på en 32-bit version af windows?

Jeg kan forstå det, hvis det er IIS der kører 32-bit.
Det gør man i nogle tilfælde, hvis der er bestemte dll-filer, der ikke findes til 64-bit.
Men det er ikke grund nok til at vælge at køre OS som 32-bit også.

Og en ny server til web med 64-bit system koster altså ikke så meget igen.
Man kan få en acceptabel HP server for under 40.000 kr inkl. OS og Care-Pack.
Det skulle de da have brugt pengene på i stedet for en flok konsulenter. :D

  • 0
  • 0
Anonym

Jeg vil nok mene at det er mere eller mindre logik for burhøns, at GC (Garbage collector) blot udskyder problemet.
GC er indført fordi folk ikke kan håndtere memory (og egentlig ikke burde kode), men det er nemt for 'programmøren', da man ikke skal tænke så meget selv.

Men 'straffen' kommer, for ting tager tid, og ting tager den tid ting tager, så at udskyde 'opgaven' med oprydning vil jeg sammenligne med opvask.

Hvis man har 12 tallerkner, og 2 brugere, er det nemt at bruge 2 tallerkner, og blot sætte dem til side - det går meget nemt så længe der er rene talerkner, men hvis opvaskeren ikke kan følge med, står man pludselig med disse 12 snavsede tallerkner, og ingen rene.

Her må man så vente på 'opvaskeren' aka GC.

Ad 32 vs 64 bit:
64 bit løser intet, blot skal man tænke 24 tallerkner i stedet for 12, så problemt bliver dobbelt så stort når GC'eren skal igang.

  • 0
  • 0
Mikkel Kruse Johnsen

"64 bit løser intet, blot skal man tænke 24 tallerkner i stedet for 12"

Hvordan kommer du lige frem til 12, du mener at der er dobbelt så mange bits.

Det har da intet med sagen at gøre. 32bit windows kan kun allokere 4GB RAM (vist nok kun 3GB), hvor 64bit windows kan allokere 16TB. Så der er stor forskel. Givet at man sætter mere RAM i

  • 0
  • 0
Vijay Prasad

Jeg vil nok mene at det er mere eller mindre logik for burhøns, at GC (Garbage collector) blot udskyder problemet.

Det er altid en afvejning (hvis man har mulighed for at vælge naturligvis - jeg kender ikke mulighederne i CLR(?)). Vil du hellere have en "let" aftensmad 6 gange og tage sliddet derefter (jf. dine 12 tallerkener), eller vil du lave arbejdet lidt efter lidt? Bruger du samlet mere tid ved nogen af løsningerne? (Det tager lidt tid at gøre opvaskevand klar, osv.)

GC er indført fordi folk ikke kan håndtere memory (og egentlig ikke burde kode), men det er nemt for 'programmøren', da man ikke skal tænke så meget selv.

Er godt klar over dit indlæg sikkert er ment som provokation. Programmøren skal naturligvis være klar over at man arbejder under en GC, ligesom programmøren skal være klar over at "free" skal bruges. Begge dele stiller krav.

Mvh,

  • 0
  • 0
Jesper Louis Andersen

Jeg vil nok mene at det er mere eller mindre logik for burhøns, at GC (Garbage collector) blot udskyder problemet.
GC er indført fordi folk ikke kan håndtere memory (og egentlig ikke burde kode), men det er nemt for 'programmøren', da man ikke skal tænke så meget selv.

GC er nærmere indført fordi gode programmører kan spare en masse tid. En (god) GC gør at du skal være virkeligt nøjsom i din C eller C++ for at slå den - og den slags tager en hulens masse tid. I stedet kan du relativt nemt få en temmeligt god performance med en GC ved hånden.

Problemet er som regel ikke GC'en, men at folk der har den til rådighed har en tendens til at sløse med sin datarepræsentation og derved bruger meget mere hukommelse end de burde. GC løser ikke mem-leaks. Det udskyder højest problemet. Samtidig er det nemt bare lige at allokere et nyt objekt fra GC'en og så smide det gamle ud. Men det øger GC-pressure.

Hvis du behandler din heap med omtanke er det stort set aldrig GC der er problemet.

En ulempe ved GC-strategien er derimod at det kræver et vist frirum for at fungere effektivt. Hvis eksempeltvist FT har allokeret 1 gigabyte til heapen og de så render mod loftet af dette fordi de har 950 megabyte levende data, så tvinger de jo en garbage-collection oftere end godt er. Og de 950 megabyte kan aldrig frigives, thi de er levende. Så falder throughput for applikationen væsentligt fordi størstedelen af tiden foregår i garbage collectoren. En mulig løsning er netop at tune sin GC så den har mere frirum og derved collecter sjældnere.

Standardmetoden for at komme problemet til livs er at benytte sig af en allocation-profiler og en heap-profiler. Man bliver nødt til at se hvem der har allokeret hvad og hvor lang tid man holder på data. På den måde kan man sætte ind overfor for de ofte relativt få steder sløseriet er udtalt.

En af de sjovere historier som er relavant i denne forbindelse, selom der godt nok er tale om skjult reklame for ANTS profileren er:

http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx

  • 0
  • 0
Jesper Mørch

Styresystemet er derfor lige nu kun i stand til at allokere op til cirka tre gigabyte hukommelse, samtidig med at det sluger halvanden gigabyte til sig selv.

Hvorfor skal et system hvis eneste opgave det er at videreformidle tekst- og billed-filer via et netværks-interface sluge 1½ GB RAM??
Selvom det formentlig ikke er muligt, burde et styresystem målrettet http ikke sluge mere end 50-100 MB - incl. CMS'et.
- Hvorfor i al verden skal man frådse med hukommelsen bare fordi man kan??
Altså, jeg kan nok også finde en 2CV og bede den trække en Boeing747, men jeg tror koblingen når at brænde af et par gange...
Hvis Sitecore skal have 1½ GB RAM for at kunne skrive "Hello World" i min webbrowser, er Sitecore ikke et brugbart CMS til andet end hjemmesider for Serie-3 holdet, eller den lokale haveforening.
En server skal ikke bruge ressourcer på sig selv, men på at arbejde for andre...
Alt andet er at bede om problemer!!

  • 0
  • 0
Erik Cederstrand

Hvorfor skal et system hvis eneste opgave det er at videreformidle tekst- og billed-filer via et netværks-interface sluge 1½ GB RAM?

Fordi det er bedre at cache data i RAM end at skulle hente det på harddisken hver eneste gang.

Hvorfor i al verden skal man frådse med hukommelsen bare fordi man kan?

Fordi RAM er billigt, og meget hurtigere end harddisk. Der er ingen grund til ikke at bruge al den RAM man har til rådighed, når nu man har betalt for den.

  • 0
  • 0
Jesper Mørch

Der er ingen grund til ikke at bruge al den RAM man har til rådighed, når nu man har betalt for den.

For at bruge en udbrændt bil-analogi svarer det lidt til at køre til købmanden 500 meter væk og retur i en Hummer H2... Den bruger højst 3 liter benzin på sådan en tur...

Et estimat på hvor meget et komplet website fylder, hvis det er lavet fornuftigt er under 100 MB
Hvorfor skal det så bruge mere end 25 gange mere RAM uden grund?
Et operativsystem som kun har den ene egenskab at det skal kunne servere de pågældende websider (som hovedsagelig er flade tekstfiler og komprimeret grafik), skal altså ikke fylde 15 gange så meget som de filer det skal gøre tilgængelige...
Med endnu en bilanalogi svarer det til at en minibus med 15 siddepladser vejer over 20 tons...
Hvorfor skal et operativsystem (med CMS) som kun skal servere flade tekstfiler over en netforbindelse allokere 1GB på grafik som ikke bruges?
Hvorfor skal der overhovedet allokeres mere end et par MB til grafik på sådan et system? Det skal jo kun optegne en tom konsol... Der er ingen grund til at bruge ressourcer på at optegne en grafisk brugerflade, hvis ikke den skal bruges, akkurat som der ikke er grund til at bruge systemressourcer på systemlyde etc.
Det er en webserver, ikke et mediecenter!!!

  • 0
  • 0
Christian E. Lysel

af Erik Cederstrand, 17. maj 2010 22:3

Fordi det er bedre at cache data i RAM end at skulle hente det på harddisken hver eneste gang.

En lille historie fra det virkelig liv:

Pt. fylder websitet 5GB og basen 8GB (hvilket tyder på der mangler at blive implementeret noget oprydning). De køre pt. på 2 af HPs billigste server med 2 langsomme SATA diske, med 10GB RAM (som er alt for meget) med typo3/apache/mysql. Miljøet smider 600 sider afsted i sekundet. Total udgiften var 20.000 kr (med penge til overs).

Dette setup skal gøres 3 gange større (besøg, sider og udvidelse med shop) og flyttes til sitecore. Den sidste skitseret løsning jeg så, skal bruge 128 GB RAM, fordelt på 7 server med SAS disk i RAID, opdelt til henholdvis operativsystem, database og log. Det er sizet til at håndtere 71 side visninger i sekunder i peak belastning. Hvis det ikke virtualiseres gætter jeg på det løber op i 280.000 kr i hardware. Det er en faktor 14, for at drive miljøet på sitecore og implementere en shop.

Argumentet omkring RAM forbruget, er der er cache i webtierne, commerce serverne og MSSQL serverne.

Man skal ikke sammenligne de 128GB RAM med vores andre systemer ... vores ERP, datawarehouse og forcast database systemer bruger til sammenligning 16 GB ialt, og håndtere langt større mængder data (2 TB) og transaktioner.

Et andet system med 140 samtidige remote desktop brugere har kun 3GB RAM, til at holde styr på 1.400 ansattes tidsplanlægning.

Hvorfor skal webapplikationer bruge så mange ressourcer?
Blev præsentationslaget ikke håndteret af klienten?

  • 0
  • 0
Maciej Szeliga

Det har da intet med sagen at gøre. 32bit windows kan kun allokere 4GB RAM (vist nok kun 3GB), hvor 64bit windows kan allokere 16TB. Så der er stor forskel. Givet at man sætter mere RAM i

2 GB medmindre man sætter /3GB i boot.ini (pas på, switchen fucker andre ting op) men det er pr. proces så med PAE kan du bruge 128 GB RAM i W2K3 Enterprise 32-bit.

  • 0
  • 0
Pauli Østerø

pinligt pinligt! Det er historier som dette der sætter IIS, .Net og Sitecore i dårligt lyst.

Det er altsammen fine systemet hvis man bare kan finde ud af at bruge dem ordenligt. Men som med så mange andre ting her i verden skal der ikke mere end et par inkompetente klovne til at smadre selv den flotteste Mercedes.

Træls som de ville sige det i Jylland, træls at de dårlige historier får lov at fylde så meget i medierne.

  • 0
  • 0
ab ab

Et estimat på hvor meget et komplet website fylder, hvis det er lavet fornuftigt er under 100 MB
Hvorfor skal det så bruge mere end 25 gange mere RAM uden grund?

Jeg går ud fra, at du taler om data til det pågældende netsted i det ovenstående, og her mener jeg, det må være sin plads at påpege, at Folketingets netsted nok er lidt et særtilfælde, da det som bekendt rummer såvel lov- som beslutningsforslag med bemærkninger i flere udgaver som §20- og udvalgsspørgsmål og gengivelser af folketingspolitikernes taler og diskussioner i udvalg gennem de sidste 6 år. Det gør formodentlig omfanget af data væsentligt større end de 100 MB, som du estimerer. Hvis vi regner på det:

100 MB = 104.857.600 bytes fordelt på (6 år med 40 uger à 4 dage) = 109.226 bytes per dag, hvilket omtrentligt svarer til 54 sider med 2.000 anslag per side. Folketinget har 179 medlemmer, og skulle de alle have mulighed for at tale til referat hver dag, ville det give dem hver knap en 1/3 A4-side per dag - og denne fordeling tager endda ikke højde for behovet for også at opbevare selve lov- og beslutningsforslagene i de forskellige udgaver.

Det kan selvfølgelig godt være, at de enkelte MF'ere kan begrænse sig til 1/3 A4-side per dag, men det forekommer mig umiddelbart urealistisk, når man betænker længden af den typiske ordførertale.

  • 0
  • 0
Jesper Louis Andersen

Når Poul-Henning Kamp nu har lavet et så dejligt cache system, som en gang for alle løser det problem at cms'er ikke scalere.

Det er den del af mysteriet jeg heller ikke kan forstå. Det lyder som en dårlig ide at lade selve CMS-systemet basere sig på at have en cache i en garbage-collected heap. Skulle jeg designe et sådant system, så ville jeg helt sikkert have en cache i CMS-systemet, men jeg ville nok basere den på en seperat applikation såsom memcached, så jeg kunne adskille caching-funktionaliteten fra selve CMS'et. Det gør den del meget nemmere at styre. Bevares, det er nemmere for programmøren at cachen ligger som en del af C#-heap'en, men det er næppe praktisk smart. Hver gang en (major) garbage collection træder i kraft kommer vi til at skulle vade hele heap'en igennem, også selv om major-generationen collectes inkrementalt. Jo flere små objekter vi har i heap, jo dyrere bliver den operation (få store objekter tager derimod ikke lang tid). Hvis vi outsourcer den del til memcached, der er bygget til den slags, så er det formentlig meget meget nemmere at håndtere memory usage.

Dertil kommer at det i moderne operativsystemer som regel er dumt at cache i applikationslaget hvis der er tale om data i en fil. Operativsystemet er meget bedre til den slags. Det er også en af grundende til at det er smart at få sin heap-size i GC'en lidt ned: OS'et får noget mere ram til sin disk-cache og det hjælper som regel. Ellers risikerer man desværre at man hele tiden evict'er disk-cachen - med elendig performance til følge. Og så får man den ide at mere RAM til ens app-layer cache er løsningen :/

Desuden kan vi køre memcached på en anden maskine. Prisen i throughput for at have et par requests over netværket er formentlig til at overse, selvom den enkelte request bliver en smule langsommere af det.

Derudover ville jeg satse på at have en webaccelerator foran systemet fra dag et. Enten i form a Varnish, Squid, eller et CDN. Fordi at lave dette rigtigt betyder at jeg som programmør kan spare væsentlig tid. F.eks. behøver jeg ikke bekymre mig synderligt om at optimere kodevejen for en stor del af komponenterne, fordi Varnish tager sig kærligt at den del.

  • 0
  • 0
Log ind eller Opret konto for at kommentere