Performance auf HP Proliant Servern mit SLES9

[Dellerium]

Hi!

Ich wollte mal rumfragen, ob jemand im Forum ist, der ebenfalls Probleme mit Suse SLES 9 hat?

Unser Problem ist das folgende:

Wir haben hier diverse HP Server stehen ( die meisten DL380 G3 mit 4 GB Ram, sowie einen HP Package Cluster mit 6GB Ram und einer MSA500 G2. Ausserdem einen Dual Opteron ( mit Dual-Core Prozessoren ) mit 16GB Ram der als Datenbank Server fungieren soll. :D

Auf allen Servern ist SLES9 installiert ( x86_64 ) - und auf allen Servern ist die Performance grausam.

Wir haben weiter einen Testserver auf dem zur Zeit eine Anwendung installiert wird - zum testen reicht uns ein Desktop Rechner auf dem wir entwickeln können ( Athlon XP 2400+ mit 3GB Ram ).
Das ist auch der Grund weshalb wir die Performance Probleme überhaupt erst bemerkt haben - denn diese treten nicht immer auf. So sind die Maschinen beim Kompilieren z.B. richtig schön schnell (und daher bemerkt man die Probleme nicht unbedingt ).

Aufgefallen ist das Problem beim Einsatz einer PostgreSQL Datenbank.

Wir haben in der Anwendung teilweise verdammt große Statements mit einem Haufen InnerJoins die richtig Last verursachen und bei Tabellen mit mehreren Millionen Einträgen schon ein bissel Zeit brauchen. Test auf dem Testserver ( Athlon XP ) brauchen ca. 25sec.

Also wir die neuen Server in Betrieb genommen haben, sowohl den Cluster wie auch das Dual Opteron System, haben wir allerdings eine Überraschung erlebt - diesselbe Abfrage brauchte auf dem Opteron 2:40min! :eek: Der Cluster ist auch nicht schneller. ( Die PostgreSQL Datenbank ist auf beiden Systemem noch nicht optimiert worden, aber das dürfte eigentlich keinen solchen Unterschied ausmachen ).

Also - ein bissel ungläubig wird man da schon. Also haben wir den Fehler gesucht und keinen gefunden. ( Außer das ich die Befürchtung hatte, das der Suse Kernel ( 2.6.5 - der kam im Jahr 2004 das erste Mal heraus ) daran evtl. nicht ganz unschuldigt ist. Unser Problem ist jedoch, dass insbesondere auf dme HP Package Cluster nur SLES oder RHES eingesetzt werden kann - weil ansonsten die HP Software nicht läuft.

Also habe ich einmal testweise ein Gentoo ( 2006.0 ) mit einem frischen 2.6.16er Kernel auf dem Opteron System installiert - der Performanceunterschied ist phänomenal: Das Statement braucht 8sec!

Mich würde einmal interessieren, ob es hier jemanden gibt, der ebenfalls Probleme mit der Performance auf HP Server ( oder allgemein 64 Bit Systemen ) in Verbindung mit dem SLES festgestellt hat?

Ich hab zwar geschaut, ob ich einen aktuelleren Kernel bekommen kann, aber mein PRoblem ist ja auch, das die HP Software von Suse abhängig ist, und ich daher garnicht so einfach Updaten kann :mad:

Daten:

HP Proliant DL385 ( ich meine G3 - die aktuellste Version halt )
2x AMD Opteron model 280 2.4GHz - 1MB L2 dual-core
16GB Ram
2x 36,4GB @ 15k
2x 72,8 @ 10k


SLES9 SP3: ( You Update komplett durchgelaufen, alle Patches sind eingespielt )
x86_64
Kernel 2.6.5-7.252.smp
Postgres 8.1.2 ( Paket vom Suse FTP )

Gentoo:
Profil 2006.0
Kernel 2.6.16-gentoo
Stage3 Archiv, CFlags auf march=opteron gesetzt und O2 als Optimierungsgrad, ansonsten keine weiteren Flags zu "Optimierung" ( Wozu auch )...
Postgres 8.1.3

Gruß Delle

[heatwalker]

Habt Ihr Euch mal die Kernel Config angeschaut, welche Prozessorunterstützung Suse hier eingebaut hat??

Da könnte vielleicht das Problem liegen.

Wie sieht es mit den Unterstützungspaketen von HP aus. Sind die installiert???
Sollte zwar nicht unbedingt was mit der Performance zu tun haben,
aber HP baut hier schon mal ein paar Verbesserungen ein (-:

[bla!zilla]

Meint ihr mit Unterstützungspaketen die PSP für SLES? Wenn ja, die sind für die Performance absolut nicht kriegsentscheidend.

- Welche Version von PSQL wird genutzt?
- CPU Auslastung der Maschine beim Import?
- Was sagt "hdparm -tT /dev/cciss/c0d0p0"? (bitte mal die verschiedenen Platten testen... also c0d0p anpassen)
- RAID Level für DB RAID und System?
- Wie verhält sich das System bei der CPU Auslastung? Wieviele % von den 100% sind User oder System? Bitte auf den Punkt "wa" bei TOP achten. Evtl. wartet die Kiste auf irgendwas.

Jetzt noch was ganz Dummes: Bitte mal den SmartArray übergehen und die Platten als Software-RAID einrichten und testen. Aktuell geht eine Befürchtung um, dass es Probleme mit dem CCISS Treiber im Kernel gibt (miese Performance). Dazu mal ein Thread aus HPs ITRC (http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=952802) welches sich sehr nach eurem Problem anhört.

ES HANDELT SICH ABER UM EIN KERNEL - KEIN HARDWAREPROBLEM! :)

Aus eigener Erfahrung kann ich nix sagen - bisher keine Performanceprobleme in der Kombination. Mache aber auch nix mit PSQL.

[Fly]

Nutze ebenfalls DL360 G4 mit Intel CPU und PSQL8. Jedoch ist mein SLES mit SP2 und 32 Bit. Die Daten liegen am SAN. Und habe kein Performance Problem :-)

[bla!zilla]

Kurze Info noch von mir: Nutze ebenfalls nur die 32 Bit Versionen des SLES.

[Dellerium]

Schön das sich so viele gemeldet haben =)

@heatwalker:

Es ist die letzte Version die Suse für den SLES anbietet - eingespielt über YOU. SPident sagt, das ca. die Hälfte auf SP3 basiert - der Rest auf SP0-2 Paketen.

Ich vermutet ja ebenfalls ein Kernelproblem. Der Suse Kernel ist ja ein 2.6.5-XXX. Ich weiss, das Suse Features zurückportiert, aber ich hab irgendwie die Vermutung, das der Dual Core Opteron nicht richtig unterstützt wird. Keine Ahnung ob da evtl. die Verteilung der Arbeit nicht vernüftig klappt....
Mit einem aktuellen 2.6.16er rennt die Kiste so wie ich das erwartet habe.

Ich hab mal nachgeschaut - der Kernel 2.6.5 wurde erstmals 2004 released und der Support von Dual Core kam erst später.


@bla!zilla

Die Unterstützungspakete ( Proliant Support Pack ) sind zwar nicht für die Performance entscheident, aber ich will da trotzdem nicht drauf verzichten, weil ich schon gerne die Funktionen der Software nutzen will ( Benachrichtung bei Problemen etc - kennst du ja :) )

Auf dem Suse System habe ich eine Postgresql Version 8.1.2 laufen lassen ( Wird von Suse auf dem FTP bereitgestellt.

Unter Gentoo lief eine 8.1.3 - aber bei den Versionen gibt es keine so gravierenden Unterschiede. Wir haben hier diverse Version von 8.0 - 8.1.X im Einsatz - es gibt zwar leichte Abweichungen, aber keine die die Abweichung um den Faktor 20 erklären. Ich bin mir _sehr_ sicher, dass es kein Problem mit der Datenbank selber ist.
Beim Import der Daten hat die Maschine insgesamt knapp 25% Auslastung - eine CPU hat halt 100%, der Rest idled größtenteils vor sind hin. Ab und zu haben halt auch die anderen Prozesse was zu tun. backgroundwriter der Datenbank etc...

Die Platten sind schnell - ausserdem schiebt Linux die Daten der Datenbank locker in den Dateisystemcache ( die DB hat eine Größe von ca. 1,5 GB - bei 16GB Ram sind bisher immer noch knapp 10GB frei gewesen.
( Der angesprochene Test bei dem ich die Performance Probleme festgestellt habe greift nur lesend auf die Datenbank zu - die Geschwindigkeit mit der die Platten Daten wegschreiben müssen kann da also kein Problem verursachen. Der Linuxdateisystem Cache hingegen sollte hier voll zur Geltung kommen - afaik )

Den Test mit hdparm mache ich Dienstag nochmal - hab ich bisher nicht gemacht, weil die Performance auf den Platten subjektiv gut war.

Datenbank und System liegen jeweils auf einem Raid1 - ist vielleicht nicht optimal, aber da die Datenbank selber recht klein ist ( 1,5GB und keine 20 oder 30 GB ) wird eh nur sehr selten von den Platten gelesen. Von daher mache ich mir da eigentlich keine Sorgen - falls du da trotzdem nen Tipp hat, raus damit =)

Das System liegt auf 2 36er Platten mit 15k Umdrehungen. Die Datenbank liegt auf 2 72 GB Platten mit 10k Umdrehungen.
pg_xlog liegt auf eine zweiten Partition auf den Systemplatten - ist also von den Daten der Datenbank getrennt. ( nur für den Fall das die Datenbank sehr viel schreiben muss)

Wegen des Threads im HP Forum - das hört sich nicht nur nach dem Problem an, das _ist_ unser Problem - ich habe den Thread im HP Forum geöffnet :D
Wo wir gerade beim dem HP Threads sind - auf dem Cluster hatten wir ebenfalls Probleme mit der MSA500G2 - wir haben dort einen Firmfehler festgestellt. Wir hatten - zu Testzwecken - die Einstellung von Read/Write Cache Ratio auf den 50%/50% der HP Voreinstellung belassen. Werden die Platten dann stark belastet - z.B. mit Bonnie schmiert die MSA500G2 reproduzierbar ab! Wir hatten reichlich Rücksprachen mit HP ( und sehr viele Techniker vor Ort ), und die wollen nun evtl. einen Patch dazu rausbringen....

Wie gesagt, ich denke auch, das es ein Kernelproblem oder Treiberproblem ist - die Hardware ist schliesslich unter Gentoo verdammt schnell. Als ich den Test unter Gentoo gefahren habe, habe ich zuerst befürchtet, das ich nur einen Teil der Daten importiert habe. Eben weil es so verdammt schnell lief.

Das Problem ist halt im Moment, das wir nicht nur den Datenbank Server habe - den man ja zur Not ohne Probleme mit Gentoo oder Debian betreiben könnte - sondern auch den HP Package Cluster. Und die HP Cluster Software läuft halt nur auf SLES oder RHES :( Und die HP Software will sich wiederum an den Suse Kernel hängen - ob das mit einem Vanilla Kernel geht habe ich noch nicht getestet, aber irgendwie ahne ich da Böses...

@fly & bla!zilla:
Ich habe Donnerstag ( hatte gestern frei =) ) auch schon überlegt, ob ich die Suse Testpartition nochmal lösche und die 32bit Version installiere. Eben um zu testen ob das Problem nur im Betrieb mit 64bit auftritt...

Ich werde hdparm nochmal testen und in der zweiten Partition nocheinmal SLES als 32 Bit Version installieren

Gruß Delle

[bla!zilla]

Ich hatte mir schon sowas mit dem Thread gedacht. :rolleyes: An euer Problem mit der MSA500G2 kann ich mich noch erinnern, da hatten wir uns ja mal via PM drüber unterhalten.

Wie schon gesagt: Testet es mal mit der 32 Bit Version. Hattet ihr mal darauf geachtet ob das System auf I/O wartet (unter "top" der Wert bei "wa")?

[Dellerium]

Ich hatte mir schon sowas mit dem Thread gedacht. :rolleyes: An euer Problem mit der MSA500G2 kann ich mich noch erinnern, da hatten wir uns ja mal via PM drüber unterhalten.

Wie schon gesagt: Testet es mal mit der 32 Bit Version. Hattet ihr mal darauf geachtet ob das System auf I/O wartet (unter "top" der Wert bei "wa")?

Jupp - wenn ich ein Dump einspiele, dann hat der Datenbank Server waitio. Zumindest, wenn ich vorschreibe, das er fsync=on hat, also die Daten sofort auf die Platte schreiben muss. Ich ja irgendwo auch klar.
Wenn ich z.B. die angesprochenen Statements laufen lasse, dann tritt aber so gut wie nie waitio auf - von daher gehe ich davon aus, das es ein Kernelproblem ist. Die Datenmengen sind in meinen Augen einfach zu gering, als dass die Platten das System soweit bremsen können. Außerdem liegen die Daten nach recht kurzer Zeit vollständig im RAM.
Ich werde mir das aber nochmal anschauen.

Mal schauen was ein 32bit Suse sagt =)

Gruß Delle