Performance counter

C

Chuky666

SQL-Guru
Beiträge
165
Nabend zusammen :)

Wir haben im icinga etliche checks die diverse Performance counter usw. vom sql Server abfragen. Ich bin letztens über batch request/sec gestolpert und tu mich etwas schwer dieses counter richtig zu deuten. Gelesen habe ich das dieser counter alleine eher nicht soviel aussagt über einen potenziellen Flaschenhals. Ich finde aber leider keine baseline die aufzeigt was man im Zusammenhang mit dem counter im Auge haben sollte. Hat vllt. einer von euch diesbezüglich Erfahrungen die er/sie teilen möchte? :)

Viele Grüße und bleibt gesund
 
Werbung:
Das ist m.E. keine klassische Datenbankthematik, sondern wird spezifisch von Icinga oder ähnlichen Systemen verwaltet.
M.E. ist es bei vielen solcher Indikatoren so, dass man sie nur im Vergleich zu anderen Countern, anderen Systemen oder über den Zeitstrahl vergleichen kann.
Geht ein Wert signifikant rauf /runter, gibt es ein Problem, ein System hat sich oder wurde runtergefahren usw.

batch request/sec kann m.E. irgendwas sein, mit ganz unterschiedlichem Durchsatz. Ich setze aber icinga nicht ein und kenne es nur vom Ausprobieren.

Mein Ansatz für Flaschenhalsfindung sind OS Tools wie sar z.B. unter linux, wo die zentrale Belastungsfaktoren zyklisch ausgegeben werden.
 
Mhh.... Das stimmt so nicht ganz. Batch request/sec ist ein sql server counter. Icinga habe ich nur erwähnt, weil wir damit Monitoren. :) Der counter allein sagt leider nichts aus. Ein System kann bei 1000 batch requests per seconds sind langweilen und ein anderes ist damit hoffnungslos überfordert. Mein Problem ist das es wohl noch andere counter gibt die man in diesem Zusammenhang beachten sollte, nur weiß ich leider nicht welche.
 
Gut, dass es batch req/sec auch beim SQL Server gibt, ist jetzt nicht ungewöhnlich, ich sag ja, das ist eine ziemlich allgemeine Bezeichnung.
Ich arbeite auch nicht mehr mit SQL Server, es gibt dort mit Sicherheit massig Indikatoren, seitens OS und auch spezial für SQL Server.

Ich glaube auch nicht, dass die Frage so allgemein zu beanworten ist. Wie Du selbst sagst, können die einen Systeme sich langweilen, die anderen sterben, bei gleicher Anzahl batch requests. Es ist wie gesagt immer naheliegend auf den Durchsatz Bytes im IO zu schauen, auf korrespondierende CPU Werte, usw.
Wenn Du deinen Counter besser einordnen willst, müsstest Du bspw. die Bytes per Request wissen, die geschrieben, gelesen werden, durch die CPU gehen, im Buffer getauscht werden,..

Wenn Du ein lahmes DB System hast, und das System ist neu aufgesetzt oder sogar neu erfunden oder in neuer Einsatzsituation, läge das Vorgehen m.E. nicht in in solchen pauschalen Tools, sondern in der Analyse langsamer oder blockierender Queries.
Speziell bei SQL Server gibt oder gab es immer so Stories mit Row Level Locking und Page Locking bis hin zu Table Locks, die je nach Druck auf dem System umgeschaltet werden (Lock Eskalation). Wenn Du mit dem System einmal in die Nähe dieser Grenzbereiche kommst (letztlich mit jedem), gibt es immer massivere Nebeneffekte für Prozesse, die sich um die gleichen Daten kloppen. Mit genug Pech wird das Update einer einzelnen Zeile zur nerver ending story, weil das System bereits aus dem Row Level Locking raus ist und es sich "bequem" macht mit Page oder Table locks. Es blockieren sich also eigentlich nicht konkurrierende Zugriffe.

Neue Systeme brauchen idR bei hinreichender Grösse und Last auch Zeit sich einzuschwingen. Moderne DB sammeln dafür Statistikdaten, die aber eben nicht adhoc nach dem Anknipsen zur Verfügung stehen. Zieht man ein Altsystem um, wird man -wenn möglich- also sogar Statistiken mitnehmen und im neuen System restaurieren. Natürlich gibt es Befehle diese Statistiken aufzubauen, zu reorganisieren, aber bei Tabellendaten im TB Bereich dauert das halt.
 
Werbung:
Zurück
Oben