> -----Original Message----- > From: Eric Tishler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 23 June 2004 9:01 a.m. > To: NZ Borland Developers Group - Delphi List > Subject: [DUG] Delphi applications on mulitprocessor machines > > > Hi All, > > I have a client server application written in Delphi 6. The > server portion runs on a fairly 'beefed up' machine with 2 > Xeon processors running at 2GHz each. I also have 2GB of RAM > and a lot of other server class hardware.
drool... > Processor window 1 shows 25% most of the time. Processor > window 2 and 4 show 0%. While processor window 3 very > occasionally shows 5 or 10%, but most often it just shows 0%. > Can anyone tell me how to read this window? Am I actually > utilizing the second processor at all? Is there something I > have to do specifically in my Delphi code (or > linker/compiler) to make my server application more fully > utilize the system hardware. > I am also running Firebird 1.0.3 on this system too. Yes, my > server application does connect to the database. A first cut, before someone who knows jumps in : probably the CPU's are hyperthreading so 2 physical cpus look to the OS like 4 CPU's. If that is the case, your 2 windows (2 and 4) staying at 0% is most likely a good thing, in that there are cases where the OS sees 4 quiet CPU's and schedules processes to run on logical CPU 1 and 2 which are just one physical CPU. That means you end up with 1 physical cpu getting hammered and the other doing nothing. Presumably your server process is the one sitting at about 25% on cpu 1, and the firebird process sits on cpu2 at 0% and goes up every now and then - thats what a lot of database servers (that aren't sqlserver ;) look like. See what happens when you run a query - especially, if you can, a big cpu or cache hitting query (with as much cpu and ram as you have, disk is probably going to be a *big* bottleneck, and it's going to be hard to have a query that'll stress one of those cpu's without it sitting waiting for the disk to send enough data to the cpu. Actually, try running a big query multiple times - the first time it'll slowly load off disk, after that it should be cached. In that 2G cache;) There isn't anything you can do in Delphi to change the processor utilisation. If you are using threads the os can schedule them across cpu's, but you get into a similar case as above - is 8 threads with 2 per (logical) cpu better than 1 process on 1 (physical) cpu? Or will you get firebird and 3 busy threads on 1 (physical) cpu? You'll only ever know by rewriting and comparing. And your performance will still vary. (threads = quick response for multiple small queries, but slow for big queries. Without threads = fast completion for a big query but slower for handling many small requests). Presumably if you've got that hardware you are want to hammer the big queries? The other thing you could try is just running 2 instances of your server app, but that can be - and usually is - dodgy. Better utilisation of system hardware is just a SMOP[1]. Is there anything you can do to use more cpu for less time? Kind of like instead of processing a file line by line, load it into that 2G(!), or instead of doing a requestlive and processing record by record, do an sql update that hits the db all at once, but I'm guessing this bit is all stuff you know ;) Cheers, Kurt. [1] : http://info.astrian.net/jargon/terms/s/SMOP.html This electronic message together with any attachments is confidential and intended for the named recipient's use only. If you are not the intended recipient (i) do not copy, disclose or use the contents in any way, (ii) please let us know by return email immediately then destroy the message, and any hard copies of the message, and any attachments. The sender of this message is not responsible for any changes made to this message and/or any attachments and/or connection linkages to the Internet referred to in this message after it has been sent. Unless otherwise stated, any pricing information given in this message and/or attachments is indicative only, is subject to change and does not constitute an offer to buy or sell securities or derivatives at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to separate formal written notification. Where reference is made to research material and/or research rec! ommendations, the basis of the provision of such research material and/or recommendations is set out in the relevant disclaimer. _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
