[Debian]: Performance Probleme.
Hi,
entschuldigung, dies wird etwas länger werden, ist nicht
Debian-spezifisch und wahrscheinlich für die Masse der Leser ohne
jede Relevanz.
da ich mir demnächst einen neuen (schnelleren) Rechner mit mehr
Hauptspeicher (128MB) zulege und damit für mich privat das Problem
umgangen habe, wollte ich jedoch noch einmal die Meinung anderer
dazu hören - bevorzugt von Leuten, die an der Entwicklung des Linux
Kernels befasst oder zumindest interresiert sind.
System: Pentium 100, 40MB RAM
Debian 2.0 (Hamm) Kernel-Version 2.0.34
Story: ich fahre auf meinem Rechner ein selbst geschriebenes Programm,
das versucht, eine vorgegebene Strategie durch Modifizierung von
Startparametern zu optimieren. d.h. mein Rechner läuft 24 Std am Tag
mit diesem Programm im Background, idealerweise mit 100%
CPU-Auslastung.
Nun bemerkte ich irgendwann, es gab Performance-Probleme, vorwiegend
beim Arbeiten mit Netscape oder XEmacs. Angezeigt wurden sie
zusätzlich durch die Lampe, die HD-Aktivitäten anzeigt. ein check mit
Top ergab das plötzlich Idle-times von 20 - 80 % der CPU-Aktivität
verschlangen. Als in der Folge einmal mein Cron-Job (fetchmail)
mehrere Timeouts bekam, gab das bei mir Alarm.
Ein Check mit der Lupe bei meinem Programm (ich vermutete eventuelle
Speicherplatzprobleme - z. B.: malloc ohne free-) blieb ohne
Ergebniss.
Also nahm ich mir als nächstes die Angaben vo Top genauer unter die
Lupe. Hier stellte ich zunächst fest, das seltsamerweise oft (meistens
bis immer) ein Gebrauch von Swap-Space angezeigt wird, selbst wenn
mittlerweile ein vielfaches an freiem RAM verfügbar ist. Obwohl dies
von meiner Logik her die Performance reduziert (zusätzliche Swap-
Verwaltung + zusätzliche IO-Belastung) stellte sich schnell heraus,
das dies nicht ursächlich für meine Probleme war.
Genaue Beobachtungen führten zu folgenden Erkenntnissen:
1. Die Performanceprobleme tauchten immer dann auf, wenn oder nachdem
ich ein Programm benutzt hatte, das einen gewissen Ruf als
RAM-Fresser hatte (Netscape, XEmacs, Gimp etc.).
2. Top zeigte in allen Fällen dann
a: exorbitante Idle-times
b: relativ niedrige Werte für benutztes Buff-Memory
c: relativ hohe Werte für benutztes Cache-Memory
d: nahezu ununterbrochene Aktivität von kflashd bzw. update
3. Meine HD war fast permanent aktiv.
4. Am nächsten Morgen lief das System allerdings wieder rund,
da scheinbar einige der Jobs aus Cron-daily dafür gesorgt hatten,
dass wieder genügend Buff-Memory zur Verfügung stand.
Daraus entstand mein derzeitiger Workaround - wiederholtes Aufrufen
von lynx oder mutt - (gibt jedesmal 10 - 200K mehr Buff-Memory) bis
sich kflushd bzw. update wieder in den Background verziehen.
Dies motivierte mich, etwas über den Kernel in Erfahrung zu bringen,
und so las ich The Linux Kernel (LDP Linux Documentation Project).
Hier erfuhr ich, das kflashd und update jeweils ein Programm aufrufen
- bdflush - welches für die konsistenz der Daten auf HD und Memory
sorgen soll. Hier las ich jedoch, das der Aufruf von eine Prozentsatz
(60%) an dirty-ram gekoppelt ist.
Nun, meine Erfahrungen lassen mich glauben, das hier vielleicht etwas
nacharbeit von Nöten ist. Denn die geschilderten Probleme sind auch
dann präsent, wenn nur (?) mein oben erwähntes Programm aktiv ist,
und ich weiss, das dessen 480K an update-fähigen daten keine 60% von
3500K Buff ausmachen können.
Wie zu Anfang gesagt, mit meiner neuen Maschine kann ich die Probleme
wohl vergessen, dennoch glaube ich, das andere möglicherweise ähnliche
Probleme haben könnten (z. B.: Performance-Probleme bei
master.debian.org in debian-devel vor drei monaten), daher bitte ich
um Antwort, insbesondere von Leuten, die wissen, ob dies als Problem
bekannt, in Arbeit oder gar bereits gelöst ist.
What to do?
Helmut
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 651
Reply to: