xterm gebruikt (te) veel geheugen

[DeadLock]

Ik heb ongeveer een week of 3 geleden een nieuwe installatie gedaan van gentoo. Dit heb ik toen gedaan om twee redenen: ik wilde weer een 'nette' installatie en ik wilde van x86 naar amd64 overschakelen. Deze installatie is goed gegaan, ik had een backup van alle gegevens en configs en hier heb ik dankbaar gebruik van kunnen maken.

Als window manager gebruik ik dwm icm een groot aantal xterms. Dit is voor mij een erg prettige manier van werken .

Nu zit ik met een vreemd probleem met xterm, deze gebruikt abnormaal veel geheugen:

evert@linux ~ $ ps aux | grep xterm
evert     4843  0.0  4.2 137896 86656 ?        Ss   16:25   0:03 xterm
evert     5233  0.0  2.3  98972 47596 ?        Ss   17:00   0:00 xterm
evert     6005  0.0  1.6  85632 34356 ?        Ss   18:20   0:00 xterm
evert     6012  0.1  1.6  85632 34400 ?        Ss   18:20   0:00 xterm
evert     6734  0.0  0.0   5124   860 pts/2    S+   18:31   0:00 grep --colour=auto xterm
evert@linux ~ $ 

Dit is dus 30 tot 85mb per xterm die er openstaat . Aangezien ik vaak toch wel 20+ xterms heb openstaan gaat dit wel erg hard natuurlijk, het lijkt me dus ook niet helemaal gezond dat ik daarstraks ongeveer een 700mb aan geheugen in gebruik had voor alleen die xterms .

Na wat testen bleek dat wanneer ik xterm zonder mijn config file draai, deze wel maar zo'n 3-5mb ram gebruikt. Hier mijn .Xdefaults:

code:

xterm*metaSendsEscape:  true
xterm*dynamicColors:    true
xterm*background:       black
xterm*foreground:       #fff
xterm*utf8:             2
xterm*eightBitInput:    true
xterm*saveLines:        32767
xterm*scrollTtyKeypress: true
xterm*scrollTtyOutput:  false
xterm*scrollBar:        false
xterm*loginShell:       true
xterm*faceName:         Dejavu Sans Mono:pixelsize=14
xterm*jumpScroll:       true
xterm*multiScroll:      true
xterm*toolBar:          false

Ik heb versie 229 (rare versienummering ?) van xterm geinstalleerd, met de volgende useflags: truetype, unicode.

Ik hoop dat iemand me een stap in de goede richting kan geven om dit probleem op te lossen, ik sta open voor alle suggesties, maar ik ga liefst geen andere term gebruiken zoals urxvt of konsole of wat dan ook.

[Verwijderd]

Is dat niet shared memory?

[DeadLock]

Om even een gedacht te geven:

evert@linux ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          2012        612       1399          0          4        110
-/+ buffers/cache:        496       1515
Swap:         2008          0       2008

Ik open exact 10 xterms en kijk dan nog eens naar het geheugenverbruik met free -m:

evert@linux ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          2012       1090        922          0          5        111
-/+ buffers/cache:        973       1038
Swap:         2008          0       2008
evert@linux ~ $ 

Als ik goed kan tellen is er 480mb (ongeveer) meer gebruikt na het openen van die 10 xterms. Als ik er nog 20 extra open ga ik swappen en wordt alles enorm traag. Dus ik denk niet dat het shared geheugen is.

[ Voor 3% gewijzigd door DeadLock op 19-01-2008 18:50 ]

[Verwijderd]

xterm*saveLines: 32767

stel je hebt een regel van 80 breed

32767 * 80 = 2621360 bytes

Je gebruikt unicode

dus 2 bytes per character

2621360 * 2 = 5242720 bytes

Is 5MB

Hmm dat is het ook niet Tenzij je meer dan 80 tekens per regel hebt of course

[deadinspace]

Verwijderd schreef op zaterdag 19 januari 2008 @ 19:06:
Je gebruikt unicode
dus 2 bytes per character

Het aantal bytes per character hangt voor unicode van de gebruikte encoding af. Het is dus niet noodzakelijk 2 bytes per character (sterker nog: meestal niet).

Ondanks dat is die SaveLines resource een goede eerste verdachte

[phobosdeimos]

Gebruik urxvt.
Ongeveer de beste terminal (ik heb ze allemaal gehad: aterm, Eterm, rxvt, xterm, gnome-terminal) en hij heeft een daemon-client functie, waardoor je één daemon opstart, en alle andere shells zijn dan clients, op die manier wordt een groot deel van het geheugen bespaard, en kost elke bijkomende client-terminal maar een honderdtal kilobytes.
Sterk aan te raden.
Zit standaard in debian.

[ Voor 6% gewijzigd door phobosdeimos op 19-01-2008 21:10 ]

[orillion]

Je zit het zelf al te posten. Er wordt ruim 400 mb gebruikt voor buffers. Verder zal het overgrote deel van was ps aux aangeeft virtueel geheugen zijn, dat gebruikt ie niet allemaal. En vergeet niet dat de gedachte van Linux (en Mac OS X) is: Geheugen wat niet in gebruik is, is nutteloos geheugen.

Lees dit eens: http://gentoo-wiki.com/FAQ_Linux_Memory_Management

[DeadLock]

deadinspace schreef op zaterdag 19 januari 2008 @ 20:21:
[...]

Het aantal bytes per character hangt voor unicode van de gebruikte encoding af. Het is dus niet noodzakelijk 2 bytes per character (sterker nog: meestal niet).

Ondanks dat is die SaveLines resource een goede eerste verdachte

De savelines maakt inderdaad een enorm verschil uit. Als ik de savelines optie helemaal weghaal kost een nieuwe xterm maar zo'n 6-8mb aan ram. Ik snap wel niet helemaal goed waardoor het hierdoor direct in het begin zo oploopt ? Bij een nieuwe lege term heeft hij toch nog niets gesaved wat ram verbruikt ? Of gaat hij al op voorhand al dat geheugen alloceren ?

phobosdeimos schreef op zaterdag 19 januari 2008 @ 21:06:
Gebruik urxvt.
Ongeveer de beste terminal (ik heb ze allemaal gehad: aterm, Eterm, rxvt, xterm, gnome-terminal) en hij heeft een daemon-client functie, waardoor je één daemon opstart, en alle andere shells zijn dan clients, op die manier wordt een groot deel van het geheugen bespaard, en kost elke bijkomende client-terminal maar een honderdtal kilobytes.
Sterk aan te raden.
Zit standaard in debian.

Ik heb vroeger voor een aantal weken (u)rxvt gebruikt, maar ik had toen enkele vreemde problemen ermee (als ik me niet vergis heb ik er zelfs een topic over gemaakt hier op GoT). Tenzij het écht niet anders kan vermijd ik rxvt liever. Misschien zal ik er in de toekomst nog eens naar kijken .

orillion schreef op zaterdag 19 januari 2008 @ 21:19:
Je zit het zelf al te posten. Er wordt ruim 400 mb gebruikt voor buffers. Verder zal het overgrote deel van was ps aux aangeeft virtueel geheugen zijn, dat gebruikt ie niet allemaal. En vergeet niet dat de gedachte van Linux (en Mac OS X) is: Geheugen wat niet in gebruik is, is nutteloos geheugen.

Lees dit eens: http://gentoo-wiki.com/FAQ_Linux_Memory_Management

Ik ben geen linux guru, maar ik weet wel ongeveer hoe linux omgaat met het geheugen. Het artikel had me relatief weinig nieuws te vertellen dus. Ik heb het artikel even helemaal gelezen en daaruit blijkt dat mijn conclusies toch wél juist zijn ? Ik kijk naar deze lijn: "-/+ buffers/cache: ". Dit is dus het geheugen wat in gebruik is zonder caching.


De saveLines is dus de grootste boosdoener, al is het wel vreemd dat ik daar vroeger nooit last van gehad heb. Toen had ik die optie ook aanstaan en toch een laag geheugengebruik . Probleem lijkt dus opgelost, bedankt voor alle antwoorden.

[orillion]

evert_ schreef op zaterdag 19 januari 2008 @ 21:36:
[...]


De savelines maakt inderdaad een enorm verschil uit. Als ik de savelines optie helemaal weghaal kost een nieuwe xterm maar zo'n 6-8mb aan ram. Ik snap wel niet helemaal goed waardoor het hierdoor direct in het begin zo oploopt ? Bij een nieuwe lege term heeft hij toch nog niets gesaved wat ram verbruikt ? Of gaat hij al op voorhand al dat geheugen alloceren ?


[...]


Ik heb vroeger voor een aantal weken (u)rxvt gebruikt, maar ik had toen enkele vreemde problemen ermee (als ik me niet vergis heb ik er zelfs een topic over gemaakt hier op GoT). Tenzij het écht niet anders kan vermijd ik rxvt liever. Misschien zal ik er in de toekomst nog eens naar kijken .


[...]


Ik ben geen linux guru, maar ik weet wel ongeveer hoe linux omgaat met het geheugen. Het artikel had me relatief weinig nieuws te vertellen dus. Ik heb het artikel even helemaal gelezen en daaruit blijkt dat mijn conclusies toch wél juist zijn ? Ik kijk naar deze lijn: "-/+ buffers/cache: ". Dit is dus het geheugen wat in gebruik is zonder caching.


De saveLines is dus de grootste boosdoener, al is het wel vreemd dat ik daar vroeger nooit last van gehad heb. Toen had ik die optie ook aanstaan en toch een laag geheugengebruik . Probleem lijkt dus opgelost, bedankt voor alle antwoorden.

Je hebt het artikel toch niet helemaal goed gelezen, want die regel waar naar jij kijkt zijn juist de buffers. Dat is dus geheugen was ook direct vrijgegeven kan worden en gebruikt kan worden voor een ander programma.

[deadinspace]

orillion schreef op zaterdag 19 januari 2008 @ 21:19:
Je zit het zelf al te posten. Er wordt ruim 400 mb gebruikt voor buffers.

Ik tel anders maar zo'n 115 MB voor cache en buffers in zijn free output
En als je kijkt naar het verschil tussen die twee outputs, dan zie je dat er eerst 496 MB geheugen in gebruik is (exclusief buffers en cache), en daarna 973. Dat is dus een toename van 480 MB in niet-buffer en niet-cache geheugengebruik.

Verder zal het overgrote deel van was ps aux aangeeft virtueel geheugen zijn, dat gebruikt ie niet allemaal.

evert_ heeft het over "30 tot 85mb". Als je naar zijn ps output kijkt, dan heeft hij het dus over de zesde kolom. Die kolom is RSS, en dat is dus de hoeveelheid geheugen van dat proces dat in het fysieke geheugen aanwezig is. Niet virtueel dus.

Met andere woorden: evert_ leest de output van ps en free wel goed

[laurencevde]

'k heb het hier ook maar eens uitgeprobeerd. xterm met standaard hoeveelheid savelines gebruikt 4,200MB geheugen, met 32767sl's is het 30,4MB.
Maar ik gebruik de KDE4-Konsole, en die maakt het niet uit hoeveel scrollback-lijntjes er ingesteld zijn, of hoeveel tabs ie open heeft. Hij verbruikt altijd 22MB. En met KDE4 heeft hij ook nog eens een split-view.

[Olaf van der Spek]

Verwijderd schreef op zaterdag 19 januari 2008 @ 19:06:
Je gebruikt unicode

dus 2 bytes per character

2621360 * 2 = 5242720 bytes

Is 5MB

Hmm dat is het ook niet Tenzij je meer dan 80 tekens per regel hebt of course

Meer dan 80 tekens lijkt me heel aannemelijk. Verder heb je 4 bytes per teken nodig (UTF32). Ook moet je per teken voorgrond-, achtergrondkleur en nog wat attributen opslaan.

[Rainmaker]

Toch vreemd. Op een "standaard" Gentoo instalatie (nooit iets veranderd aan de config van xterm) heb ik dit probleem niet.

Is wel al een oude instalatie (3 jaar), maar zou niet uit mogen maken...

Zonder Xterm

code:

Medusa ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          3959       3814        144          0        424       2580
-/+ buffers/cache:        809       3149
Swap:          478          0        478

Met 5 xterms:

code:

Medusa ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          3959       3829        129          0        424       2583
-/+ buffers/cache:        822       3137
Swap:          478          0        478

Met 5 keer gnome-terminal open:

code:

Medusa ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          3959       3831        127          0        427       2581
-/+ buffers/cache:        822       3136
Swap:          478          0        478
Medusa ~ $

[Ivo]

Is het mogelijk dat xterm statisch gelinkt is en veel libs telkens meesleurt het geheugen in?

[ Voor 6% gewijzigd door Ivo op 22-01-2008 01:11 ]

[Olaf van der Spek]

Ivo schreef op dinsdag 22 januari 2008 @ 01:10:
Is het mogelijk dat xterm statisch gelinkt is en veel libs telkens meesleurt het geheugen in?

Dat geheugen wordt gewoon gedeeld met alle andere xterms.