Speedproblem

[mr.no-name]

Klar, parallel bei einer Anfrage - also bei großen sequenziellen Zugriffen sehr gut, da dadurch die Transfergeschwindigkeit gesteigert werden kann.
Aber wie fdsonne in seinem letzten Beitrag schon meinte, spielt das bei kleinen Zugriffen keine Rolle.

Es kommt in deinem Fall wohl wirklich nur auf die Zugriffszeit an, und die wird durch Raid-0 nicht besser - aber mit SSDs bist du dann ja auf jeden Fall gut genug bedient

 

[ottidsl]

ad garantie bei der x25e: http://support.intel.com/support/ssdc/hpssd/sb/CS-029645.htm

Die kochen wie die Indilinx-Drives mit SLC auch nur mit Wasser bei Intel! Drum gibts auch nur 3 Jahre Garantie bei gleicher Leistung(wie z.B. das Ultradrive LE) und deutlich geschmalzenerem Preis

und ad raid 0: Bei deinem Problem geht es doch nie und nimmer um sequentielle Zugriffe sondern schlicht und ergreifend um die Performance bei 4K und random und ähnlichem => du kannst so viele Platten für den Raid nehmen wie du willst, deswegen erhöht sich höchsten das Ausfallsrisiko

---------- Beitrag hinzugefügt um 19:48 ---------- Vorheriger Beitrag war um 19:43 ----------

nicht zu vergessen zählt die Zugriffszeit (eigentlich is die fast noch wichtiger)

 

[Elrond der 2te]

Wie gesagt, ich würde nicht damit experimentieren, SSDs sind noch nicht lange genug am Markt um beurteilen zu können wie Langlebig die Dinger wirklich sind, vorallem in einen Produkttivserver würde ich nix anderes als echte (nicht diese Desktop pseudo RAID Editions) SAS Drives stecken...

Was mir ein wenig Spanisch vorkommt ist, das im Eingangspost geschrieben steht das der TE die Maschine selbst zusammengestellt hat & jetzt muss er plötzlich den Admin Fragen was für ein RAID Controller da drin ist??? Meiner Meinung nach handelt es sich bei dem Array entweder um ein SW Raid oder um ein Fakeraid per onBoard SAS ohne XOR & BBU... Geschweige denn das 3 Platten für ein Raid 5 die absolute Untergrenze darstellen (und bei einem Ausfall läuft die Geschichte solange Degradet bis man ne Ersatzplatte einbaut geschweige denn das es überhapt noch lebt mit 2 Platten..). Bei 50-120 User würde ich unter 6 + 1 Hotspare Platten gar nicht anfangen bzw. sogar noch eine Cold Spare Platte nehmen (da der Server ja zusammengefrickelt ist....)

 

[future_former]

Es muss ca. einmal die Woche eine Verarbeitung aufgerufen werden die ca. 5000 kleinigkeiten erledigt. Ich habs gestern diese verarbeitung mal gestartet und hab endlich rausgefunden warum das 1. ewig dauert und 2. der Server dabei müde lächelt.
Die DB liegt wie geplant auf dem RAID 5 mit 3 Platten, nun ist es so das das Programm lauter sehr kleine Datensätze in der DB abruft. Das heist die Platten suchen sich zu tode, ich hab eine durchschnittliche R/W auslastung der Platten von 1Mb/s. Die Platten schafen aber ca. 120Mb/s :-S, die CPU`s dümpeln irgendwo bei 5-10% und der RAM füllt sich mit gigantischen 2Gb`s
Das selbe ist es im normalen Betrieb wenn ca. 50 Leute in dem Programm arbeiten.
Das Problem ist das die Platten garnicht genug Daten zum Lesen oder Schreiben bekommen um mal richtig Gas zu geben und das dauernde abgreifen von kleinigkeiten frist unglaublich Performance.

ich bin leider kein SQL freak, aber ich würde da vor irgendwelchen massiven hardware-upgrades erst auf software-seite nach einer lösung suchen und daher zuerst mal

1.) die datenbank regelmässig (autonmatisiert) konsolidieren, z.B. nachts
2.) den datenbank-cache massiv vergrössern (und damit zusammenhängend den arbeitsspeicher ausbauen).

je nach hardware könnte ein RAM-ausbau auf 16 GB oder mehr sinnvoll sein, wenn maximale DB-performance wichtig ist. die anfragen werden dann soweit möglich erstmal vom RAM verarbeitet und neue informationen sukzessive in grossen portionen auf die platten geschrieben, was controller und disks schon mal ein gutes stück entlastet, da sie nicht mehr jede anfrage direkt verarbeiten müssen, stichwort: I/O.

in diesem falle ist es allerdings unerlässlich, dass der RAID-controller und der server selbst batteriegepuffert sind (alos USV vorschalten !), sonst ist die datenbank bei stromausfall ziemlich im eimer.


future_former

 

[N-Traxx]

Was mir ein wenig Spanisch vorkommt ist, das im Eingangspost geschrieben steht das der TE die Maschine selbst zusammengestellt hat & jetzt muss er plötzlich den Admin Fragen was für ein RAID Controller da drin ist???

Moin,

Nein, das läuft etwas anders. Ich arbeit für ein Softwareunternehmen und er Server steht bei einem Kunden. Ich setze denen eine Empfehlung auf, z.b. min. die CPU, die und die Platten, wieviel RAM mit der geschwindigkeit. usw... und geb das weiter. Und die kaufen dann zwei nummern kleiner und haben dauernd Speedprobleme. Die Kiste ist ein 19" Dell Server, mit den Komponenten die ich im ersten Post geschrieben habe. Aber leider hab ich keine Ahnung was da für ein Controller drinnen ist.

---------- Beitrag hinzugefügt um 10:29 ---------- Vorheriger Beitrag war um 10:26 ----------

ich bin leider kein SQL freak, aber ich würde da vor irgendwelchen massiven hardware-upgrades erst auf software-seite nach einer lösung suchen und daher zuerst mal

Das läuft schon alles, die DB wird auch regelmässig defragmentiert. Das einzige was jettz ist, es läuft noch SQL2000 der wird aber getauscht auf 2005 wenn endlich mal die Lizenz da ist.

 

[Elrond der 2te]

@ N-TRaxx: Das ist nat was anderes.. Als ich im Startpost gelesen habe Selbst Zusammengestellt dachte ich es handelt sich um einen Marke Eigenbau Server..... Wäre jetzt halt interessant was in dem Server für ein Controller drinn ist bzw. wie das RAID konfiguriert ist.. Ich denke das da der Hund begraben liegt in Kombination mit den nur 3 RAID 5 Platten.. Was ich mir vorstellen könnte ist, das z.B durch eine falsch Konfigurierte Strip size des RAID 5 Arrays dieses bei der Verteilen Abfragen im KB Bereich innerhalb der DB an seine Grenzen stößt...

 

[jni]

Das Problem wird wohl hauptsächlich an fehlenden/falschen Indexen der Datenbank liegen. Da muß mal jemand ran, der sich mit MSSQL auskennt und auch ein wenig mit der konkreten Anwendung und die DB mal tunen. Mit massiver RAM-Aufrüstung läßt sich das Problem sicher auch lindern ist aber nicht so sinnvoll.

Trotzdem noch ein paar Fragen zur Konfig:
- liegen DB-Files und Log-Files auf physisch verschiedenen Laufwerken ? Log-Files auf dem Systemlaufwerk geht auch OK.
- sind die DB- und Log-Dateien selber einigermaßen defragmentiert ?
- nutzt der SQL 2000 als 32-Bit-Programm die kompletten 8 GByte RAM im AWE-Modus ?
- wie hoch ist die CPU-Last während der laufenden Anfragen ?

Wir haben auch ein SQL 2000 in ähnlicher Größe und Nutzerzahl laufen auf deutlich schwächerer Hardware. Das geht eigentlich ganz gut - natürlich mit ordentlich konfigurierten Indexen.

 

[N-Traxx]

Das Problem wird wohl hauptsächlich an fehlenden/falschen Indexen der Datenbank liegen. Da muß mal jemand ran, der sich mit MSSQL auskennt und auch ein wenig mit der konkreten Anwendung und die DB mal tunen. Mit massiver RAM-Aufrüstung läßt sich das Problem sicher auch lindern ist aber nicht so sinnvoll.

Trotzdem noch ein paar Fragen zur Konfig:
- liegen DB-Files und Log-Files auf physisch verschiedenen Laufwerken ? Log-Files auf dem Systemlaufwerk geht auch OK.
- sind die DB- und Log-Dateien selber einigermaßen defragmentiert ?
- nutzt der SQL 2000 als 32-Bit-Programm die kompletten 8 GByte RAM im AWE-Modus ?
- wie hoch ist die CPU-Last während der laufenden Anfragen ?

Wir haben auch ein SQL 2000 in ähnlicher Größe und Nutzerzahl laufen auf deutlich schwächerer Hardware. Das geht eigentlich ganz gut - natürlich mit ordentlich konfigurierten Indexen.

Hallo, steht schon allen im Thread.
SQL 2000 schafft nur max 4Gb RAM. Und das auch nur mit einem Patch, standardmässig kann SQL 2000 nur mit 2Gb etwas anfangen.

http://support.microsoft.com/kb/274750

EDIT:
Eine regelmässiger defrag und reindex läuft schon bei der DB.

---------- Beitrag hinzugefügt um 06:56 ---------- Vorheriger Beitrag war um 06:46 ----------

Ich denke das da der Hund begraben liegt in Kombination mit den nur 3 RAID 5 Platten.. Was ich mir vorstellen könnte ist, das z.B durch eine falsch Konfigurierte Strip size des RAID 5 Arrays dieses bei der Verteilen Abfragen im KB Bereich innerhalb der DB an seine Grenzen stößt...

Das würde sich ja Testen lassen, wie wären den die Einstellungen ? Ich bring heute hoffentlich noch in erfahrung was für ein Controller da drinnen ist.

EDIT2:

So die Controllerdaten:
http://pics.traxxtec.de/RAID_1.jpg
http://pics.traxxtec.de/RAID_2.jpg

---------- Beitrag hinzugefügt um 08:09 ---------- Vorheriger Beitrag war um 06:46 ----------

So jetzt hab ich auch die Einstellung von dem RAID 5 und musste feststellen das Write-Back nicht aktiviert ist.

http://pics.traxxtec.de/RAID_3.jpg

Was soll ich den genau einstellen lassen ?

grüße

 

[Elrond der 2te]

Zudem ist Adaptive Read Ahead + der Cache des Controllers disabled (wenn direkt bedeutet das der Cahce der Platten verwendet wird...), die 64KB Stripesize sollte nicht das Probem sein... Ich würde den Writeback Cache (BBU und/oder USV Vorhanden?), Adaptive Read Ahead (Beschleunigt Lese Zugriffe) sowie den Controller Cache Einschalten (so wie es aussieht wird der nicht verwendet, das Ding hat 512MB...) Bevor am Array/Controller was verändert wird auf jeden fall noch vorher ein Backup anlegen..

 

[N-Traxx]

So jetzt ist Wirte-Back auf immer
lesemodus ist auf read-ahead
Cache Modus steht auf Cache
Und der HDD Cache ist auf aus, braucht ja keiner wenn der Controller Cachet.

Ob das nun was bringt erfahre ich die nächsten Tage.

grüße

 

[ottidsl]

Naja so wie der Raid konfiguriert war könnte das eventuell gereicht haben für eine spürbare Leistungssteigerung.

Was ich aus deinen Pics nich rauslesen kann: Hat das Ding ne BBU? Ich hoffe schon ohne könnte es trotz USV doch noch ungemütlich werden.

 

[N-Traxx]

Was ich aus deinen Pics nich rauslesen kann: Hat das Ding ne BBU? Ich hoffe schon ohne könnte es trotz USV doch noch ungemütlich werden.

Ich denke Ja, auf jedenfall kann man "immer Write-Back unabhängig vom BBU zustand" einstellen. uns so willd kann es nicht werden, es wird ja jede Nacht ein DB Backup gefahren.

 

[ottidsl]

ad so wild kanns nicht werden: Naja ein degradede array der grade einen rebuild macht sorgt dir dann aber sicher für nen ordentlichen Leistungseinbruch.
Ich würde ne bbu wenn nicht schon vorhanden ans herz legen! Kostet nicht die Welt und spart auf jeden Fall Ärger.

 

[Elrond der 2te]

Normalerweise müsste man im Raid Utility den Status der BBU (wenn vorhanden) abrufen können bzw. müsste das Util beim Umschalten von Write Through auf Write Back darauf hinweisen das keine BBU vorhanden ist (Ist bei LSI Controllern normalerweise so) Solange aber eine USV vorhanden ist, sollte die BBU eigentlich überflüssig sein, da sie ja bei einem Stromausfall nur den Cache mit Strom versorgt.. Je nachdem wie das RAID jetzt performt und wie viele Hot Swap Schächte in dem Server noch vorhanden sind, würde ich noch Mindestens 2 Platten hinzufügen (eine davon als Hotspare)

 

[ottidsl]

Dass er ne usv hat da bin ich mir ziemlich sicher(wer hat schon ne produktiv umgebung ohne)! Trotzdem hilft ihm ne USV wenig, wenn er sich sein Server mal ordentlich abschießt und resettet werden muß

 

[Elrond der 2te]

Da hast recht, hab ich jetzt nicht berücksichtigt............

 

[jni]

@N-Traxx

ALso der SQL server 2000 kann definitiv min. 16 GByte per AWE benutzen - halbwegs aktueller Patchstand vorausgesetzt (SP4). Das OS ist bei uns Windows 2003 Server x86 (muß wohl ne Enterprise Edition sein).