ADO/MSSQL mit Multi Prozessor Board

[bernhard_LA]

wir haben eine Clients Server Anwendung mit folgenden Merkmalen

a) ca. 1 Mio .... 50 Mio Datensätze
b) komplexere Mathematische Operationen im Client pro Datensatz
c) Zurückschreiben der geänderten Daten des Clients

wir haben Multi-Threading ADO Zugriff auf die Datenbank und separate Rechnen-Threads im Client implementiert.
Die Erhöhung des Thread Counts von 1 ...6 bringt einen deutlichen Performance-Gewinn, danach bleibt die Ausführungszeit konstant unabhängig von der Anzahl der Threads.

Vermutlich liegt der Flaschenhals am Datendurchsatz der Festplatte. Lohnt sich hier der Aufbau eines RAID 0 Systems , anhand obiger Beschreibung ?

[Lemmy]

Zitat:

Zitat von bernhard_LA (Beitrag 1335727)

Vermutlich liegt der Flaschenhals am Datendurchsatz der Festplatte. Lohnt sich hier der Aufbau eines RAID 0 Systems , anhand obiger Beschreibung ?

Klar - zumindest für euren Lieferanten wird es sich lohnen....

Vielleicht liegt der Flaschenhals auch am billigen Cat4 Kabel das der Admin in seiner verstaubten Kiste gefunden hat und das zufällig die richtige Länge hat ;-) Daher: stellt konkret fest WAS der Flaschenhals ist und behebt dann das Problem - sprich messt während eines Laufs die CPU, Ram, Netzwerk, HDD-Auslastung von Client und Server und fangt an zu analysieren.

[bernhard_LA]

CPU Nutzung < 10 %
RAM Nutzung < 10 %
HDD ~ 40 % der Zeit mit 100 % lt. performance Analysis tool

[jobo]

Erst Zustimmung an Lemmy.
Bei den Angaben die Du insgesamt gemacht hast, finde ich nicht, wieviel Benutzer im Spiel sind.

Ansonsten:
Datenbanken warten (fast) immer auf die Festplatten. Deine Zahlen sind also nicht ungewöhnlich.
Was mich irritiert, alles was Last machen könnte (Berechnung) findet auf dem Client statt. Was quält also
die Festplatten so?

50 Mio ist nicht wenig, aber mit einem RAID 0 verdoppelst Du "nur" die Geschwindigkeit.
Also IO wäre dann nur noch 20% der Zeit auf 100% Last, richtig?

Nichts gegen RAID 0, man könnte das sicher noch mit SSD toppen.
In der Optimierung der Zugriffe softwareseitig liegt meist aber der Schlüssel für eine viel größere Optimierung. Hier spräche man dann nicht von Verdoppelung, sondern von 2 oder 3 stelligen Faktoren.
Diese Zahl ist konkret hier natürlich vollkommen aus der Luft gegriffen, eher ein Erfahrungswert. Manchmal reicht ein Index mehr, manchmal auch einer weniger,.., es ist jedesmal anders.

[Sir Rufo]

Eine Optimierung des Clients kann man mit einer Pipeline hinbekommen die grob wie folgt aussieht:

1. Daten lesen (1 Thread)
2. Daten berechnen (CPU-Count Threads)
3. Daten schreiben (1 Thread)

Dadurch fallen die Wartezeiten beim Lesen/Schreiben nicht mehr ins Gewicht.

[p80286]

Zitat:

Zitat von bernhard_LA (Beitrag 1335727)

wir haben Multi-Threading ADO Zugriff auf die Datenbank und separate Rechnen-Threads im Client implementiert.
Die Erhöhung des Thread Counts von 1 ...6 bringt einen deutlichen Performance-Gewinn, danach bleibt die Ausführungszeit konstant unabhängig von der Anzahl der Threads.

Wenn Du sagen wir 3 Threads für das Holen der Daten und 7 Threads für das Berechnen hast, wundert mich das nicht.
Die Rechenthreads drehen Däumchen während sie auf die Daten warten.

Zitat:

Zitat von bernhard_LA (Beitrag 1335727)

Vermutlich liegt der Flaschenhals am Datendurchsatz der Festplatte. Lohnt sich hier der Aufbau eines RAID 0 Systems , anhand obiger Beschreibung ?

Welche Festplatte? Server oder Client?
Bei der geringen Speicherauslastung (des Servers?) solltest Du unbedingt einmal die Konfiguration der DB prüfen.

Ansonsten kann ich mich nur den Ausführungen meiner Vorschreiber anschließen. Ohne eine vollständige und detailierte Analyse ist das nur ein Stochern im Nebel.
(eine WLAN-Connection mit 47k ist nicht eben eine Autobahn)

Gruß
K-H

[bernhard_LA]

ich habe als Ergänzung den Algo - als PAP dargestellt, es macht hoffentlich unseren Ansatz klar.

Primar habe ich an Info's Tips zum Thema

1. a) Hardware Upgrade
2. b) Sofware Upgrade am MSSQL Server, Konfiguration MSSQL Server

interesse, weil diese Aktionen schnell und mit wenig finanziellem Aufwand verbunden sind.

die Option

• c) neue SW Konzept für unseren Algo

bedeutet eine längere Entwicklungszeit ggf. ohne Nutzen wenn ich schon heute nicht den Flaschenhals verstanden habe. Hier ist die Frage nach einer effektiven Analysemethode.

[jobo]

Also sicherheitshalbe nochmal:
Unter idealen Bedingungen skaliert das System sauber bis 6 Threads.
Der Client hat nichts anderes zu tun?
Der Server hat nichts anderes zu tun?
Die Sessions sind pro Client nicht limitiert?
Das geschieht bei einem Client? Oder auch bei mehreren?
Das ist unabhängig von der Leistungsfähigkeit des Clients?
Es gibt keine "wahrnehmbaren" Störungen im Serverbetrieb (außer der IO Last selbst)?
Gibt es anhaltende Locks auf dem Server?
Wieviel Datensätze werden pro Thread bearbeitet? = 1
Verändert die Berechnung die Auswahlkriterien der Datensätze für den Client bzw. für weitere Threads?
Gibt es administrationsseitig jemand, der Ausführungspläne der Lese und Schreib Anweisungen geprüft hat?

Mich irritiert die Zahl 6, sofern sie immer konstant bleibt, wie hier dargestellt.
Hat die Zahl 6 etwas mit den komplexen Berechnungen zu tun?

[jfheins]

Zitat:

Zitat von jobo (Beitrag 1335823)

Mich irritiert die Zahl 6, sofern sie immer konstant bleibt, wie hier dargestellt.
Hat die Zahl 6 etwas mit den komplexen Berechnungen zu tun?

Sie könnte mit der Anzahl an CPU-Kernen zusammenhängen. Bspw. bei einem 5820k würde ich über 6 Thread keine signifiaknten Zuwächse mehr erwarten.

Wenn es wirklich an der HDD liegt (aber wer hat heutzutage noch io intensive Datenbanken auf magnetischen Speichermedien??) sollte das Problem mit einer Samsung 950 Pro für die Datenbank erledigt sein, um hier mal eine konkrete Empfehlung zu äußern.

[frankyboy1974]

Hallo,

wenn ich lese, dass laut PAP die Berechnung circa eine Sekunde dauert, würde ich vermuten, dass der Flaschenhals dort liegt und nicht im I/O Bereich. Mein erster Gedankengang war, zu empfehlen, die Berechnung direkt auf der Serverseite auszuführen (gespeicherte Prozedur) und somit zumindestens die Netzwerkkommunikation einzusparen, aber das würde die Berechnungszeit natürlich nicht grundsätzlich verändern. Wenn man den Berechnungsalgo nicht wirklich mehr optimieren kann, würde natürlich schnellere Hardware, ggf. mehrere Clients die parallel die Arbeit verrichten, helfen den Zeitaufwand zu minimieren.
Bei einer Berechnungszeit von 1 Sekunde, würde ich mir den Berechnungsalgo allerdings auch noch einmal anschauen, ob da nicht doch ein wenig Optimierungspotenzial drinne steckt.

mfg