Prozessoren sinnvoll einsetzen!

[neo-sun]

Hallo Leute,

ich schon wieder.

Habe hier ne 5500, mit 10 Prozessoren, die langsamer iss als meine U60?!

Habe irgendwo gelesen, das man die Proz. skalieren muß.

Also Aufgaben zuteilen muß, habe aber leider keine Ahnung was ich da machen muß.

Hoffe hier kann mir jemand helfen?

Gruß

Neo-Sun

[mhinas]

Habe hier ne 5500, mit 10 Prozessoren, die langsamer iss als meine U60?!

Habe irgendwo gelesen, das man die Proz. skalieren muß.

*stirnrunzel*

inwiefern ist die 5500 kangsamer als die U60? vom subjekiven empfinden her? oder hast du was gemessen? das skalieren jedenfalls sollte eigentlich das OS/das Sys selber besorgen...

[Jonny]

Es macht nicht nur die Masse
Die 5500 gab es mit CPU's von 167 bis 464 MHz. Wenn in deiner U60 schnellere
CPU's drin sind als in der 5500er, dann fühlt sich die auch schneller an.
/usr/platform/sun4u/sbin/prtdiag -v gibt zu solchen Geschichten Auskunft.

Zweng sinnvollem Einsatz kann ich nur SETI@HOME und das Team sonnenblen.de empfehlen
Dort macht es dann auch wieder die Masse

Gruß
Jonny

[neo-sun]

Hallo erstmal,

danke für die schnelle Antworten, also es sind alles 440 CPU´s.

Naja Subjektiv ist das nicht, sondern eher ziemlich real.

auf der Sun läuft einmal ein Apache Server, sowie ne Datenbank, Fakt ist das die Response Zeiten des Apches, doch wesentlich langsamer sind als die von der U60.
Ein vergleich mit einem Windows Rechner war dann noch erschreckender.

Ist das Normal?

Gruß

neo-sun

[llothar]

Na ja ein Vergleich mit einem 2,8 GHz Rechner ist da sicher erschreckend. Es sind halt nur 440 Mhz, d.h. es sollte schon 5-6x langsamer sein.

Solche Server geben keine guten Response Zeiten sondern sind dazu da auch bei Peaks nicht "geslashdottet" oder "geheist" zu werden. Warum das allerdings langsamer als auf einer U60 ist ist mir nicht einsichtig. Es sei den der Speicher ist ziemlich falsch auf die CPU Boards verteilt (geht das ueberhaupt ?)

Vielleicht lieferst du mal ein paar reale Zahlen bevor wir hier alle anfangen zu raten.

[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]

Es sei den der Speicher ist ziemlich falsch auf die CPU Boards verteilt (geht das ueberhaupt ?)

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