lkml.org 
[lkml]   [2000]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux responsiveness under heavy load
Date
Try distributing your data over several disks; for example, put the /usr and
/home
on seperate disks from /. Furthermore, if you can add more IDE cards or
more SCSI cards and distribute the
drives over the interfaces, you'll win even more.

My experience with Linux (and more generally, any PC OS) is that when you're
doing lots of disk I/O on the drive that holds the system files, you see
near total loss of responsiveness.

For example, while untarring a large (1G) file to the system disk, I can't
even telnet into my box. It holds at the "
Connection established". If I hit ^Z to stop the tar job, the telnet
immediately finishes the connection!

However, I recently had a chance to move all the data to seperate disk, and
did some experimenting.
When untarring on the seperate disk, the system still maintained full
responsiveness (it was a bit slower,
IE a short delay for each typed character). I could telnet in and run jobs
without any trouble.

I've seen this with: IRIX, Solaris, Tru64, Linux, Win98, and WinNT (the OS's
I use regularly).

----- Original Message -----
From: "Nicolas MONNET" <nico@monnet.to>
To: <linux-kernel@vger.rutgers.edu>
Cc: <nico@monnet.to>
Sent: Wednesday, March 08, 2000 12:10 PM
Subject: Linux responsiveness under heavy load


>
> I hope this is the appropriate place to ask this kind of question ... I
> could'nt really find any useful info otherwise (web search). Here I go:
>
> I use almost Linux mostly for all my computing needs -- both personal and
> corporate. I've been extremely pleased for over 4 years. However
> something bothers me.
>
> I've noticed that under heavy loads, and actually, not so heavy loads,
> Linux's responsiveness is effectively very poor.
>
> 2 cases I've encountered lately:
>
> 1 - My company has a MySQL-backed web server. We need to compute stats and
> generate somewhat long series of queries on a regular basis (every n
> minutes). The database fits entirely in the disk cache, AFAIK: the machine
> is equipped with 300MB and the whole database is ~ 45MB. Now, as more
> queries are concurrently issued (more than 1 at once), the responsiveness
> gets worse. It's mostly significant when spawning new processes -- I.e
> when logging in from telnet from instance, which takes a few seconds. The
> system isn't even swapping, I can verify it. The load average in that case
> is between 2 and 4. The system is a proliant 1600 with 1 PII-450.
>
> It's not like there's a bunch of runaway processe: at most, 5 processes
> are running.
>
> 2 - I was using a perl script to install the Unreal Tournament Bonus
> pack .umod (basically a compressed package). The said script is marked as
> not being optimised, and it used up to 230M of memory whereas I have 128M
> of physical ram. Of course, it swapped a lot, as I expected it. But ...
> the system was absolutely unusable during that time. Not just slow ...
> absolutely unusable. Plus top showed it as 80% idle most of the time.
> (The disk is connected using UDMA/33 on a BE6-2 MB, the system is a
> PIII-450).
>
> Now I *hear* (but is it true?) that *BSD handles this sort of case much
> more nicely. Is it true? Is there anything planned to make linux perform
> better in this area? Are there workarounds? Niceing the process doesn't
> seem to do any good. Is there, for example, a way to force a process not
> to consume more than a certain % of the CPU?
>
> Thanks in advance for your help.
>
> (Please CC me on the replies)
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:1.430 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site