[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [enterprise] Maskiner med 128 GB RAM - erfaringer



I sslug.enterprise, skrev Hanne Munkholm:
>  Vi købte oktober for første gang en server med 128 GB RAM (24 cores - 4
>  x 6-core).

Lækkert jern! Vi har 8x4-core i den størate med 64GB ram. 

>  Det største vi har haft før er 32 GB RAM, og det er tilsyneladende lidt
>  af et spring.
> 
>  Hvis der er nogen der kan bidrage med noget reel viden, erfaringer,
>  eller links til seriøse artikler omkring hvad man skal tage højde for
>  med sådan en maskine, vil jeg gerne have noget input.
> 
>  Den kører Debian etch, og vi startede med default kernen, en noget
>  gammel 2.6.18 efterhånden.
> 
>  Da folk kom i gang med at bruge den fik vi I/O performance problemer, og
>  den crashede også med en I/O fejl et par gange. 

Dette er "i mine øjne" 2 forskellige problemer. I/O performance
problemer, der kan du med fordel kigge på den tråd som Troels linkede
til. Men når du ser crashes så tror jeg også du har en enkelt eller 2
defekte ram-klodser siddende i maskinen. Jeg antager at det er
server-hardware du har med at gøre, så der er sikkert en ilom-log der
kan fortælle dig om systemet har nogle problemer. 

Jeg har oplevet på maskiner med 64GB ram at de først "sprang" i luften
når de blev pressede. Dette skyltes simpelthen at rammen ført blev brugt
til noget i den situation og havde siddet ubenyttet hen indtil.
Serverens ilom-log kunne sågar fortælle mig hvilken ram-sokkel det
defekte modul sad i. (Sun hardware). 

>  Først troede jeg det
>  havde noget med disksystemet eller filsystemet at gøre, men jeg endte
>  med at konkludere at det var flush af RAM der tilsyneladende "hængte"
>  systemet i intervaller, og det hjalp også en del at skrue på parametrene
>  /proc/sys/vm/dirty_background_ratio og /proc/sys/vm/dirty_expire_centisecs.
> 
>  Tilsyneladende flushes dirty RAM når en vis procent-del af RAM er dirty,
>  og 10% af RAM'en har en lidt anden betydning med 128 GB RAM end med
>  f.eks. 4 eller 8 GB. Det er det jeg kan stille på med
>  dirty_background_ratio, og den har jeg sat ned fra 10 til 2.
> 
>  dirty_expire_centisecs kan ændre på hvor gamle sider skal være før
>  pdflush skriver dem ud, og den har jeg sat lidt op, fra 3000 til 4000.
> 
>  Det var et quick fix, som hjalp en del, men ikke helt afhjalp problemet,
>  den virkede stadig lidt tung af og til. Og de værdier jeg har valgt er
>  lidt et skud.

Vi har ingen med 128GB (endnu) men på dem med 64GB kan jeg godt fornemme
problemet. Jeg har ikke pillet ved de parametre du nævner ovenover fordi
det var åbnelyst i vores situation (den Troels nævnte) at det absolut 
ikke var det der var problemet. Når man loggede mængden af dirty-pages, 
så skulle man have en utroligt ringe ide-disk neden under for at det skulle 
tage over 10 sekunder at flush'e det og alligevel tog det over 480. 

>  Vi prøvede naturligvis en nyere kerne ved først kommende lejlighed, med
>  en hjemmebygget 2.6.28 hvór jeg enablede en masse ting der så spændende
>  ud, og disablede alt hvad vi ikke skulle bruge (og lidt vi egentlig
>  skulle bruge - DVD-drevet, ups *G*), og det hjalp endnu mere, men jeg
>  kører stadig med de ændrede vm parametre.

Vi kom fra Ubuntu standardkernen, men kører 2.6.27/28 på dem nu.
Ubuntu's standardkerne har noget semi-defekt NFS bygget ind. (i hvert
fald for os). 

>  Men er det en god idé? Eller er der i virkeligheden en måde at fortælle
>  kernen på at den har meget RAM, så den selv gør det på en mere fornuftig
>  måde?

Jeg tror det er en god ide at holde den på "rimeligt" nye kerner det
næste stykke tid. Der blev fikset ting i default-scheduleren[1], samtidigt
med en del ændringer mht. fsync i ext3 i denne cycle og Jens Axboe har
en patchesæt der ændrer hvor mange tråde der forsøger at skrive til
diskene (tidligere har det vist været en per kerne, men skifter til en
per device). 

[1] http://thread.gmane.org/gmane.comp.file-systems.ext4/12492/focus=12534

>  Det skal nævnes at vi ikke bruger maskinen til virtualisering som mange
>  andre nok ville bruge den type maskine til, vi bruger den til number
>  crushing på nogle store datasæt. Dvs. vi kan nemt komme ud for at èn
>  process bruger størstedelen af RAM'en en gang imellem.

Sådan har vi det også hos os. Jeg gætter på genom-assemblies med velvet?-)

Jeg skal være ærlig at jeg sad med den samme fornemmelse i kroppen,
spørgsmålet nagede: "Hvorfor har andre med dette hardware ikke de samme
problemer", indtil virtualiseringstanken ramte hjernen. 

>  De gamle tommelfingerregler for swap holder heller ikke rigtig mere.
>  Jeg fandt en diskussion om det på nettet:
> 
>  http://www.cyberciti.biz/tips/linux-swap-space.html
> 
>  Det er på den ene side ikke meningen den skal swappe. På den anden side
>  så er der ikke noget der hedder "RAM nok" for os, ... swappen har været
>  i brug, og de 8 GB jeg har givet den virker som for lidt. Så nu prøver
>  jeg nok med 16 når jeg får lejlighed til at lave den om.

Stik den "nok". Jeg har endnu tilgode at se swap gøre nogen skade
(untagen når swap-devicet har bad-blocks). 

Swap gør at når en "vandvittig" bruger har brugt alt ram og lidt til, så
kan sysadm stadig stikke ind og finde ud af "hvem" man skal ringe til. 

Jesper
-- 
./Jesper Krogh, sslug@sslug, Jabber ID: sslug@sslug



 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2009-05-01, 02:01 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *