Hardware > Sun SPARC

SUNFIRE 6800 in Betrieb nehmen

<< < (9/26) > >>

llothar:

--- Zitat von: crypticvision am 23. August 2007, 13:01:25 ---schlimmen Engpässen führen. Ich brauch hier nicht mal so eine dicke Internetanbindung, aber die Rechenleistung ist manchmal schon heftig. Gerade wenn in Echtzeit Kompression bzw. Dekompression ausgeführt wird. Aber das ist alles noch Zukunftsmusik. Wenns nämlich mit der SF nicht klappt, muß eine große x86 Maschine ran. Oder sogar zwei davon, wegen der Clusterei.

--- Ende Zitat ---

Dann war die 6800 vermutlich ein Fehlkauf. Bei reiner Integer Rechenleistung hättest du in der Tat einen grösseren x86 Server kaufen sollen oder 2 davon wenn du Cluster Redundanz magst.

Na ja als Übungsspielzeug ....

crypticvision:
Mag sein, aber für das Geld gehts doch erstmal. Dafür habe ich von Haus aus volle Redundanz. Und wenn hier alle mein Vorhaben so madig machen, kann ich sie auch wieder verkaufen und wende mich Windows zu. Ich weiß ja nun nicht, ob das im Sinne der hier Beteiligten ist. Ich will nur anmerken, hier haben einige Mainframes zuhause stehen, ohne diese nur ansatzweise profitabel nutzen zu können. Für viele ist es doch die reine Liebe zum Gerät, was ich nicht verübeln kann. Das was ich vor habe, sind bis jetzt ja auch nur Ideen. Erstmal die Maschine dazu bringen, so zu funktionieren, wie ich das gern hätte und dann werde ich weiter sehen.

meik:

--- Zitat von: crypticvision am 23. August 2007, 13:01:25 ---
--- Zitat von: Tschokko am 23. August 2007, 11:50:19 ---Also für den Klassiker Apache+Mysql+PHP ist die Fire meiner Meinung nach die absolut verkehrte Maschine. Ausser du musst einige tausend User gleichzeit bedienen... Ein dicker Oracle Server + J2EE Application Server + SAP R/3 Server + usw. treffen eher den Anwendungsbereich der SF6800.

--- Ende Zitat ---

Das Letztere wird wohl dann der Fall sein, wobei ich anfangs trotzdem aus Kostengründen erstmal lieber MySQL einsetzen werde.

--- Ende Zitat ---

Als Alternative zu MySQL gibt es noch Postgres. Hat vielleicht nicht die riesige Popularität in der OSS-Welt wie MySQL, ist aber bei Solaris dabei. Postgres hat in meinen Augen die Vorteile, dass es einen vernünftigen Query-Optimizer gibt, sodass komplexere Abfragen wesentlich performanter laufen als mit MySQL und scheint auch in vielen Details ähnlicher zu Oracle oder DB2 zu sein als MySQL, sodass ein Datenbank-Wechsel schmerzfreier verläuft.


--- Zitat ---Apache inkl. Perl wird drauf laufen.

--- Ende Zitat ---

Ist im Solaris bereits drin.


--- Zitat ---Die Anwendung an der wir hier schreiben, ist tatsächlich ein ziemlich dicker Brocken. Ich teste derzeit mit wenigen befreundeten Firmen. Die Auslastung kann bei meinem Proliant zeitweise 100% betragen. Wenn nun viele Firmen das Programm einsetzen, was natürlich angedacht ist, könnte es zu Geschäftszeiten zu schlimmen Engpässen führen.

--- Ende Zitat ---

Viele parallele Abfragen sind nicht das Problem, die Frage ist eher, ob das Programm für eine Anfrage mehrere Prozessoren nutzen kann.


--- Zitat ---Ich brauch hier nicht mal so eine dicke Internetanbindung, aber die Rechenleistung ist manchmal schon heftig. Gerade wenn in Echtzeit Kompression bzw. Dekompression ausgeführt wird. Aber das ist alles noch Zukunftsmusik. Wenns nämlich mit der SF nicht klappt, muß eine große x86 Maschine ran. Oder sogar zwei davon, wegen der Clusterei.

--- Ende Zitat ---

Ein UltraSPARC III ist zwar kein Wunder an Rechenleistung, aber 24 (soviele Prozessoren hat die SF6800 im Vollausbau) mal 900MHz sind insgesamt mehr als ein ein einfacher x86-Server mit max. 4 Prozessoren. Klingt so, als könnte das eine gute Übung sein, um eure Anwendung darauf hin zu prüfen, wie gut sie auf Multiprozessorsystemen läuft. :-)


--- Zitat ---
--- Zitat von: Tschokko am 23. August 2007, 11:50:19 ---Nicht aber so wenns an die dicken Geräte von HP geht, sprich HP Integrity, Superdome, HP9000, usw. ;) Man sollte nicht Äpfel mit Birnen vergleichen. Eine HP/Compaq x86 Gurke spielt nicht in der Liga deiner SF6800.

Gruß Tschokko

--- Ende Zitat ---

Was die ganz großen von HP angeht, so denke ich, sind die trotzdem bestimmt genauso servicefreundlich wie die "kleinen" Proliants. Ich habe da keine Erfahrung, kann mir aber nicht vorstellen, daß man bei den Großen anders vorgeht. Ich bin da aber lernbereit.

--- Ende Zitat ---

Das ist bei den großen Kisten überall ziemlich ähnlich. Sun (oder auch HP oder IBM) machen das ja nicht aus Schikane, dass sie entweder gar keine Leute vom Kunden an die Hardware lassen oder nur nach sorgfältiger Schulung, sondern weil das einfach keine Spielzeuge sind. Eine Backplane austauschen zu müssen, weil ein Techniker ein Teil aus versehen falsch eingebaut hat, ist ärgerlich, und wenn da Instanzen drauf laufen, die wichtig sind, für den Kunden auch teuer. Ich kann das gut verstehen, dass da die Hersteller keinen Leute dran lassen wollen, die nach dem Motto arbeiten, wird schon irgendwie klappen...

crypticvision:

--- Zitat von: meik am 23. August 2007, 14:25:16 ---Viele parallele Abfragen sind nicht das Problem, die Frage ist eher, ob das Programm für eine Anfrage mehrere Prozessoren nutzen kann.

--- Ende Zitat ---

Ja, es nutzt soviele Prozessoren wie da sind, da in den meisten Fällen viele Ausgaben gleichzeitig abgearbeitet werden. Ich glaube 24 ist für die Anwendung sogar eine ganz gute Zahl. Im Moment sinds nämlich bei jedem Aufruf ca. 25 Instanzen des Perl Interpreters gleichzeitig. Die werden natürlich bei wenigen CPUs nacheinander abgearbeitet. Je mehr Nutzer gleichzeitig, desto mehr Instanzen stehen in der Warteschlange.


--- Zitat ---Ein UltraSPARC III ist zwar kein Wunder an Rechenleistung, aber 24 (soviele Prozessoren hat die SF6800 im Vollausbau) mal 900MHz sind insgesamt mehr als ein ein einfacher x86-Server mit max. 4 Prozessoren. Klingt so, als könnte das eine gute Übung sein, um eure Anwendung darauf hin zu prüfen, wie gut sie auf Multiprozessorsystemen läuft. :-)

--- Ende Zitat ---

Da stimme ich zu. Also selbst zu Testzwecken recht sinnvoll das Maschinchen. Unsere Anwendung, wenn sie denn mal fertig wird, geht aber nicht außer Haus. Ist ähnlich wie bei ebay. Die benutzen Ihr Websystem auch nur für sich selbst.


--- Zitat ---Das ist bei den großen Kisten überall ziemlich ähnlich. Sun (oder auch HP oder IBM) machen das ja nicht aus Schikane, dass sie entweder gar keine Leute vom Kunden an die Hardware lassen oder nur nach sorgfältiger Schulung, sondern weil das einfach keine Spielzeuge sind. Eine Backplane austauschen zu müssen, weil ein Techniker ein Teil aus versehen falsch eingebaut hat, ist ärgerlich, und wenn da Instanzen drauf laufen, die wichtig sind, für den Kunden auch teuer. Ich kann das gut verstehen, dass da die Hersteller keinen Leute dran lassen wollen, die nach dem Motto arbeiten, wird schon irgendwie klappen...

--- Ende Zitat ---

Kann ich natürlich auch verstehen. Gerade in Firmen, die das Teil produktiv einsetzen, sollte es keine Ausfallzeiten geben. Das da dann keiner probieren darf ist logisch. In meinem Fall hängt aber noch nichts davon ab.

Ich habe übrigens Bilder gemacht. Ich werde die heute Abend hier einstellen. Gibts hier sowas wie einen Bildermanager? Andere Foren haben sowas. Ich muß mal schauen, was geht.

Toktar:

--- Zitat von: crypticvision am 23. August 2007, 16:42:52 ---Kann ich natürlich auch verstehen. Gerade in Firmen, die das Teil produktiv einsetzen, sollte es keine Ausfallzeiten geben. Das da dann keiner probieren darf ist logisch. In meinem Fall hängt aber noch nichts davon ab.

--- Ende Zitat ---

Die xSeries von IBM darf jeder kleine Krauter verkaufen, bei deen Großen Eisen der pSerie muss schon einiges an Schulungen vorhanden sein, um überhaupt so eine Kiste verkaufen zu dürfen, bei der iSerie wird es dann ganz verrückt.
Solande solch eine Kiste als "Spielzeug"* läuft, ist der Support egal. Wenn allerdings Geschäftsprozesse darauf laufen und auch noch Dritte im Spiel sind, wird an einem Wartungsvertrag wohl nix verbeiführen.


*Oracle auf eine SF6800 ist bestimmt der Hammer

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete