Re: Pakete, die wesentlich bremsen, finden
Also sprach Peer Oliver Schmidt <pos@theinternet.de> (Thu, 09 Feb 2006
19:43:09 +0100):
> Al Bogner schrieb:
> > Am Donnerstag, 9. Februar 2006 17:36 schrieb Evgeni Golov:
> >>On Thu, 9 Feb 2006 17:25:12 +0100 Al Bogner
> >><debian@ml061.pinguin.uni.cc> wrote:
> >>
> >>>Ich habe alle Pakete eines schnellen Rechners auf einem langsamen
> >>>installiert und bin nun auf der Suche, was das System _wesentlich_
> >>>bremst, speziell das Hochfahren verlangsamt.
> >>>Wie analysiere ich das am besten? Aus den u.a. Logs sehe ich
> >nichts, >>das überflüssig ist.
> >>
> >>Danke für das log, aber schau dir doch mal bootchart an, das malt
> >>hybsche Bildchen von deinem Bootvorgang.
> >
> >
> > Dann interpretiere bitte mal:
> > http://members.inode.at/pinguin/bootchart.png
>
> Hast Du bei dem Suse Rechner auch alles als Module? Mir ist
> aufgefallen, dass das Laden der Module ewig und vier Tage dauert,
> oder habe ich da etwas falsch interpretiert?
[Boot] Vielleicht zeigt dir CONFIG_PRINTK_TIME wo es lange braucht. Ich
vermute eher auch, dass das Erkennen der Hardware und laden der Module
recht lange benoetigt. Sowas sollte aber beim Booten auf der Console
in Echtzeit augenscheinlich werden. Verwende keine graphischen
Bootzeugs, die erschweren das Debugging und verlangsamen das Ganze nur.
I.d.R. ist ein langsameres System [Laufzeit] vom Kernel und den
verwendeten Apps abhaengig. Generell ist aber zu sagen, dass sich
Distributation schon alleine durch die verwendeten Versionen und
compilieroptionen stark unterscheiden koennen. Daneben sind Dinge wie
GCC und distributationsspezifische Kernel und allgemeine
Grundeinstellungen
relevant.
Wenn das System das Gleiche, nur auf einem langsameren Rechner ist, ist
klar dass es nicht so rauschen wird.
Herausbekommen was bremst:
Ich wuerde dir empfehlen beide Systeme einigen Benchmarks zu
unterziehen, essentiell um Bottlenecks schneller und einfacher finden.
U.a. lmbench ist da hervorragend geeignet, Einzeltest wie
dd/tiobench/bonnie fuer's Filesystem/Netzwerk und diverse
cpu- und memory-hog Programme mit time mitstoppen sollten das Problem
auch aufzeigen. Dann noch applikationsspezifische Benchmarks nutzen,
falls du es schon soweit eingeengt hast. Daten vergleichen und schon ist
mensch dem Problem einen grossen Schritt naeher gekommen.
Btw. Lmbench musste ich in Etch selber bauen da das .deb nicht wollte.
Ich installier' auf Servern noch acct (braucht CONFIG_BSD_PROCESS_ACCT
gesetzt) um mit "sa" Einblick zu bekommen was langfristig wieviel
arbeitet.
sl ritch
Reply to: