[ale] [ANNC] ALE CENTRAL for Thursday, May 21, 2009

[JK]

Jeff Lightner wrote:
> It's not so much how much resources each app uses but how much of the
> SAME resources they use at the SAME time.  I've seen systems brought to
> their knees by something like:
> 
> while true
> do ls -lR /
> done

That would be weird. It's only running one instance of ls at a time,
so I'd expect the impact to be minimal, other than hitting the disk
for inodes from time to time if the filesystem was crowded.

Put an & at the end of the second line and you might fill the
process table in a hurry.  Processes are a rather scarce resource
on some OS's, and there was a time when Linux was limited to 65K
processes, although that may no longer be the case.  I'd expect the
CPU and RAM impact of that "&" would be fairly minimal, though,
since everything "ls" touches -- executable, libs, inodes -- would
get cached in RAM by the kernel rather quickly. On a HUGE filesystem
where the in-use inodes could overwhelm physical RAM you might get
some thrashing.

In general, multiple processes merely *using* the same resource is not
a problem -- in fact it's the case that modern OS's mostly optimize for.
As much memory, swap space, filesystem resources, etc as possible is
shared on a copy-on-write basis.  It's when a bunch of processes
create *new* instances of resources (eg by writing a CoW RAM
page, or by creating a new filesystem object), or contend for
existing ones (eg by locking a file for write operations) that things
slow down.

-- JK


-- 
A closed mouth gathers no feet.