5 messages in org.freebsd.freebsd-smpRe: current working SMP mboards?| From | Sent On | Attachments |
|---|---|---|
| Ken McKittrick | Feb 28, 2000 7:08 am | |
| Jim Mercer | Feb 28, 2000 7:30 am | |
| Kelly Yancey | Feb 28, 2000 8:16 am | |
| Jim Mercer | Feb 28, 2000 8:21 am | |
| Fabio Cesar Gozzo | Feb 28, 2000 9:07 am |
| Subject: | Re: current working SMP mboards? | |
|---|---|---|
| From: | Jim Mercer (ji...@reptiles.org) | |
| Date: | Feb 28, 2000 8:21:18 am | |
| List: | org.freebsd.freebsd-smp | |
On Mon, Feb 28, 2000 at 05:03:57PM +0100, Bart van Leeuwen wrote:
i'm considering the following for 3.4-STABLE (or 4.0-RELEASE): ASUS (P2B-DS or P2L97-DS) 512M RAM 1 x scsi drive for OS/applications 5 x 9/18 gig U2W drives under vinum raid5 for data
First of all, I am using virtually the same config, the p2b-ds works fine and the scsi stuff works out of the box on both 3.x and 4.0
cool.
my theory was that with a dual processor, each incantation of the application would fire up on alternating processors.
In quite a few cases that works fine. Don't count on it that the app will keep running on the same cpu all the time, but when you run some app twice and they both require cpu time, fbsd will distribute the load over its 2 cpus.
postgresql works with a main process (which coordinates reads/writes to the actual database) and a pairing of client/server processes to actually deal with the query.
so, if i fire up a query, there are 3 processes involved, one persistent, two transient.
if there are two cpu's, then the processes have more available CPU to get the job done, right? i understand that a single, non-threaded, process will not use cycles from both processes concurrently, but two processes may end up using independent processors for CPU cycles.
i gather that the processes might end up on the same CPU, but since i have many queries running at the same time, it would have some advantage to have the processes round-robin'ing the CPU's.
is this correct? or is SMP effectively useless unless my application (primarily postgresql) is multi-threaded.
Not mostly useless, tho its unlikely to double the performance..
doubling the performance would be way cool, but even a 25% increase in performance would be an acceptable upgrade from where we are now.
Its important to realize that a single instance of an application can only be run by 2 cpus simultaniously if it is multi threaded. A non multi threaded app is unlikely to show any performance gain on smp. What SMP does do in such cases however is make that you can run more on that machine.. ie, it doesn't get faster, it gets more capacity. (ie, the capacity to run a 2nd instance of an application without any impact on the first instance)
assuming disk I/O is not a factor (which it may be), if i have a process which is processor intensive, i can run two instances of that process in parallel, right? so if the process takes 30 seconds to complete, then it would be 60 seconds in serial, and 30 seconds (plus something no doubt) in parallel.
or are you saying that even when running the processes in parallel, that there are wait-states or something that would make the parallel running time similar to the serial running time?
-- [ Jim Mercer ji...@reptiles.org +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message