Re: [Debian]: Performance Probleme.
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 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: 653
Reply to: