Regressions- und Performance-Tests
Regressionstests werden benutzt, um zu testen, ob ein bestimmter
Teil des Systems wie erwartet funktioniert und um sicherzustellen,
dass alte Bugs nicht wieder eingebaut wurden.
Die &os; Regressionstest-Werkzeuge finden Sie im
&os;-Quelltextbaum im Verzeichnis src/tools/regression.
Mikro-Benchmark-Checkliste
Dieser Abschnitt enhält Tipps, wie man angemessenes
Mikro-Benchmarking auf &os; oder von Teilen von &os; selbst
machen kann.
Es ist nicht möglich, jedes einzelne Mal alle der folgenden
Vorschläge anzuwenden, aber je mehr davon benutzt werden,
desto besser wird der Benchmark kleine Unterschiede nachweisen
können.
Schalten Sie APM und alles andere,
das den Systemtakt manipuliert, ab (ACPI ?).
Benutzen Sie den Single-User Modus. &man.cron.8; z.B. und
andere Systemdienste fügen nur Störungen hinzu.
Der &man.sshd.8;
Systemdienst kann ebenfalls Probleme verursachen. Falls während
des Tests ssh-Zugriff benötigt wird, schalten Sie entweder die
Neuerstellung des SSHv1 Schlüssels ab, oder beenden Sie den
sshd-Elternprozess während der Tests.
Lassen Sie &man.ntpd.8; nicht laufen.
Falls &man.syslog.3;-Ereignisse erzeugt werden, starten Sie
&man.syslogd.8; mit leerer
/etc/syslogd.conf, ansonsten lassen Sie
es nicht laufen.
Sorgen Sie für möglichst wenig Disk-I/O; falls
möglich vermeiden Sie sie ganz.
Hängen Sie keine Dateisysteme ein, die Sie nicht
benötigen.
Hängen Sie /, /usr,
und jedes andere Dateisystem als nur lesbar ein, wenn möglich.
Dies verhindert, dass atime-Aktualisierungen auf Disk (usw.) das Ergebnis
verfälschen.
Reinitialisieren Sie das beschreibbare Test-Dateisystem mit
&man.newfs.8; und füllen Sie es aus einer &man.tar.1;- oder
&man.dump.8;-Datei vor jedem Lauf. Hängen Sie es aus
und wieder ein, bevor Sie den Test starten. Dies sorgt für einen
konsistenten Dateisystemaufbau. Bei einem worldstone
-Test
bezieht sich dies auf /usr/obj
(Reinitialisieren Sie es einfach mit newfs und
hängen Sie es ein). Um 100% reproduzierbare Ergebnisse
zu bekommen, füllen Sie das Dateisystem aus einer
&man.dd.1;-Datei (also mit so etwas wie: dd
if=myimage of=/dev/ad0s1h
bs=1m).
Benutzen Sie malloc-gestützte oder preload-ed &man.md.4;
Partitionen.
Machen Sie einen Neustart zwischen den einzelnen Iterationen
des Tests, dies ergibt einen konsistenteren Zustand.
Entfernen Sie alle nicht unbedingt nötigen
Gerätetreiber aus dem Kernel.
Wenn z.B. USB für den Test nicht benötigt wird,
entfernen Sie USB aus dem Kernel. Gerätetreiber,
die sich einhängen, haben oft tickende
Timeouts.
Konfigurieren Sie Hardware aus
, die
nicht benutzt wird. Entfernen Sie Disks
mit &man.atacontrol.8; und &man.camcontrol.8;, wenn die
Disks für den Test nicht benutzt werden.
Konfigurieren Sie nicht das Netzwerk, es sei denn es wird
getestet, oder warten Sie bis der Test fertig ist, wenn Sie
das Ergebnis zu einem anderen Rechner übertragen wollen.
Falls das System an ein öffentliches Netzwerk angeschlossen
sein muss, achten Sie auf Spitzen von Broadcast-Traffic.
Obwohl dieser kaum auffällt, wird er CPU Zyklen brauchen.
Ähnliches gilt für Multicast.
Legen Sie jedes Dateisystem auf seine eigene Disk. Dies
minimiert Jitter durch Optimierungen von Lesekopfbewegungen.
Minimieren Sie Ausgaben auf serielle or VGA-Konsolen.
Ausgaben in Dateien umgeleitet ergeben weniger Jitter
(Serielle Konsolen werden leicht zum Flaschenhals).
Benutzen Sie die Tastatur nicht während der Test läuft,
sogar space oder
back-space erscheint in den Ergebnissen.
Stellen Sie sicher, dass der Test lang genug läuft,
aber nicht zu lange. Wenn er zu kurz ist, ist
Timestamping ein Problem. Wenn er zu lang ist, werden
Temperaturänderungen und Drift die Frequenz von Quarzkristallen
im Rechner beeinflussen. Daumenregel: mehr als eine Minute,
weniger als eine Stunde.
Versuchen Sie, die Temparatur in der Umgebung des Rechners
so stabil wie möglich zu halten. Dies betrifft sowohl
Quarzkristalle als auch Disk-Laufwerks-Algorithmen.
Um wirklich stabilen Takt zu bekommen wäre es auch möglich,
einen stabilisierten Takt anzuschliessen. D.h., besorgen Sie
sich einen OCXO + PLL und koppeln Sie das Ausgangssignal in
die Taktgeberschaltkreise anstelle des Quarzkristalls
der Systemplatine an. Wenden Sie sich an &a.phk; wenn Sie mehr
Informationen hierüber benötigen.
Lassen Sie den Test mindestens drei Mal laufen, aber es
ist besser ihn mehr als 20 Mal laufen zu lassen, sowohl für
den vorher
als auch für den
nachher
Code. Versuchen Sie abzuwechseln
(d.h. nicht erst 20 Mal vorher
und
dann 20 Mal nachher
), dies ermöglicht es
umgebungsbedingte Effekte zu erkennen. Wechseln Sie nicht
1:1 ab, sondern 3:3; dies ermöglicht, Wechselwirkungseffekte
zu erkennen.
Ein gutes Muster ist: bababa{bbbaaa}*.
Dies gibt Hinweise nach den ersten 1+1 Läufen (sodass Sie
den Test stoppen können, falls er völlig danebengeht), und
Sie können die Standardabweichung nach den ersten 3+3
Läufen überprüfen (zeigt an,
ob sich ein längerer Lauf lohnt), und das ergibt später
Werte über Trends und Wechselwirkungenn.
Benutzen Sie usr/src/tools/tools/ministat
um festzustellen, ob Ihre Ergebnisse signifikant sind.
Überlegen Sie sich das Buch
Cartoon guide to statistics
ISBN:
0062731025 zu kaufen. Es ist sehr empfehlenswert,falls Sie Dinge
wie Standardabweichung und Studentsche t-Verteilung vergessen
oder nie gelernt haben.
Benutzen Sie keinen Background &man.fsck.8;, wenn Sie nicht
Background fsck selbst testen wollen. Schalten
Sie auch background_fsck in
/etc/rc.conf aus, es sei denn der Benchmark
wird nicht mindestens 60+Laufzeit von
fsck
Sekunden nach Systemstart
gestartet, da &man.rc.8; aufwacht und
prüft, ob fsck auf irgendeinem
der Dateisysteme
laufen muss, wenn Background fsck eingeschaltet
ist. Stellen Sie ebenfalls sicher, dass keine Snapshots
herumliegen, falls der Benchmark nicht ein Test mit
Snapshots ist.
Falls der Benchmark unerwartet schlechte Performance zeigt,
überprüfen Sie Dinge wie große Mengen Interrupts
von unerwarteten Quellen. Es gibt Berichte, dass einige
ACPI-Versionen sich
daneben benehmen
und ein Übermaß an
Interrupts erzeugen. Um zu helfen, ungewöhnliche Testergebnisse
zu diagnostizieren, machen Sie ein Paar Momentaufnahmen von
vmstat -i und suchen Sie nach
Ungewöhnlichem.
Achten Sie auf Parameter für Optimierungen für
Kernel und Userland, desgleichen für Debugging.
Es ist einfach, irgendetwas
durchrutschen zu lassen und dann später festzustellen, dass
der Test nicht das Gleiche verglichen hat.
Benchmarken Sie nie mit den Kerneloptions
WITNESS and INVARIANTS
eingeschaltet, wenn der Test nicht diese
Merkmale selbst benchmarken soll. WITNESS kann
400% und mehr Abnahme von Performance erzeugen. Ähnliches gilt
für Userland &man.malloc.3;-Parameter, Voreinstellungen
hierbei bei -CURRENT unterscheiden sich von denen bei
Production-Releases.