Łukasz Andrzejak wrote:
On 1/4/07, *andy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Łukasz Andrzejak wrote:
Hi,
On 1/4/07, *Kumar Appaiah* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
A couple of my friends who were using Sarge, on machines with
128 MB
of RAM and 256 MB of RAM have complained that an upgrade from
Sarge to
Etch has slowed their machine down considerably. This is
irrespective
of the Window Manager. Is there any particular reason why
this could
I havent noticed any 'slow down' myself.
Sadly, you failed to say what window manager/de you are using on
this box.
If its a DE, you could try something lighter, or as others have
pointed out - try to find the app thats hogging the memory.
Also - please note that slowing a machine down can mean lots of
things, from not enough ram, to more read/writes to disk and not
enough cpu power.
Most of these things can be checked with the tools mentioned in
this thread, but im not exactly sure how to pinpoint a read/write
culprit.
To add something actually usefull - i reccomend htop (a better
top) and xrestop (checks running apps for memory footprint
x-resource wise) to check what takes the most resources.
Both are somewhere in the repo's (htops is a standalone package,
not sure about xrestop - its been ages since i installed it).
If your using a DE - maybe try using a simple windowmanager, and
just compare.
Ive found that most people acutally dont use half the features of
KDE/GNOME and something along the lines of fluxbox or fvwm is
sufficient.
As a sidenote and personall preference - i always compile my own
kernel with make-kpkg and im rarely troubled by the kernel
problems that my friends mention.
--
Pozdrawiam
Łukasz Andrzejak
Thanks Lukasz - the reference to htop and xrestop was useful. I've
installed them and will monitor them over time to discern a pattern.
I must put my hand up: I am running the vanilla Gnome DE and there
are probably loads of services that I don't need and several I
don't want. Ordinarily I would run XFce but wanted to play in
Candy Land for a while with an all singing, all dancing, bells and
whistles, bloated DE. Also, I got lazy and fed up with configuring
the XFce menus on Etch in the way I used to use them on Slackware.
Methinks I will need to beef up on Gnome and the services it runs
by default, what they do, and how to turn them off or configure
them. If anyone has any specific recommendations that would be
useful, but in the meantime I'll rummage in the on-line Gnome
help/info files.
As an aside, having just double checked, I am supposed to be
running 1GB of RAM but it is only showing a total of 758MB. Is
this typical rounding off and 1GB is in reality only 758MB, or is
it typical for the full amount not to be shown? Seems like missing
250MB of RAM is a fair chunk to not show up. What gives?
a fair chunk ? Thats exactly the amount i have. Total :D
Im running a amd XP2000 with 256 megs of ram with etch, along with a
2.6.19.1 <http://2.6.19.1> kernel (i like to tinker) and im getting no
slowdowns.
On the other hand - i often see swap, but thats what happens when you
do code that processess hundred-meg databases with php. I have a
healthy 4 gigs of it reserved (heck - with a 250gig drive, why not ?).
About the missing 250megs of ram...
Maybe you have an integrated card ?
Maybe you have ramdisks created on boot ? (its a debian kernel thing i
think - ive seen this before - compile your own kernel and it will go
away, or maybe add some boot params for the kernel).
The amount of physicall ram is inside proc/meminfo iirc, maybe youl
get a 'true' read from there (and maybe thats where 'free' gets its
info from and its biased too, dunno).
Maybe check syslog/kern.log/dmesg ?
--
Pozdrawiam
Łukasz Andrzejak
Hmmm ... relevant bits of dmesg:
0MB HIGHMEM available.
767MB LOWMEM available.
Memory: 771640k/786240k available (1543k kernel code, 14044k reserved,
574k data, 196k init, 0k highmem)
Yep - looks like that RAM has been sliced off somewhere.
And now kernel.log
0MB HIGHMEM available.
895MB LOWMEM available.
Memory: 901688k/917312k available (1543k kernel code, 15068k reserved,
574k data, 196k init, 0k highmem)
Seems inconsistent.
Hmmm the plot thickens. Any ideas anyone?
