Tuning

• * Vorüberlegungen
• * Prozesse / CPU
• * Festplatten
• * Paging und Swapping
• * Dateisystem
• * Anwendungen

* Vorüberlegungen (Index)

Eine wichtige Voraussetzung zum Optimieren eines Rechners ist das Festlegen
des Verwendungszwecks, denn zwischen Proxy-Server, Grafikworkstation, Router oder
"normaler Allrounder" liegen Welten. Ein weiteres Kriterium ist damit natürlich
die Hardware, denn ein Server sollte kurze Antwortzeiten und eine schnelle
Festplatte haben, während eine Rendermachine eher hohen Durchsatz und viel RAM benötigt.
Ein wichtige Tatsache, die während der Installation festgelegt wird, ist die
Speicherung der Daten, da sonst unnützes Suchen wertvolle Zeit kostet. Um dies zu
vermindern bietet es sich an logische Datenblöcke auch physisch nahe beieinander
in Partitionen zu speichern und SoftUpdates unter *BSD einzusetzen. Ebenso kann man eine Partition auch mit der Option noatime mounten um ein aktualisieren der Accesstime abzuschalten, dies ist z.B. auf einem FTP Server recht nützlich.

* Prozesse / CPU (Index)

iostat
gibt eine Übersicht über I/O Aktivität aus

slick@AragornOfArathorn: $ iostat
      tty            wd0             cd0             cd1             fd0             cpu
 tin tout  KB/t t/s MB/s   KB/t t/s MB/s   KB/t t/s MB/s   KB/t t/s MB/s  us ni sy in id
   4   66  7.54  12 0.09   0.00   0 0.00   0.00   0 0.00   0.00   0 0.00   8  0  0  0 91

Interessant sind hier neben den Staistiken zu den Massenspeichern vor allem die
Daten unter cpu.
us Zeit (in %) die die CPU Userprozesse in normaler/hoher Priorität bearbeitet
ni Zeit (in %) die die CPU Userprozesse in niedriger (nice) Priorität bearbeitet
sy Zeit die für das System verwendet wurde (Kernelcode, Systemaufrufe ...)
id Leerlauf der CPU

Dies gibt einen guten Ansatz umd die Last zu beurteilen:

• Ist die CPU ausgelastet?
• Ist die CPU viel im Leerlauf?
• Ist der Datendurchsatz gering/hoch?
• Bremsen die Platten die CPU oder umgekehrt?

Gibt es z.B. viele Zugriffe aber wenig Datenvolumen sollte man das I/O System
überprüfen, ob z.B. DMA deaktiviert, das Dateisystem nicht optimiert ist, Festplatten
zu langsam etc.

ps und pstree
ps zeigt die laufenden Prozesse mit PID, Status und Zeit an.
pstree visualisiert die Prozesse als Baum und stellt somit ABhängigkeiten sehr gut dar.

systat
systat zeigt die Last in einem Diagramm an.

fstat
fstat gibt eine Übersicht über offene Dateien aus, läßt somit Rückschlüsse
auf den Systemzustand und laufende Prozesse schließen.

Prozessorpriorität
Die Prozessorpriorität kan mittels nice/renice bestimmt werden.
Unix besitzt seit geraumer Zeit Prioritäten für Prozesse (nice erschien erstmalig in 6 AT&T)
welche die Zuweisung von Prozessorzeit beeinflussen. Hierbei bedeutet eine hohe
nice-Priorität eine geringere Zeitzuweisung und beeinflusst somit insbesondere
CPU-lastige Prozesse wie z. B. Compilerläufe, renice ermöglicht unter BSD die
Prioritätenänderung von laufenden Prozessen.

Ausnutzen von Randzeiten
Mittels cron oder at kann man Aufgaben zu bestimmten Zeiten ausführen lassen,
so kann man Backups oder Updates nachts oder am Wochenende anlaufen lassen.
Zusätzlich kann man Programme via batch laufenlassen (batch ist auch als gute
alte Stapelverarbeitung bekannt), da batch die angegebenen Programme erst startet wenn das Loadlevel unter den angegebenen Wert sinkt.

* Festplatten (Index)

Eine gute Möglichkeit die Leistung des Rechners zu verbessern ist das Optimieren
der Festplatte. Dies betrifft aber nur IDE, denn SCSI läßt sich nicht besonders tunen.
In der Regel lässt sich im BIOS der PIO bzw. DMA Modus einstellen. PIO: Programmed Input/Output
der die Daten direkt von der Festplatte an die CPU übergibt, während bei DMA
(Direct Memory Access) die Hardware das liefern der Daten übernimmt und somit die CPU anderes erledigen kann.

* Paging und Swapping (Index)

Swapping ist das Auslagern von kompletten Prozessen auf die Festplatte
um so Hauptspeicher freizubekommen.
Paging ist fast das selbe, hierbei werden allerdings Speicherseiten ausgelagert.
Der Kernel versucht beim Paging möglichst vorausschauend zu arbeiten und oft genutzte
Seiten im RAM zu behalten.
Paging ist in der Regel kein großes Problem, da nach einer Faustregel die meisten Programme
80 % ihrer Laufzeit in 20% des Programmtextes verbringen und somit einige
Speicherseiten problemlos ausgelagert werden können. Ebenfalls werden Prozesse nach 20 Sekunden
als idle eingestuft und werden aus dem RAM geswapt.
Die beste Möglichkeit den swap/paging-Status anzuzeigen ist das Program vmstat.

slick@AragornOfArathorn: $ vmstat
 procs   memory     page                       disks         faults      cpu
 r b w   avm   fre  flt  re  pi   po   fr   sr w0 c0 c1 f0   in   sy  cs us sy id
 1 1 0 89908369576   60   0   0    0    0    0  2  0  0  0  204 1104 195 18  1 81
 

vmstat gibt sehr gute Auskunft über die Seitenauslagerung des Systems.
Beim einfachen Aufruf versucht vmstat Mittelwerte seit Systemstart aufzurufen.
Mensch kann per -c und -w mehrere Ausgaben in einem bestimmten Intervall ausgeben.
Die Ausgabe interpretieren:
procs memory page disks faults cpu r b w avm fre flt re pi po fr sr w0 c0 c1 f0 in sy cs us sy id procs
r : laufende Prozess (enthält schlafende und auf I/O wartende nicht)
b : blockierte Prozesse, die auf I/O oder externe Ereignisse warten
w : augelagerte und lauffähige Prozesse, größer 0 ist sehr schlecht
memory
avm : Größe des belegten virtuellen Speichers
fre : Größe des freien physikalischen Speichers
page
flt : Gesamtseiten die geswapped wurden
re : Seiten die zurückgewonnen wurden
pi : Seiteneinlagerung in kB/sec
po : Seitenauslagerung in kB/sec
fr : Seiten die freigemacht wurden
sr : Seiten die gescannt wurden (je Sekunde)
disks enthält eine Übersicht der Platten und deren Transferrate
faults
in : Deviceinterrupts pro Sekunde
sy : Sytemcalls pro Sekunde
cs : CPU Context-Switch Rate (Context Switch = Umschaltung zw. Prozessen)
cpu
de : geschätzter kurzfristiger Speichermangel, größer 0 = RAM-Mangel
us : CPU-Zeit die im Kernel-Modus verbraucht wird
sy : CPU-Zeit die im Kernel-Modus verbraucht wird
id : CPU-Zeit die im Leerlauf verbracht wird
Am interessantesten sind die Werte in w und po.
Sie indizieren ob Paging und/oder Swapping stattfindet und sind in Verbindung
mit fre sehr nützlich. Paging setzt ein wenn der freie Speicher unter
LOTSFREE sinkt und Desperation Swapping bei unterschreiten von DESFREE.
Die beiden Schwellwerte sind in vmparam.h definiert.

* Dateisystem (Index)

Das Dateisystem läßt sich auch etwas tunen,und zwar mit den mount-Optionen
noatime und nodiratime welche verhindern, daß bei jedem Dateizugriff
die Zugriffszeit im entsprechenden INODE gespeichert wird, und somit den
Dateizugriff wieder beschleunigen.
Besondere Beachtung sollte man den mount-Optionen und unter *BSD insbesondere den SoftUpdates schenken. Interessant ist hier u.a. noatime, das das Updaten der AccessTime bei Zugriff auf eine Datei verhindert und softdep, das besagte SoftUpdates aktiviert. Hierzu eine kleine Benchmark auf einem P3-500, 256MB RAM 8GB ATA66 IBM IDE Platte,
es wurde pkgsrc.tar.gz (24MB Groß, enthielt 76693 Dateien) mit tar -xzf entpackt.

Zeitaufwand entpacken normal	824,61	9,83u	43,36s
mit softdep,nocoredump,noatime	268,56	9,82u	31,09s
löschen (rm -rf) normal	625,82	0,82u	12,77s
löschen (rm -rf) getuned	99,49	0,75u	4,64s

* Anwendungen (Index)

Oft erhält man Anwendungen neben den Quellen auch als Binary. Es kann sich schon
lohnen die Quellen zu beschaffen und diese auf der eigenen Maschine zu kompilieren,
denn dann kann man davon ausgehen daß das Programm für den eigenen Prozessor
optimiert wird, und nicht für den des Entwicklers.
Ebenso gibt es ein Compilersuite die von Intel gepowert wird und dementsprechend
natürlich auf Intel CPUs schneller läuft.
Module/Dienste
So wurde unter anderem in der iX 09/01 getestet, das der gcc 3 zwar länger compiliert
als der Vorgänger, dafür laufen aber die neucompilierten Programme schneller.
Natürlich ist es ebenfalls besser alle unbenötigten Module und Daemons rigoros
rauszumschmeißen, und somit Platz und Zeit zu sparen.
Außerdem können nicht existente Programme die Sicherheit nicht gefährden.
Kernel
Ein weiteres wichtiges Kapitel ist der Kernel, welcher als Generic-Kernel der
Distributionen oft unnötig groß ist.
Es empriehlt sich diesen neu zu übersetzen und dabei selbstverständlich alle
unnötigen Quellen rauszuschmeißen, z.B. SCSI oder ISDN wenn das nicht benutzt wird.

\$Id: tuning.html,v 1.33 2014/08/21 09:24:04 stefan Exp $



$Log: tuning.html,v $
Revision 1.33  2014/08/21 09:24:04  stefan
Umlaute und Makefile clean up