hallo liste, hallo matthias ich habe eueren thread erst heute gefunden, hat irgendwer von euch das problem mittlerweile gelöst? bei mir schauts ähnlich aus, keine ahnung warum... habe hier xfree 4.0.3, kde 2.2.2 alpha und kernel 2.4.0 laufen vielen dank im voraus! -- may you always grok in fullness ( http://w3.one.net/~wap/wapGrok.html ) -- from/von/de >mfeilner@f-linux.com< Markus Feilner --------------------------- Linux, Webdesign, Erlangerstr. 2 --------------------------- IT-Consulting 93059 Regensburg ----- 0941/706523--------mobil: 0170/3027092
Am Mittwoch, 20. Juni 2001 20:59 schrieben Sie:
hallo liste, hallo matthias ich habe eueren thread erst heute gefunden, hat irgendwer von euch das problem mittlerweile gelöst? bei mir schauts ähnlich aus, keine ahnung warum... habe hier xfree 4.0.3, kde 2.2.2 alpha und kernel 2.4.0 laufen vielen dank im voraus!
http://www.suse.de/de/linux/linux_faq/26Speicher.html mfg roman
Roman Langolf wrote:
ich habe eueren thread erst heute gefunden, hat irgendwer von euch das problem mittlerweile gelöst?
Nein nein, das hat damit nichts zu tun. Es ist auf meinem System nachweislich so, daß X mit der Zeit den Speicher belegt. Das ist unabhängig von Buffer und Cache. Bitte das ursprüngliche Posting lesen, das bereits vor 2-3 Wochen in die Liste ging. - Matthias
Am Donnerstag 21 Juni 2001 17:54 schrieb Matthias Kleine:
Roman Langolf wrote:
ich habe eueren thread erst heute gefunden, hat irgendwer von euch das problem mittlerweile gelöst?
Nein nein, das hat damit nichts zu tun. Es ist auf meinem System nachweislich so, daß X mit der Zeit den Speicher belegt. Das ist unabhängig von Buffer und Cache. Bitte das ursprüngliche Posting lesen, das bereits vor 2-3 Wochen in die Liste ging.
- Matthias
also ich hab mittlerweile auf Xfree 4.1.0 aufgerüstet, aber nach dem start von kde sagt mir top jetzt immer noch (nach ca 5 min uptime!): 530 root 12 0 57696 46M 2752 S 0.3 37.5 0:41 X der memory amount steigt pro tag ca um 5-6 mb, ohne daß man am rechner arbeitet, sonst wesentlich schneller. auf rechnern in einem system bei kunden hatte ich unter ähnlichen bedingungen gerade mal 12-16 Mb und das konstant. markus -- may you always grok in fullness ( http://w3.one.net/~wap/wapGrok.html ) -- from/von/de >mfeilner@f-linux.com< Markus Feilner --------------------------- Linux, Webdesign, Erlangerstr. 2 --------------------------- IT-Consulting 93059 Regensburg ----- 0941/706523--------mobil: 0170/3027092
Hallo! Am Mittwoch, 20. Juni 2001 20:59 schrieb Markus Feilner:
hallo liste, hallo matthias ich habe eueren thread erst heute gefunden, hat irgendwer von euch das problem mittlerweile gelöst? bei mir schauts ähnlich aus, keine ahnung warum... habe hier xfree 4.0.3, kde 2.2.2 alpha und kernel 2.4.0 laufen vielen dank im voraus!
Also eine Lösung dazu kann ich euch nicht bieten. Aber vielleicht ein paar Vermutungen. Bei mir ist das ähnlich. Auf einem Athlon 800 mit 256MB Speicher brauchte X nach 2 Stunden Arbeit am Rechner ca. 100MB. Nach einem Speicherupgrade auf 512MB braucht es nun plötzlich 220MB(!!) Auszug aus top: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 532 root 16 0 212M 210M 2196 R 0.0 42.0 1:17 X Anscheinend "nimmt" sich X einen gewissen "Anteil" (immer ca 40%) des zur verfügung stehenden Speichers. Komischerweise aber erst nach einiger Zeit, und umso schneller, je mehr Fenster geöffnet und geschlossen werden. (z.B. viele Testläufe beim Programmieren). Dieses Phänomen zeigt sich bei mir seit SuSE7.0 (bzw XFree4.x). Außerdem scheint es unabhängig vom Windowmanager zu sein (gleiches Problem unter KDE, WindowMaker, Gnome/Sawfish). Woran das genau liegt, ob es Bug (Speicherleck) oder Feature(Caching von Grafikdaten, Zwischenspeichern von verdeckten Fenstern.....) ist kann ich leider nicht sagen... Grüße Manfred Gahr
From: "Manfred Gahr"
Also eine Lösung dazu kann ich euch nicht bieten. Aber vielleicht ein paar Vermutungen. Bei mir ist das ähnlich. Auf einem Athlon 800 mit 256MB Speicher brauchte X nach 2 Stunden Arbeit am Rechner ca. 100MB. Nach einem Speicherupgrade auf 512MB braucht es nun plötzlich 220MB(!!) [..] Woran das genau liegt, ob es Bug (Speicherleck) oder Feature(Caching von Grafikdaten, Zwischenspeichern von verdeckten Fenstern.....) ist kann ich leider nicht sagen...
von http://www.linuxpower.org/display.php?id=211 "Keith Packard, in his TinyX server using his new frame buffer code, has reduced the X server to 500-700K bytes of code (depending on whether you want his new render extension for anti-aliased text and graphics). Most of the perception of bloat is caused by how Linux reports memory. An X server maps the display card into its address space, and on current graphics cards this can easily be 8, 16, 32 or even 64 megabytes of address space (for the frame buffer and registers of the display). Naive people look at "ps" or "top" and draw the wrong conclusion. Clients may be asking the X server to preserve pixmaps on their behalf (which should really be charged to the client, but it shows up in the X server). So, for example the RSS size on my iPAQ is 2.2 megabytes when running Familiar, with backing store and save unders still enabled (arguably, on a device like an iPAQ, I should disable them, which would further reduce the RAM footprint)." Alfred
Am Freitag, 22. Juni 2001 13:28 schrieb Alfred Poschmann:
reports memory. An X server maps the display card into its address space, and on current graphics cards this can easily be 8, 16, 32 or even 64 megabytes of address space (for the frame buffer and registers of the display). Naive people look at "ps" or "top" and draw the wrong conclusion. Clients may be asking the X server to preserve pixmaps on their behalf (which should really be charged to the client, but it shows up in the X server). So, for example the
Das klingt alles recht aufschlußreich, aber Fakt ist, daß das fortwährende Allokieren von Speicher bei mir auf Dauer dazu führt, daß Unmengen von Daten in den Swap verlagert werden. Ich habe hier 512 MB RAM mit gleicher Menge Swap im Einsatz. Diese Speichermenge wird teilweise auch in Anspruch genommen. Durch den übermäßigen Speicherhunger von X kommt es jedoch mitunter dazu, daß das System teilweise in die Verlegenheit gerät, Speicher kurzfritig mittels Swapping freischaufeln zu müssen - genau die Art von Verzögerung, die man sich nicht wünscht, wenn man sein System mit reichlich Speicher ausstattet. Das Problem läßt sich (aus Anwendersicht) beheben, indem man die Zahl der freepages freepages unter /proc entsprechend vergrößert, aber das kann man ja nicht als mehr denn einen Workaround bezeichnen. Bis zu 180 MB belegter Speicher, nach dem Beenden aller X-Applikationen (außer WM) lassen sich beim besten Willen nicht durch zusätzliche 64 MB Grafikkartenspeicher, gecachte Bitmaps oder ähnliche Features erklären oder gar rechtfertigen. Ich will allerdings nicht ausschließen, daß anstelle von X der Windowmanager (hier Kwin) der Bösewicht ist, indem er X das Cachen allermöglichen Bilder oder Widgets aufträgt. - Matthias
Am Freitag 22 Juni 2001 23:44 schrieb Matthias Kleine:
Das klingt alles recht aufschlußreich, aber Fakt ist, daß das fortwährende Allokieren von Speicher bei mir auf Dauer dazu führt, daß Unmengen von Daten in den Swap verlagert werden. Ich habe hier 512 MB RAM mit gleicher Menge Swap im Einsatz. Diese Speichermenge wird teilweise auch in Anspruch genommen. Durch den übermäßigen Speicherhunger von X kommt es jedoch mitunter dazu, daß das System teilweise in die Verlegenheit gerät, Speicher kurzfritig mittels Swapping freischaufeln zu müssen - genau die Art von Verzögerung, die man sich nicht wünscht, wenn man sein System mit reichlich Speicher ausstattet.
Das Problem läßt sich (aus Anwendersicht) beheben, indem man die Zahl der freepages freepages unter /proc entsprechend vergrößert, aber das kann man ja nicht als mehr denn einen Workaround bezeichnen. Bis zu 180 MB belegter Speicher, nach dem Beenden aller X-Applikationen (außer WM) lassen sich beim besten Willen nicht durch zusätzliche 64 MB Grafikkartenspeicher, gecachte Bitmaps oder ähnliche Features erklären oder gar rechtfertigen.
Ich will allerdings nicht ausschließen, daß anstelle von X der Windowmanager (hier Kwin) der Bösewicht ist, indem er X das Cachen allermöglichen Bilder oder Widgets aufträgt.
- Matthias
stimmt genau, vor allem wenn man bedenkt, daß auf vergleichbaren systemen der speicherbedarf mittels der ausgabe von den gleichen programmen ps oder top nur ca 12-16mb (sic!!!) beträgt. (siehe meine vorherigen mails) das problem für mich ist: X stirbt regelmäßig nach längerer arbeit mit vielen fenstern ohne vorwarnung, nämlich genau dann (vermutung!) wenn aller möglicher speicher voll ist. das ist wenn man gerade fleissig am arbeiten ist, inakzeptabel. mein system ist jetzt uptime 2:27am up 7:32, 1 user, load average: 0.91, 1.18, 1.16 und da ich (noch) über "nur" 128mb ram (+120mb swap) verfüge, ist folgender speicherverbrauch ebenfalls inakzeptabel: 1837 root 10 0 83988 54M 13912 R 4.3 43.9 17:59 X am gemapten grafikkartenspeicher kanns auch nicht liegen, da ich nur 8mb in meiner grafikkarte habe, oder? und wenn nur der xdm läuft, sinds trotzdem noch 26 mb. und das schlimmste ist: auch wenn ich nicht arbeite, steigt der speicherverbrauch von X pro tag um 5 mb. also kanns eigentlich nicht alleine am öffnen/schliessen von fenstern liegen, oder? ich habe diese beobachtung ebenfalls nach deaktivierung sämtlicher verzierungen an fenstern und wechselnder hintergrundbilder gemacht. dieses verhalten war bei x 4.02, 4.03 und ist bei x 4.1.0 gleich. ich habe auch festgestellt, daß diverse anwendungen (zb. konqueror) den speicherverbrauch von X erhöhen, und nach ihrer beendigung nicht wieder derselbe wert wie vorher erreicht wird, sondern einige 100kb mehr. 2 fragen: 1.) habt ihr ähnliche erfahrungen mit anwendungen gemacht? wenn ja, welche programme waren es? 2.) welchen kernel verwendet ihr? ich verwende 2.4.0 und habe da schon einiges an negativen erfahrungen mitbekommen... kann das der schuldige sein? danke im voraus euer markus -- may you always grok in fullness ( http://w3.one.net/~wap/wapGrok.html ) -- from/von/de >mfeilner@f-linux.com< Markus Feilner --------------------------- Linux, Webdesign, Erlangerstr. 2 --------------------------- IT-Consulting 93059 Regensburg ----- 0941/706523--------mobil: 0170/3027092
participants (6)
-
Alfred Poschmann
-
M.A.N.E@t-online.de
-
Markus Feilner
-
Matthias Kleine
-
Matthias Kleine
-
Roman Langolf