[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Slow system
- From: Rick Stevens <rstevens vitalstream com>
- To: Getting started with Red Hat Linux <redhat-install-list redhat com>
- Subject: Re: Slow system
- Date: Tue, 21 Dec 2004 16:40:28 -0800
Carla & Dick Bickert wrote:
Rick Stevens wrote:
Carla & Dick Bickert wrote:
Bob McClure Jr wrote:
On Fri, Dec 17, 2004 at 01:51:09PM -0600, Carla & Dick Bickert wrote:
I have recently installed Red Hat Linux 9. It boots fine and there
appear to be no problems, but the GUI runs EXTREMELY slow
(openoffice takes 3-4 minutes to come up). The computer has a
Celeron processor running at 667 Mhz and the hard drive is plenty
big. Any suggestions?
Thanks
Dick
Post the results of running "free". That may well tell the story.
Cheers,
The results of "free" are as follows:
Total Used Free Shared
Buffer Cached
mem 60348 59456 892 0
1396 14160
-/+ buffers/cache: 43900 16448 Swap: 192772
40432 152340 0
I'm new at Linux, so keep your answers at an elementary level (if
possibe).
You appear to only have 64MB of RAM in your system. This isn't really
enough to run a desktop environment (you'd even be hard pressed to run
Windows efficiently in 64MB).
You're using 40MB of swap, so your machine is spending a lot of time
swapping. You've probably also noticed your hard drive is
working pretty hard, too. When memory gets full, the system starts
looking for programs that aren't currently ready to run. It then
swaps bits of those programs out to the swap partition of your hard
drive to free up memory, and swaps in pieces of programs from the disk
that are ready to run. Disk I/O is always much less efficient than
RAM operations, hence your machine slows down. If the swapping is
bad enough, the machine becomes unusable.
The easiest fix is to add more RAM. I'd add at least another 64MB,
although you'd be much happier with another 128MB or more.
I installed RD9 on a computer with 512MB of RAM. It runs much faster
and not so much disk activity. Thanks for everyones insight, it helped
tremendously.
Glad to hear it. You ran into the dread "10 lbs. of stuff in an 8 lb.
bag" syndrome (a.k.a. "swapping").
One of the ways to detect that is the "free" command you used before.
Let me parse the output for you a bit so you can see what I saw (I'm
going to reformat it a bit, too):
Total Used Free Shared Buffer Cached
mem 60348 59456 892 0 1396 14160
-/+ buffers/cache: 43900 16448
Swap: 192772 40432 152340 0
The first line is, of course, just headers. The second line starting
with "mem" is the _physical_ memory in your machine. The numbers are
all in kilobytes, so you can see that the "Total" column shows that you
have 60MB (4MB is in "extended" memory). Of that 60MB, 59MB is "Used",
and 892K is "Free" (don't worry about shared, buffer and cached at this
time).
The "-/+ buffers" bit shows how many I/O buffers are used and how many
are free. If you don't understand that, don't worry about it.
The final, "Swap:" line shows how much swap space you have. You have a
total of 192MB of swap, and you're using 40MB of it. This means that
the programs you're using are using a total of 100MB (60MB of physical
RAM and 40MB of space on the disk). That means that almost half of the
active programs have to be swapped off and on the disk. Ugh!
Another way of looking at it is to do "vmstat 5". This will display a
series of lines of data showing the actual memory activity, one line
every 5 seconds until you hit CTRL-C. The important thing to watch in
a vmstat display are the "si" (swap-in) and "so" (swap-out) columns. If
you see a lot of activity in those columns (if the numbers are
significantly above zero), then your machine is running out of memory.
For most users, the fix is adding memory.
Heavy swapping may be indicative that a program is "leaking" memory or
doing other unkind things. Many neophyte programmers write sloppy code
that allocates memory and doesn't return it, and often the only way you
can detect that is by watching vmstat while the program executes. As
a user, there isn't much you can do about that sort of thing other than
chastising the programmer.
I hope that helps you follow along in our analysis of what you gave us
and aids you in continuing to monitor your system.
To paraphrase an old adage: "You can never be too rich or have too much
RAM!" :-)
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens vitalstream com -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- "You think that's tough? Try herding cats!" -
----------------------------------------------------------------------
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]