Hardware > Sun

Prozessoren sinnvoll einsetzen!

<< < (2/2)

Matthias:
Sicher stellt sich auch die Frage, wie schnell die CPU's der U60 sind.

Gab es überhaupt 440 MHz für die 5500 ?  Ich dachte das wären dann 464 MHz .....

Dann ist auch die Frage, wie viele Prozessoren der Apache überhaupt benutzt. Und zu bedenken gilt auch, dass die 5500er Boards alles SBus sind (ich glaube 25 MHz) und die U60 immerhin PCI (33 MHz). Es würde mich nicht wundern, wenn das damit etwas zu tun hätte.

Zudem kann auch der Speichertakt (bzw. Zugriffsgeschwindigkeit auf den Seicher, Interleaving), die Größe und Geschwindigkeit des cache, nicht zu vergessen der CPU-Bustakt eine Rolle spielen. Nicht zu vergessen die Platten.

Ich denke, der Hauptgrund ist, dass eine U60 eben grundsätzlich einen 'moderneren' Aufbau hat als eine 5500 - ganz egal, welche Komponenten man betrachtet. Und das alles zusammen läßt schon erahnen, dass mit einer 5500 bei der (wahrscheinlich) nur 1 Prozessor genutzt wird, nicht die Performance einer U60 erreichen kann.

Aber packe doch mal 20 Apache Prozesse auf die 5500 und die U60 und greife mit 20 Clients gleichzeitig darauf zu - vielleicht gibt das etwas Licht in die Geschichte.

Und wenn alles nichts hilft : suche nach anwendungsorientierten Benchmarks die viele User simulieren - da sollte eigentlich die 5500 vorne liegen.

Just my 2 ct's

Matthias

stiefkind:

--- Zitat von: llothar am 25. Mai 2006, 12:14:39 ---Es sei den der Speicher ist ziemlich falsch auf die CPU Boards verteilt (geht das ueberhaupt ?)

--- Ende Zitat ---

Jein. Die 5500 hat UltraSPARC II CPUs. Und damit die MMU auf den Systemboards, nicht in den CPUs, wie das bei nachfolgenden UltraSPARC-CPUs der Fall ist. Das bedeutet, erstmal ist es der Maschine egal, wo CPU und wo Memory stecken. Man kann sogar ein Systemboard nur mit Memory bestueckt betreiben, waehrend die CPUs auf anderen Boards stecken.

Aber: In so einem Fall muessen die Daten vom Memory in Richtung CPU und zurueck den langen Weg ueber die Backplane nehmen. Und das kostet uU. Es macht also Sinn, Memory auch nahe an die CPUs zu stecken.

Ein weiterer Faktor kann sein, dass aufgrund asymmetrischer Memory-Bestueckung kein Memory-Interleaving gemacht wird bzw. gemacht werden kann. AFAIR kann man das im OBP auch aus-/einschalten und in recht engen Grenzen beeinflussen. Voraussetzung ist aber in jedem FAll symmetrische Memory-Bestueckung, sprich: gleich grosse Module auf allen Baenken, ueber die man Interleaving machen will.

Am L2-Cache kann's eher nicht liegen. Die x500-Serie hatte CPUs bis rauf zu 464MHz/8MB L2, eine U60 hatte max. 450MHz/4MB L2.

Insgesamt ist es natuerlich schwer, Aufgrund der relativ vagen Aussagen ueber die Antwortzeiten eines Apache rueckzuschliessen, wo der Engpass ist. Im ersten Schritt waere der Output von /usr/platform/sun4u/sbin/prtdiag -v hilfreich. Von beiden Systemen. Haben beide gleiche OS-Version (/etc/release)? Gleichen Patchstand (showrev -p)? Hast Du den Apache selber kompiliert? gcc? Sun Studio? Mit welchen Compilerschaltern? Wenn nicht kompiliert, woher hast Du das Binary?

Zur einer genaueren Untersuchung wuerde man zunaechst iostat, vmstat, mpstat, prstat heranziehen. Wenn das nicht hilft, koennte man anfangen, den Apache mittels psrset, pbind und/oder Ressource Management auf eine einzelne CPU zu binden und mal schauen, was sich dabei veraendert. Was macht die Datenbank auf dem gleichen System? Swap?

Ich habe im Moment ein aehnliches Problem mit MySQL + MediaWiki auf einer E4500 mit 12CPU/24GB RAM. Ok, die Maschine macht noch eine ganze Menge anderen Kram, aber das Wiki hat dermassen ueble Antwortzeiten. Allerdings ist MySQL recht lieblos mit gcc kompiliert, weil's erstmal einfach auf die Schnelle da sein musste. Ich vermute, mit einem Studio 11 wird das schlagartig besser aussehen... Aber meine 30-Stunden-Tage sind immer noch verschollen :-)

wolfgang

Navigation

[0] Themen-Index

[*] Vorherige Sete