Helmut Metzdorf wrote: > > Hi, > > entschuldigung, dies wird etwas länger werden, ist nicht > Debian-spezifisch und wahrscheinlich für die Masse der Leser ohne > jede Relevanz. hi ich habe grade Deinen Beitrag mit aufmerksamkeit gelesen.
> > da ich mir demnächst einen neuen (schnelleren) Rechner mit mehr [...] > 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.). meine beobachtungen beschränken sich hier in erster Linie auf netscape und so5, was diese sorte programme angeht. > > 2. Top zeigte in allen Fällen dann > a: exorbitante Idle-times unsere vermutung war, die verbratene performanz spielt sich auf einem derart niedrigen level ab, daß sie von top nicht angezeigt wird. Es scheint hier auch ein bischen mit der rechnerarchitektur zusammen zu hängen. ich fahre hier mit zwei pentium 100 (billig-); 75 (asus-board) das asus läuft obwohl nur eine platte, weniger ram, wesentlich runder als marke billig (zwei PLatten an je einem ide strang, verteilung der Daten und Programme ... viel ram). so das engpässe nicht so ins gewicht fallen und idel-times nicht gegenläufig zur beobachten performanz sind. > b: relativ niedrige Werte für benutztes Buff-Memory > c: relativ hohe Werte für benutztes Cache-Memory richtig, wobei ins besondere so5 erstmal den speicher vollknallt. die modulle könnten ja jetzt gebraucht werden und mit 30mb zuschlägt. nach einer nacht plötzlich auf 10mb zusammengeschrumpft ist und immer nocht funktioniert ohne nachzuladen. selbiges für netscape wobei dieses program nur bei bedarf nachläd, sich aber genauso ungerne von seinem speicher trennt. dies scheint mir bei vielen anderen programen, die einen dynamischen speicherverbrauch haben anderst zu sein. die freigabe erfolgt schneller. was der kernel zwischenlager ist noch mal eine andere geschichte. > 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. hier deinen letzten satz verstehe ich nicht ganz. > What to do? Keine ahnung so etwas muß ich anderen menschen überlassen. -- Grüße Christoph Marcel Hilberg Marburg pgp 16 20 43 2A 20 29 61 7A 6A 49 87 5E 34 77 2E B0 http://www2.crosswinds.net/frankfurt/~room10/ ------------------------------------------------ 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: 653
