Linux Debian support - Re: Linux to support Massive Multi-Threading (or dies)!

This is Interesting: Free IT Magazines  
Home > Archive > Linux Debian support > November 2004 > Re: Linux to support Massive Multi-Threading (or dies)!





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Re: Linux to support Massive Multi-Threading (or dies)!
Iceman

2004-11-16, 2:45 am

On Mon, 15 Nov 2004 07:41:02 -0500, Jean-David Beyer wrote:

> Linønut wrote:
> Sure enough, but does it matter?
>
> 6404 ? S 2:43 /usr/lib/mozilla-1.4.3/mozilla-bin
> 6415 ? S 0:00 /usr/lib/mozilla-1.4.3/mozilla-bin
> 6416 ? S 0:00 /usr/lib/mozilla-1.4.3/mozilla-bin
> 6417 ? S 0:00 /usr/lib/mozilla-1.4.3/mozilla-bin
> 6419 ? S 0:01 /usr/lib/mozilla-1.4.3/mozilla-bin
> 6838 ? S 0:00 /usr/lib/mozilla-1.4.3/mozilla-bin
>
> I.e., it makes many processes, but all but one do next to nothing, so they
> might as well run on a single processor as not.
>
> It seems to me that unless they do something with the one that is process
> 6404 (at the moment on my machine), splitting over multiple processors is
> not going to make any practical difference. Furthermore, since Mozilla
> uses few resources on my machine compared to others, I would be well
> advised to investigate other processes. Mostly Mozilla must be able to
> keep up with my keystrokes, and downloading over a dial-up connection, so
> it does not use much processor time unless I try to look at a page with
> .pdf in it. For some reason, when Mozilla displays .pdf stuff, it burns up
> an entire processor. Doing what I cannot imagine. That must be a bug, though.
>
> But for my usage (probably atypical), my biggest resouce hog is a database
> application that uses a bunch of processes for service: IBM's DB2 that
> uses lots of concurrent processes. One program takes around an hour on a
> dual 3.06GHz hyperthreaded machine with 4G RAM (so Linux thinks I have 4
> processors). If I watch it, it is seek-limited on the hard drives (not IO
> limited in the sense of transferring information in and out: this machine
> can do 55MBytes/sec IO to the hard drives, and that may not be the upper
> limit). The processes run about 4 Megabyte/sec to the hard drives. Almost
> all that data are on 4 Ultra/320 10,000rpm SCSI hard drives, split up to
> do a minimum of seeking. The log file is on a 7200rpm EIDE hard drive that
> (at the time) is not doing anything else. It spends a lot of time logging.
> The dbms has 8 page cleaner processes (that do the bulk of the writing to
> the hard drives) and 8 page fetcher processes (that do the bulk of the
> writing from the hard drives) to ensure maximum concurrance in reading.
> What happens is that about 25% of the cpu power is used, with about a
> dozen concurrent processes running. about 70% of the time, the system is
> in IO-WAIT state according to top. The page cleaners are mostly in D
> state. It just cannot seek fast enough, in spite of there being 6 hard
> drives, each of which has an 8Meg cache in it. So more processors, better
> multiprocessing, etc., will be no use.
>
> BTW, running with 6 hard drives instead of 2 really does help cut down on
> the seeking, though. A similar system with two Ultra-2 Wide 10,000rpm hard
> drives took 10 to 12 hours for the same thing.


I'm curious, why aren't you running a RAID5 or something?
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com