Verschil met 1 of 2 CPU's?

[Verwijderd]

Haai,

Ik zag dat er al een topic over dual Xeon CPU's was maar dat topic loopt iets anders en heb ik niks aan, vandaar dus deze.

Ik draai op het werk met een Proliant ML530 en hierin draait dus 1x P3 Xeon 1GHz.

Sinds het begin van dit jaar draait er een apllicatie op die 85% van de dag op 100% staat......
Kan iemand mij vertellen dat wanneer ik er een 2de CPU bij zet de 100% naar 50% gaat? Of handeltie gewoon zijn opdrachten 2x zo snel af.

Wij willen best €2000 uitgeven maar willen wel een zekerheid...

Wie o wie..

[ Voor 2% gewijzigd door Verwijderd op 04-05-2003 02:09 . Reden: schrijffout ]

[BalusC]

Dat hangt volledig van de applicatie af Zie ook de SMP FAQ, welke je kunt vinden in de Technische PMG FAQ.

Edit: dus, check de appl specs en/of mail de maker van de applicatie

[ Voor 20% gewijzigd door BalusC op 04-05-2003 02:15 ]

[YoupY]

De extra voordelen die je haalt uit het gebruik van 2 cpu's zie je voornamelijk terug wanneer je meerdere programma's tegelijkertijd draait. Bij een 1 processor systeem worden alle processen zo snel achter elkaar aangeboden dat het lijkt alsof er meerdere programma's tegelijkertijd draaien. In werkelijkheid nemen ze om de beurt een pauze en is het volgende proces weer aan de beurt.

Wanneer de 2 of meer processoren hebt wordt de werklast verdeeld over die processoren. Dit wordt verder bepaald door het operating system. Ik weet verder niet precies of het mogelijk is om bepaalde programma's zelf aan een processor toe te wijzen, omdat in principe het operating system hiervoor verantwoordelijk is. Windows geeft wel de mogelijkheid om met prioriteiten te rommelen.

Het programma dat op 100% draait, zal dan ook wel op 100% blijven draaien, alleen zal er daarnaast meer processortijd beschikbaar zijn voor de andere processen.

Het lijkt me verder dat wanneer je even verder had gezocht wel een antwoord had kunnen vinden op de vraag die je nu steld

[N8w8]

Naast performancewinst bij multitasken maken veel server apps vaak ook zelf al gebruik van SMP, zoals databases, webservers e.d.. En tegenwoordig kunnen bijvoorbeeld progs die gebruik maken van POSIX threading in Linux al vanzelf over meerdere CPUs verdeeld worden. En bij t compilen van src code kan je (bij GNU make althans) meerdere CPUs aan t werk zetten door ze tegelijkertijd verschillende objecten te laten compilen.

Hangt dus 100% van de app in kwestie af (maar dat had BalusC al eerder geconcludeerd )

[FragFrog]

Verwijderd schreef op 04 mei 2003 @ 02:09:
...
Sinds het begin van dit jaar draait er een apllicatie op die 85% van de dag op 100% staat......
Kan iemand mij vertellen dat wanneer ik er een 2de CPU bij zet de 100% naar 50% gaat? Of handeltie gewoon zijn opdrachten 2x zo snel af.

Het hangt niet alleen van de applicatie af hoor

Met windowsXP prof kun je dmv taskmanager gemakkelijk aangeven dat die applicatie bijvoorbeeld 1 CPU voor zichzelf krijgt, op die manier wordt die applicatie sneller, en kun je toch makkelijker doorcomputeren doordat je andere proc idle is op kernel activiteit na. En als je er niks aan doet staan je procs meestal beide op 50% te werken. In het toch vrij specifieke geval van voor dual CPU geoptimaliseerde software zal de applicatie 2x zo snel gaan, maar of dat zo is zul je zelf wel in de handleiding kunnen vinden.

[BalusC]

Tsja, als die ene server alléén voor die applicatie wordt gebruikt, dan zul je totaal geen profijt trekken van een tweede CPU wanneer de applicatie niet multithreaded is (lees: niet geoptimaliseerd voor SMP configuraties)

[Bierkameel]

BalusC schreef op 04 mei 2003 @ 16:21:
Tsja, als die ene server alléén voor die applicatie wordt gebruikt, dan zul je totaal geen profijt trekken van een tweede CPU wanneer de applicatie niet multithreaded is (lees: niet geoptimaliseerd voor SMP configuraties)

Je kan wel met CPU Affinity die taak op de 2de proc laten draaien waardoor de eerste proc meer tijd over heeft voor andere taken zoals disk I/O en netwerkverkeer

[BalusC]

Hoeveel moeite zou een CPU in I/O en netwerkverkeer stoppen? Toch niet meer dan 5% schat ik .. Zo'n server zal wel voorzien zijn van een HW-based NIC/schijfcontroller

Affijn, al met al voorspel ik dat een 2e CPU slechts 5% prestatiewinst zal opleveren, wanneer de server inderdaad alléén die ene applicatie hoeft te draaien.

[ Voor 33% gewijzigd door BalusC op 04-05-2003 16:31 ]

[Verwijderd]

Het hangt gewoon af van de applicatie. Zo claimen de makers van Deep Fritz 7 (schaakprogramma dat 'gewoon' onder Windows draait) dat de rekensnelheid met een 2e CPU met maar liefst 85% toeneemt. Maar de searchengine van Fritz staat dan ook als een wonder van efficiëntie bekend, het is compleet in Assembler geschreven omdat de code sneller is dan dat van een hogere programmeertaal als C en de programmeur meer mogelijkheden geeft voor agressieve optimalisaties.

Ik vrees echter dat er slechts weinig programma's zijn die net zo goed geoptimaliseerd zijn, vraag gewoon je softwareleverancier welke prestatiewinst er te behalen valt met een 2e CPU.

[ Voor 7% gewijzigd door Verwijderd op 05-05-2003 15:54 ]

[Remy]

Zou het niet in toekomstige OS'en (Windows, Linux, wat anders, doet er ff niet toe) makkelijk zijn, als er dual-proc code ingebakken zou worden, die automatisch die 2e proc detect en in gebruik neemt? Dan hoeven de 'gewone' programmamakers zich daar niet druk over te maken, en dan kunnen dual-proc eigenaars zeker weten dat hun 2e proc ook goed benut wordt. Want dat gebeurt dan wel met multitasking veel, maar nog niet veel binnen programma's zelf, de uitzonderingen daargelaten die dus wel speciale SMP code bevatten.

Of zou dat te duur/moeilijk worden voor OS'makers, omdat niet veel thuisgebruikers een dualproc systeem hebben, en laten ze het (voorlopig) aan de softwaremakers zelf over. Want met die special ingebakken code, of desnoods een update voor het OS, is een dualproc systeem veel interessanter, niet alleen voor heavy multitasking, maar ook voor alle andere programma's die rauwe processingpower nodig hebben

[Verwijderd]

Die CPU load vind ik verdacht hoog. Om wat voor applicatie gaat het?

btw:
Als het tegenzit moet je eerst je OS opnieuw installeren/upgraden om de 2e CPU te kunnen zien

[vassago]

Verwijderd schreef op 04 mei 2003 @ 02:09:
Haai,

Ik draai op het werk met een Proliant ML530 en hierin draait dus 1x P3 Xeon 1GHz.

Sinds het begin van dit jaar draait er een apllicatie op die 85% van de dag op 100% staat......
Kan iemand mij vertellen dat wanneer ik er een 2de CPU bij zet de 100% naar 50% gaat? Of handeltie gewoon zijn opdrachten 2x zo snel af.

Kijk even met Performance monitor of je Queing hebt op je processor, zo ja gaat het zeker schelen.
Ook is het CPU gebruik wat de taskmanager opgeeft niet geheel relevant.

Wij willen best €2000 uitgeven maar willen wel een zekerheid...

Wij waren bij compaq maar 600 eur. kwijt voor een P-III 1400, 2000 eur lijkt me erg veel.
Anders die Xeon inruilen voor een evt. snellere P-III, de Xeon 512KB cache is dezelfde proc als een P-III 512KB cache.

[TD-er]

Even de bovengenoemde nadelen daargelaten (reinstall windows oid)
Het grote voordeel van een dual-cpu-systeem is dat je machine lekker rap blijft reageren als er een programma druk aan het rekenen is.
Er is maar heel weinig software wat sneller gaat lopen als je er een CPU bijprikt.
Ik heb nu een P4, voor m'n videoeditingwerk en als de computer druk aan het comprimeren is, dan kan ik nog amper fatsoenlijk zitten internetten. Dit was met m'n dual machine niet het geval, daar merkte je haast niets van een ander process. (behalve bij hdd-access enzo)

[Vaporized]

ik denk niet dat het heel veel zal uitmaken, omdat er niet veel software is op gemaakt..

[Qwerty-273]

ReemF schreef op 04 May 2003 @ 21:36:
Zou het niet in toekomstige OS'en (Windows, Linux, wat anders, doet er ff niet toe) makkelijk zijn, als er dual-proc code ingebakken zou worden, die automatisch die 2e proc detect en in gebruik neemt? Dan hoeven de 'gewone' programmamakers zich daar niet druk over te maken, en dan kunnen dual-proc eigenaars zeker weten dat hun 2e proc ook goed benut wordt. Want dat gebeurt dan wel met multitasking veel, maar nog niet veel binnen programma's zelf, de uitzonderingen daargelaten die dus wel speciale SMP code bevatten.

Osén hebben al support voor dual procs en ze gaan daar al handig mee om verschillende processen aan verschillende procs toe te wijzen. Alleen kan een OS nooit weten wat het programma gaat doen en wijst standaard een programma/process dus alleen toe aan 1 proc (1 van de zovelen dan he )

Programmeurs moeten in hun software aangeven welke processen los van elkaar kunnen draaien en waar ze afhankelijk van zijn. Programmeurs zijn daar soms te lui in, of tja hebben geen dual station zelf waardoor optimalisaites daarvoor meestal niet ingebakken worden

[Gregoor]

vassago schreef op 04 May 2003 @ 21:39:
Kijk even met Performance monitor of je Queing hebt op je processor, zo ja gaat het zeker schelen.
Ook is het CPU gebruik wat de taskmanager opgeeft niet geheel relevant.

Dit lijkt mij zelf ook de beste oplossing. De vraag is namelijk of het programma zeg maar net die 100% gebruikt, en het er dus net mee aankan, of dat het eigenlijk 130% zou gebruiken, en dus bij dubbele cpu capaciteit ook die dertig procent sneller zou draaien. Dat lijkt me dus ten eerste van belang voor je keuze. Overigens is het wel zo dat ookal mocht de queue voor de processor niet groot zijn, en het dus lijkt weinig nut te hebben een 2e proc aan te schaffen, het natuurlijk toch verstandig kan zijn (mits de applicatie goede support biedt), omdat er dan toch meer groeiruimte voor de toekomst is, en specifieke pieken dan beter op zijn te vangen.

Daarnaast is het inderdaad ook van belang hoe het programma met meerdere processoren omgaat. Als het bijvoorbeeld amper gebruik maakt van verschillende threads, dan zal het voordeel maximaal een paar procent zijn, omdat de kernel, disk en i/o activiteiten dan verschuiven naar proc 2, en je eerste proc dus een paar procent meer over heeft voor de applicatie. Mocht het wel beter werken met meerdere threads, die ook goed gebruiken maken van meerdere procs, dan kan het dus stukken nuttiger zijn. Vraag dat dus even na bij de leverancier van de applicatie, of stel die vraag op een gerelateerd forum of een nieuwsgroep van gebruikers van de betreffende applicatie. Daar zul je waarschijnlijk minder subjectieve antwoorden kunnen verwachten.

[Verwijderd]

Ok...dank dank voor de vele reacties en sorry dat ik wat laat reageer maar er waren wat andere issue's....

Ik zal even een diepere uitleg geven:

De applicatie die op de server draait heet Parsis. Dit is een TMS (Transport Management Systeem) en deze draait op de Providex Engine. De programmeer taal is ook Providex.

Ik ben geen programmeur dus heeft het geen zin mij daar iets over te vragen.

In Januari gingen wij (mijnsinziens veeeels te vroeg) live met dit pakket met alle gevolgen van dien. Traag traag traag was het vervelende woord in deze....collega's werden, in terecht, steeds ongeduldiger......
Het programma werd toen via een snelkoppeling met een UNCpad gestart..

Later kregen wij van Parsis via Providex een proggie dat WinDX heet en voor een soort host/slave situatie zorgt.
Proggie wordt locaal geinstalleerd en via de snelkoppeling geeft je wat details in en draaien.

Op de server draait dan dus de host van WinDX.....so far so good.

Snelheid winst voor de gebruikers wat echt 100%, super dus....maaaaaaaar...overdag...dan zitten er tussen de 30 a 40 gebruikers in is pakket niet vooruit te branden, sterker nog, wanneer ik naar de server loop om iets te checken.......nou, tis net een slowmotion machine geworden....

Wanneer ik dan de CPU ff monitor via de taskmanager...100%.

Elke keer wanneer iemand het programma (Parsis) op zijn/haar computer start dan start er dus een applicatie op de server, hetgeen je op de server dan ook echt ziet....er staan dan echt 30 proggies te stampen.
Bij het inlezen van bv boardcomputer gegevens....1 groot drama.....neem maar een interne snipperdag ofzo.

Nu heeft Providex Canada al gezegt dat het aan het programmeren...de firma hier zegt weer dat ze dat weten en alles er al aan gedaan hebben....

Dus: Het probleem is niet zo makkelijk en het vraagstuk blijft nog steeds staan. Er is nog steeds niemand maar dan ook niemand die mij de garantie kan geven dat het wel sneller gaat werken met 2 CPU's.

Wat een verhaal he.....

[Verwijderd]

test

[Aetje]

Test okee

Maar naast het CPU gebruik, check ook eens hoeveel geheugen er gebruikt wordt. Als er 30 appjes op de server lopen die best zwaar zijn kan het zijn dattie zonder geheugen zit -> veel swappen -> zeer slome machine.

[leuk_he]

Je zegt dat het een P3 Xeon is. Er zijn inmiddels ook P4 xeon´s die op heel veel meer megaherzen draaien (en behalve dat ook echt sneller zijn). Als je bottleneck echt de cpu capaciteit is (te weinig geheugen kan ook tot hoge cpu load lijden) dan zal een 2x snellere processor(2x maal sneller is meer dan 2x aantal Mhz) zeker winst opleveren. Multiprocessor moet je altijd afwachten (test bla bla bla)

Hoeveel Mhz draait die xeon nu ongeveer?
Kan compaq ook een 2xsnellere server leveren/upgraden voor Euro 2000 (hmm.dat is niet zo heel veel geld daarvoor)
Zijn er ook snellere P3 xeons beschikbaar dan er nu in die machine zit? dan die eerst upgraden lijkt me.

[Elephtera]

er draaien meerdere programma's dan zou met een beetje goed instellen 15 op de ene proc, en 15 op de andere proc moeten kunnen, wat in theorie een snelheids verdubbeling zou betekenen. als echter de hd en geheugen de bottleneck is, dan zal een extra proc weinig uitmaken omdat de pc daar de hele tijd op moet wachten.
hd is op te lossen met een raid-0 opstelling, en geheugen gewoon meer en/of sneller geheugen erin.

[heuveltje]

het is simpel
als ie idd op de server 30 appies lopen
dan zijn 2 cpu's een stuk sneller dan 1
Os zal ze redelijk netjes verdelen over 2 cpu's dus ook daar hoef je niet naar te kijken

wel kijken : of je genoeg geheugen hebt, als dat vol is dan helpt niks meer.
hoeveel disk-activiteit je hebt, bij teveel vertraagd dat ook je servert !

[dion_b]

heuveltje schreef op 15 May 2003 @ 15:54:
het is simpel
als ie idd op de server 30 appies lopen
dan zijn 2 cpu's een stuk sneller dan 1
Os zal ze redelijk netjes verdelen over 2 cpu's dus ook daar hoef je niet naar te kijken

wel kijken : of je genoeg geheugen hebt, als dat vol is dan helpt niks meer.
hoeveel disk-activiteit je hebt, bij teveel vertraagd dat ook je servert !

Yup, second that.

Maar goed, we hebben het hier over een P3 Xeon 1GHz. Waarschijnlijk kun je voor de prijs van een enkele nieuwe exemplaar daarvan zowat een nieuwe server neerzetten met een P4 op 3GHz met SMT, wat gegarandeerd meer performance winst zal opleveren

Sowieso zal de OS opnieuw geinstalleerd moeten worden, ook bij het gewoon bijplaatsen van een 2e CPU...

[Verwijderd]

Aetje schreef op 15 May 2003 @ 11:21:
Test okee

Maar naast het CPU gebruik, check ook eens hoeveel geheugen er gebruikt wordt. Als er 30 appjes op de server lopen die best zwaar zijn kan het zijn dattie zonder geheugen zit -> veel swappen -> zeer slome machine.

Het geheugen gebruik is heel weinig.....de app slurpt CU tijd, geen RAM

[Verwijderd]

leuk_he schreef op 15 mei 2003 @ 13:21:
Je zegt dat het een P3 Xeon is. Er zijn inmiddels ook P4 xeon´s die op heel veel meer megaherzen draaien (en behalve dat ook echt sneller zijn). Als je bottleneck echt de cpu capaciteit is (te weinig geheugen kan ook tot hoge cpu load lijden) dan zal een 2x snellere processor(2x maal sneller is meer dan 2x aantal Mhz) zeker winst opleveren. Multiprocessor moet je altijd afwachten (test bla bla bla)

Hoeveel Mhz draait die xeon nu ongeveer?
Kan compaq ook een 2xsnellere server leveren/upgraden voor Euro 2000 (hmm.dat is niet zo heel veel geld daarvoor)
Zijn er ook snellere P3 xeons beschikbaar dan er nu in die machine zit? dan die eerst upgraden lijkt me.

Ja ik weet het...er is altijd weer sneller te koop maar dat is niet de issue. Vorig jaar hebben we deze server speciaal hiervoor aangeschaft (de oude was echt oud). Alles volgens de wensen van ons zlef en de programmamaker....nui zitten we echter met het geneuzel...heel irri...niet voor mij, maar wel voor mijn gebruikers...dus ook voor mij

Dus een update is nu een beetje zonde van het geld, afschrijving is voor 3 jaar dus moet het er nog ff mee doen. Onze Xeon draait iig op 1Ghz en zou echt meer dan genoeg zijn.

[Verwijderd]

heuveltje schreef op 15 mei 2003 @ 15:54:
het is simpel
als ie idd op de server 30 appies lopen
dan zijn 2 cpu's een stuk sneller dan 1
Os zal ze redelijk netjes verdelen over 2 cpu's dus ook daar hoef je niet naar te kijken

wel kijken : of je genoeg geheugen hebt, als dat vol is dan helpt niks meer.
hoeveel disk-activiteit je hebt, bij teveel vertraagd dat ook je servert !

Maar het zijn 30 dezelfde hoor, niet 30 verschillende......geheugen heb ik, meer dan de helft blijft op dit moment "over"......en de schijfactiviteit is ook snel....en niet noemenswaardig druk....

[Gé Brander]

Maar ondersteunt die applicatie wel 2 processoren?
Geval bij ons: ML580 met 2 x 2.0GHz Xeon en ML380 met 1 x 2,8GHz Xeon en beide 3Gb geheugen. De ML580 op een bloedsnel SAN en de ML380 op een locaal RAID 5 systeem, programma: SQL Server 2000/Analisys Services. De ML380 was sneller! (ML580 2h50minuten de ML380 2h30minuten) Dit was het herberekenen van een kubus met data uit een database met 133miljoen records.
Mijn idee hierover: De ML580 was drukker met het herverdelen van de taken over 2 processoren dan wat hij moest doen en deed er daarom langer over.

[heuveltje]

Verwijderd schreef op 19 mei 2003 @ 12:12:
[...]


Maar het zijn 30 dezelfde hoor, niet 30 verschillende......geheugen heb ik, meer dan de helft blijft op dit moment "over

Dat maakt niet

Als het nou 1 process was dat voor 30 clienten alles deed dan had je een probleem. want windows kan niet 1 proces over 2 cpu's draaien tenzij dat programma er speciaal voor geschreven was.

Maar als het 30 processen zijn (welke boeit niet, ook al was het 50 keer mspaint.exe) dan word het gewoon

Ok jij cpu 1, jij cpu2, jij cpu1, jij cpu2 enz............
afhankelijk van hoever ze allemaal even veel van de cpu vragen kun je dan best wel op een behoorlijke snelheids winst uitkomen.

[heuveltje]

c70070540 schreef op 19 May 2003 @ 12:14:
Maar ondersteunt die applicatie wel 2 processoren?
Geval bij ons: ML580 met 2 x 2.0GHz Xeon en ML380 met 1 x 2,8GHz Xeon en beide 3Gb geheugen. De ML580 op een bloedsnel SAN en de ML380 op een locaal RAID 5 systeem, programma: SQL Server 2000/Analisys Services. De ML380 was sneller! (ML580 2h50minuten de ML380 2h30minuten) Dit was het herberekenen van een kubus met data uit een database met 133miljoen records.
Mijn idee hierover: De ML580 was drukker met het herverdelen van de taken over 2 processoren dan wat hij moest doen en deed er daarom langer over.

das iets heel anders. das 1 applicatie. dus die kun je alleen over 2 cpu's breken als het multithreaded is. maar als het "slecht" geschreven is en thread 1 continu moet wachten op data uit thread2 dan gaat dat idd niet zo snel.

bij 30 losse apllicaties heb je dat probleem niet

[Dromer]

Maar hoe loopt de server dan als er 15 of 20 keer dat progje is opgestart?
Want als hij dan nog steeds brak loopt heeft een 2e processor weinig zin.
Je krijg dan dat elke cpu 15 a 20 progs voor zijn rekening neemt.
Dus als dat al traag is is het met 2 cpu's ook gewoon traag.

[heuveltje]

true, maar iig al minder traag dan met 1 proc

[Verwijderd]

Mmmm, de firma waar Providex vandaan komt zegt het volgende :

ProvideX is geen multi-threaded applicatie. In een multi-processor
omgeving zal ProvideX dus enkel complete ProvideX processen per processor starten.
Let wel dat ProvideX behoorlijk vaak Windows API's gebruikt, die wel degelijk multi-threaded kunnen zijn.


Wat moet ik hier nu weer mee, vaag he?

[heuveltje]

zal ProvideX dus enkel complete ProvideX processen per processor starten.
dat zeiden we toch al
1 proces zal er niet sneller van worden.
maar als jullie er 30 tegelijk draaien wel dus
(voor de goede orde. als je taskmanager opstart zie je nu dus 30 keer providex oid staan ?)


maar je zou eens met de fabrikant moeten mailen wat hun eigenlijk aanraden voor 30 clients
misschien staat er wel iets heel slecht ingesteld. en kan het veel sneller

[Verwijderd]

heuveltje schreef op 19 mei 2003 @ 15:23:
zal ProvideX dus enkel complete ProvideX processen per processor starten.
dat zeiden we toch al
1 proces zal er niet sneller van worden.
maar als jullie er 30 tegelijk draaien wel dus
(voor de goede orde. als je taskmanager opstart zie je nu dus 30 keer providex oid staan ?)


maar je zou eens met de fabrikant moeten mailen wat hun eigenlijk aanraden voor 30 clients
misschien staat er wel iets heel slecht ingesteld. en kan het veel sneller

Ten eerste ff mijn excuus voor het niet meer reageren maar het was wat hectisch allemaal hier en heb eindelijk weer eens tijd gevonden.

Ja, in de taskmanager staan die 30 Processen te draaien.
Inmiddels heb ik (een tijde geleden) contact gehad met (volgens zeggen) de Providex Guru en hij zei expliciet dat 2 CPU's eerder vertragend dan versnellend zullen werken.

Inmiddels is het allemaal ietsiepietsie sneller geworden, de programmeur heeft wat records opgeschoont.
De RAID controller heb ik op 75% READ en 25% WRITE gezet wat ook wat snelheidswinst moet geven, daar Providex meer leest dan schrijft.

Volgend jaar ga ik wel shoppen voor een nieuwe processor of misschien komt er wel een geheel nieuwe server alleen voor dit process.
Het blijft echter misschien.....

Nogmaals, dank voor jullie bijdragen.