Re: RELENG_7 - Geschwindigkeit

Heiko Wundram wrote:
> Ich hab seit gestern abend bei mir ein RELENG_7 (sprich, gestern abend, also
> nach der Umbenennung geuppt) System laufen, und beobachte ähnliche Symptome
> wie Peter Ullrich Kruppa in seiner Mail "portupgrade und make brauchen zu
> viel CPU".
>
> Im Endeffekt bemerke ich, sobald bei mir ein Job läuft der viel auf die Platte
> zugreift, eine deutliche Verlangsamung des Gesamtsystems, so dass zum
> Beispiel die Maus unter X hakt, oder Fenster (länger) nicht mehr neu
> gezeichnet werden, u.ä. Ein top zeigt mir an, dass die laufenden Prozesse ca.
> 20% User-Zeit und das System ca. 10% System- und 70% Interrupt-Zeit
> beanspruchen.

70% Interrupt ist sehr viel.

> Am swappen liegt die Interrupt-Zeit definitiv nicht; mein
> System hat 1 GB RAM und gar nichts der 1,5 GB swap in Benutzung.
>
> Ein "vmstat -i" ist etwas ungewöhnlich:
>
> """
> phoenix# vmstat -i
> interrupt total rate
> irq1: atkbd0 3759 0
> irq10: acpi0 1877 0
> irq14: ata0 211276 23
> irq15: ata1 90 0
> irq17: cbb0 cbb1+ 197457 21
> irq19: sis0+ 2 0
> irq20: ohci0 10833 1
> irq21: ohci1 16 0
> irq23: ehci0 1 0
> cpu0: timer 18015081 1999
> Total 18440392 2047
> phoenix#
> """

Das sieht eigentlich vollkommen normal aus für einen Desk-
top-Rechner mit zweieinhalb Stunden Uptime.

Ich vermute, auf irq17 ist neben den Cardbus-Bridges noch
Deine Graphikkarte (»grep "irq 17" /var/run/dmesg.boot«).
Falls Du kein Cardbus brauchst, schmeiß das mal aus Deinem
Kernel raus. Dies könnte den Interrupt-Overhead etwas
reduzieren. Aber das hat nichts mit Festplatten-I/O zu
tun, d.h. mit dem von Dir beobachteten Problem bei Platten-
zugriffen kann es eher nichts zu tun haben. Wie es aus-
sieht, haben ata0 und ata1 jeweils einen Interrupt für
sich.

> Ich habe einen GENERIC-Kernel (ohne Änderungen an dem, was standardmäßig
> eingestellt ist für den RELENG_7 in sys/i386/conf/GENERIC) gebaut, also
> sollte ja eigentlich wohl HZ=1000 eingestellt sein, ich kriege aber 2000
> ticks/s für den Timer?

Das ist 'ne FAQ. Der HZ-Wert und die Timer-Rate haben nur
mittelbar miteinander zu tun, müssen aber nicht identisch
sein. Der Faktor hängt von diversen Dingen ab und wird so
gewählt, dass die Präzision des Timers bestmöglich ausge-
nutzt wird, ohne das unbemerkte Overruns auftreten können.

Wenn Du GENERIC ohne Änderungen verwendest, dann hast Du
ULE als Scheduler. Was WITNESS und INVARIANTS betrifft,
kommt es auf den genauen Zeitpunkt an, zu dem Du gesuppt
hast. Ab rev. 1.474.2.1 sind die aus GENERIC verschwunden.
Ähnliches gilt für src/lib/stdlib/malloc.c rev. 1.147.2.1,
was die malloc-Debug-Optionen betrifft.

> Sonst, wenn das System nicht gerade auf die Platte zugreift, sehe ich
> zumindest gefühlt eine deutliche Verbesserung resp. RELENG_6, da das System
> insgesamt schneller reagiert (was sich besonders beim Starten von
> KDE-Anwendungen bemerkbar macht).
>
> Warum ich selber noch mal schreibe: die entsprechenden Debug-Optionen aus dem
> früheren CURRENT-Zweig sollten ja eigentlich jetzt seit der Umbenennung
> standardmäßig ausgeschaltet sein, oder nicht?

Wie gesagt, es kommt auf den genauen Zeitpunkt an, zu dem
Du gesuppt hast. Die Debug-Sachen wurden ja nicht exakt
zeitgleich mit dem Branch abgeschaltet, sondern gewisse
Zeit später.

> Das System selbst ist ein (alter, also noch nicht zweikerniger) AMD Turion;
> pciconf liefert folgendes:

Interessant wären stattdessen eher noch die dmesg-Ausgaben,
insbesondere Erkennung der Festplatten(-controller).
Evtl. noch ein paar Zeilen von »vmstat 5« und eine Ausgabe
von top.

Du kannst auch mal mit gstat beobachten, wie die Auslastung
der Festplatten so ausschaut.

> Ich weiß, dass ich im Endeffekt selbst schuld bin, wenn ich ein PRERELEASE
> einsetze,

Eigentlich machst Du da nichts falsch. Die PRERELEASE ist
ja gerade zum Testen da, und wenn sich niemand über irgend-
welche Probleme beschwert, dann wird genau dieser Code
später die RELEASE sein. Und wenn Du Dich _dann_ über
Probleme beschwerst (die schon vorher da waren), _dann_
bist Du selbst schuld.

> aber vielleicht hat ja jemand ähnliche Erfahrungen mit RELENG_7
> gemacht, und kann mir sagen, wo ich noch ein bissel schrauben
> kann/könnte. ;-)

Als erstes könntest Du mal versuchen, den ULE-Scheduler zu
verwenden. Eigentlich (nach bisherigen Erfahrungen) macht
er auf UP-Systemen keinen nennenswerten Unterschied, aber
einen Versuch ist es trotzdem wert.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"C++ is over-complicated nonsense. And Bjorn Shoestrap's book
a danger to public health. I tried reading it once, I was in
recovery for months."
        -- Cliff Sarginson
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message