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 [EMAIL PROTECTED] die im Body "unsubscribe debian-user-de <deine emailadresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ------------------------------------------------ Anzahl der eingetragenen Mitglieder: 651
