10Gbit Client/Server SQL?

Sebbl2k schrieb:
[...]aus der praxis.
Aus der Praxis heraus würde ich Niemanden an Server lassen, dessen erste Antwort auf die Frage "wie kann die Performance verbessert werden" nicht ist "da schau ich ins Monitoring, dann kann ich eine Aussage treffen".
Gibt es kein Monitoring würde ich auch erwarten, dass etwas in der Art wie: "Das ist große Scheiße, ab Morgen kümmere ich mich darum, dass Monitoring läuft" kommt.

Mit Monitoring ist es dann recht simpel. Irgendwer beschwert sich, dass etwas Lange dauert. Pluspunkte gibt es, wenn genau benannt werden kann was lange dauert und wann etwa diese Aktion ausgeführt wurde. Dann macht man sein Monitoring mit History vom Server auf und schaut hin.
  • Auslastung NIC >60% für ein oder mehrere Sekunden -> Anbindung optimieren
  • CPU Auslastung auf vielen oder einzelnen Kernen hoch -> Da sollte man mal schauen wieso das so ist, ob sich da etwas sinnvoll beschleunigen lässt (Datenbankoptimierung, Parallelisierung von Aufgaben, Geld auf bessere CPU werfen)
  • I/O Wait mit hohem Anteil -> Ursache suchen
  • Speicherauslastung >60-80% Mehr Speicher und mal schauen dass nicht irgend ein Prozess sinnlos Speicher reserviert

Wer stattdessen Onlineforen befragt ohne echte Infos zu liefern, sollte Kehrdienst bekommen und gegebenenfalls ne gescheite Fortbildung zur Adminstration -.-
 
@holdes
der skysnake hat es unterstellt..
welches tool nimmt man da am besten zum messen der nic (windows server) und i/o wait? der taskmanager soll ja nicht immer das gelbe vom ei sein.
der server ist nicht virtualisiert und verteilt auch software an die clients. aber es geht mir, wie gesagt, hier nur um „kleine“ aber viele sql-pakete.
zur umgebung stehen da schon einige sachen.
streng genommen brauchte ich das monitoring bisher nicht.. da ich ohnehin nicht mehr grosse (technische) möglichkeiten habe und das system ziemlich performant läuft. zumindest im vergleich zu vergleichbaren umgebungen.
eine san für xxx.xxx euro steht nicht in relation.
 
Zuletzt bearbeitet:
Nein, zur Umgebung steht da fast nichts....

Wenn es keine Probleme gibt, dann gibt es auch nichts zu tun. Versteh mich nicht falsch, aber es scheint nicht so zu sein als ob du wissen würdest ob es ein Problem gibt, und wenn ja unter welchen Randbedingungen.

Es wurde schon mehrfach versucht dir zu sagen, das alles mögliche die Ursache für ein Problem sein kann. Das wird man aber nur sagen können, wenn du eben alles mögliche überwachst.

Wie schon gesagt wäre ein erster Schritt mal das Monitoring der Nics, Mem, CPU usage, interrupts, IO usw. Am Besten im Intervall von 1s.

Aber auch dann, selbst wenn es da hin und wieder Probleme gibt, kann es total egal sein, oder dramatisch.

Habt ihr z.b. SLAs die ihr einhalten müsst? Hast du bisher überhaupt nichts zu gesagt. Das ist aber entscheidend...

Für nen SQL Server wäre z.b. durchaus nützlich zu wissen was die Responce time ist. Das würde man z.b. mal alle 60s über ne simple Abfrage Monitoren, oder halt auch jede Sekunde, je nachdem wieviel Info ihr braucht...

Aber gerade bei Mehrfachnutzung eines Systems muss man halt auch mit mehr Randbedingungen testen...
 
  • Gefällt mir
Reaktionen: nosti
Nein, kein SLA.
Ich probier dann mal das Windows Admin Center aus… mal schauen ob es da in den Sql-Stosszeiten irgendwo klemmt.

ich wollte wissen, ob das ohnehin schon schnelle system dadurch noch schneller wird. mit problemen hat das ja wenig zu tun.

probleme wären für mich timeouts oder lange wartezeiten.. aber das trifft ja nicht zu.
 
Kann ich schneller auf einer leeren Autobahn fahren wenn ich ne zweite daneben baue?

Also ich bin erst mal raus. Keine Ahnung was du willst.
 
ja, wenn auf der zweiten kein stau ist :-).
 
Für generelle Zustands- und Performanceinformationen zum SQL-Server kann man u.a. die Blitz Tools nutzen.
https://www.brentozar.com/blitz/

Allerdings sollte man schon ein wenig Hintergrundwissen haben.

Kommt eben auch ganz auf die Konfig vom Server und die Struktur der Datenbanken an. Du kannst die beste Hardware nehmen und einen lahmen Server draus machen, nur durch sinnfreie Datenstrukturen, fehlende Indizes und eine mangelhafte Installation.
Für gewöhnlich sollte das Netzwerk, ohne Log-Shipping, nicht das Problem sein. Der Client feuert nur ein paar SQL Befehle ab. Die Antwort vom Server kann natürlich Quark sein, aber bei den SQL-Servern die ich bisher gesehen habe, war die Ursache für grottige Performance eher auf dem Server zu suchen.
 
Zurück
Oben