Optimalisere linux kjerne!

[Erlend85]

Hva innebærer dette? Er det risky når du kun har SSH? Og hvis jeg nevner Ubuntu 8.04, er det noe vits? Får man bedre ytelse! CPU er Q6600.

Takker for alle svar angående dette .

[hockey500]

for å svare på det første, "hva innebærer dette":

kjernen i f.eks. ubuntu er svært generisk, den har støtte for mye forskjellig hardware. Det meste trenger du ikke, og det kan du trygt fjerne ved å kompilere din egen kjerne. I tillegg kan du kompilere kjernen spesifikt for ditt system, noe som kan gi en viss ytelsesøkning.

 

"Er det risky når du kun har SSH":

jeg ser ikke noe som helst logikk i den setningen, så det ignorerer jeg.

 

"Og hvis jeg nevner ubuntu 8.04, er det noe vits?"

nok en gang, hva mener du med det? du kan kompilere din egen kjerne i 8.04 også selvsagt, men hvorfor skal du gjøre det?

 

"Får man bedre ytelse!" (hva er greia med utropstegn etter den setningen?)

i de fleste tilfeller praktisk talt ingenting. Ikke gjør det er mitt råd. Du slår meg ikke som typen som vet hva du bør gjøre for å optimalisere en kjerne, så gå utifra at ubuntu-utviklerne har bedre peiling enn deg.

[Erlend85]

Nei, jeg leste litt om srcds, og jeg leser at serveren kan kjøre med bedre fps hvis du optimaliserer linux kjerne. Jeg hadde bare håpet noen av dere ville dele noen tanker om det .

[hockey500]

Hvis du kan fortelle meg hva du legger i ordet FPS, så kanskje jeg kan hjelpe. for den vanlige betydningen av ordet har null og niks å gjøre med serveren du spiller på.

[Manuel]

Det er sjelden hensiktsmessig å kompilere en egen kjerne. Grunner til at du ønsker å gjøre dette kan være fordi Ubuntu-kjernen mangler støtte for din maskinvare, du ønsker å bruke spesielle funksjoner som ikke lar seg aktivere gjennom Sysctl eller for moro skyld. At du vil merke noen forskjell ved å kompilere kjernen mot en nyere prosessorarkitektur tviler jeg på.

 

Hvis du velger å kompilere kjernen selv så må du også huske å kompilere eventuelle ekstramoduler som ikke følger med kjernen. Eksempler på dette er de driverene man får gjennom "linux-restricted-modules".

[A!1]

En kan nok spare litt minne ved å stippe kjernen for alt unødvendig, men det er ingen hensikt på en maskin med C2Q6600 som trolig også har nok ram. Da anbefaler jeg heller å sette inn litt mer minne hvis du mangler det.

[oj88]

Hva innebærer dette? Er det risky når du kun har SSH? Og hvis jeg nevner Ubuntu 8.04, er det noe vits? Får man bedre ytelse! CPU er Q6600.

Takker for alle svar angående dette .

 

Du skal være ganske kyndig for å begi deg ut på noe sånt. Klart du kan få noe bedre ytelse ved å strippe kjernen og kompilere mot din maskinvare, men det er minimalt. Dessuten kan du få problemer på en distribusjon som Ubuntu, som på flere måter er beregnet på å kjøre Ubuntu sin kjerner (f.eks proprietære drivere nevnt over).

Endret 27. mai 2009 av oj88

[WonderBjarne]

Hva innebærer dette? Er det risky når du kun har SSH? Og hvis jeg nevner Ubuntu 8.04, er det noe vits? Får man bedre ytelse! CPU er Q6600.

Takker for alle svar angående dette .

 

Du skal være ganske kyndig for å begi deg ut på noe sånt. Klart du kan få noe bedre ytelse ved å strippe kjernen og kompilere mot din maskinvare, men det er minimalt. Dessuten kan du få problemer på en distribusjon som Ubuntu, som på flere måter er beregnet på å kjøre Ubuntu sin kjerner (f.eks proprietære drivere nevnt over).

Du trenger ikke være så veldig kyndig. Husker jeg kompilerte egen kjerne for noen år siden da jeg kjørte Slackware 10 ellerno sånt. Leste litt dokumentasjon og fulgte rådene som stod skrevet da jeg skulle krysse av for de ørten tusen tingene kjernen skulle støtte. Fikk alt til å fungere på 3-4 forsøk.

Jeg la de driverne jeg trengte direkte inn i kjernen, ikke som moduler, og etter det jeg kan huske så fikk jeg en litt raskere oppstart.

Lærte ekstremt mye om GNU/Linux den tiden jeg brukte Slackware og hadde egenkompilert kjerne, men nå hadde jeg ikke orket å gå tilbake til Slackware. Ubuntu gjør deg lat

[Sokkalf™]

Kompilering av kjerne har da også blitt litt mer komplisert enn det var i "begynnelsen". Ikke veldig, men ting som f.eks å lage en initrd osv var ikke ting jeg trengte å gjøre når jeg surret med Slackware for 10 år siden.

 

Sier ikke at det er spesielt vanskelig, men det er ikke verdt det mtp. den minimale ytelsesøkningen/minnebesparelsen man får, annet enn i helt spesielle tilfeller.

 

En annen ting er at man etter å ha kompilert en kjerne selv, må passe på å oppdatere den selv også. Dvs, skulle det dukke opp en exploit eller noe sånt, må man laste ned ny kildekode (evt. patche den man har), og rekompilere.

[Varj]

når du sier "bedre fps", så gjetter jeg at du surrer med en eller annen game server, og ja, på versjon 2.4 av linux kjernen var det mye å hente ved å endre på antall hz scheduleren kjørte på, da default var 100.

 

i 2.6 derimot, er default 1000, så her er det ikke noe å hente lenger.

 

da alt er modulært er det eneste du kan tjene litt diskplass og litt minne, i så små mengder at det er ubetydelig på moderne hardware, det er mer aktuelt om du surrer med bittesmå enheter med begrenset hardware.

[olear]

Standard hz i 2.6 er 250.

[TheMaister]

Kompilering av kjerne har da også blitt litt mer komplisert enn det var i "begynnelsen". Ikke veldig, men ting som f.eks å lage en initrd osv var ikke ting jeg trengte å gjøre når jeg surret med Slackware for 10 år siden.

 

Sier ikke at det er spesielt vanskelig, men det er ikke verdt det mtp. den minimale ytelsesøkningen/minnebesparelsen man får, annet enn i helt spesielle tilfeller.

 

En annen ting er at man etter å ha kompilert en kjerne selv, må passe på å oppdatere den selv også. Dvs, skulle det dukke opp en exploit eller noe sånt, må man laste ned ny kildekode (evt. patche den man har), og rekompilere.

 

Å kompilere uten initrd er da mer stress enn med initrd :S Uten initrd må man jo gjøre litt research og finne ut akkurat hvilke sata/ide/filsystem/whatever-moduler man må bygge inn i kjernen for å kunne boote. Man kan jo seff bygge alt mulig som kan krype og gå av unødvendig stuff inn i kjernen for å helgardere seg, men det er jo litt mot sin hensikt. Med initrd er det bare å kompilere alt som kan krype og gå av drivere som moduler og så kjøre mkinitcpio eller tilsvarende Tok litt tid før jeg fikk kernel uten initrd til å boote skikkelig. Merkelige nvidia-hovedkort ...

 

Synes at å kompilere kernel manuelt er litt lurt å kunne. Man vet aldri

 

Forresten, mens det diskuteres Hz. Er det noe ytelse å hente på en ganske rask dual core om jeg skrur opp Hz i kernelconfig fra 300 til 1000, eller blir det bare mer overhead? Om det er 0.01% mer ytelse å hente, så er det fortsatt litt

Endret 28. mai 2009 av TheMaister

[HawP]

Forresten, mens det diskuteres Hz. Er det noe ytelse å hente på en ganske rask dual core om jeg skrur opp Hz i kernelconfig fra 300 til 1000, eller blir det bare mer overhead? Om det er 0.01% mer ytelse å hente, så er det fortsatt litt

Hz har ingenting direkte med hvor raskt programmene kjører. Den "styrer" hvor responsivt systemet er, dvs. hvor ofte kjerna veksler mellom prosesser/tråder/whatever eller "svarer" på interrupt (hvis jeg ikke tar helt feil). Så i visse situasjoner (spesielt på desktop) vil du heller kanskje merke (måle) at én enkelt prosess muligens heller kjører mikroskopisk saktere siden den blir oftere avbrutt dersom "timer frequency" settes til 1000.

 

CONFIG_HZ_300:

 

│ 300 Hz is a good compromise choice allowing server performance │

│ while also showing good interactive responsiveness even │

│ on SMP and NUMA systems and exactly dividing by both PAL and │

│ NTSC frame rates for video and multimedia work.

 

CONFIG_HZ_1000:

 

│ 1000 Hz is the preferred choice for desktop systems and other │

│ systems requiring fast interactive responses to events.

[Sokkalf™]

Å kompilere uten initrd er da mer stress enn med initrd :S

 

Jeg sa for 10 år siden. Såvidt jeg husker var det ikke vanlig (muligens ikke engang mulig) å bruke initrd. Å kompilere kjernen var en veldig enkel prosess (vel, ihvertfall i forhold til kompilering av alt annet, siden man slapp å forholde seg til dependency hell)

[Varj]

Standard hz i 2.6 er 250.

 

det var 1000 når 2.6 kom, men jeg skal ikke uttale meg om hvordan den evt har blitt justert ned i senere tid.

 

uansett er ikke 250 dårlig for gameserver med mindre nettkoden er fryktelig dårlig og alle sitter på supre linjer.

[Sokkalf™]

Et program som liker litt flere ticks/sec er ihvertfall VMWare Server.

På Debian Etch måtte jeg rekompilere kjernen med 1000Hz for at VMware ikke skulle fylle loggene med dritt, og for å få klokkene på guestene til å gå riktig.