Lade...
 

ObjectStore Client Profiling

ObjectStore® Client Profiling

Das Programm cxDBProf dient der Fernüberwachung von ClassiX®-Anwendungen und dem Feststellen von Engpässen und unerwarteten Locks auf die Datenbank ObjectStore.

cxDBProf basiert auf zwei Informationsquellen:

  • Es werden Statusinformationen ausgewertet, die der Server über die Clients zur Verfügung stellt. Diese kann man sich auch mittels "ossvrstat" anzeigen lassen.
  • Die Clients selbst senden über das ClassiX®-Remote-Profiling-Protokoll Informationen über die abgearbeiteten InstantView®-Messages und Prozeduren.

Siehe auch CXOSLOG.EXE - eine Version ohne Window-Oberfläche, die als Windows Service läuft.

Konfiguration

Die Überwachung der Anwendungen erfolgt über das ClassiX®-Profile-Protokoll (cxpp). Dieses erfordert einen gemeinsamen UDP-Port auf dem Client und dem Computer, auf dem der Profiler läuft.
Dazu ist jeweils ein Eintrag in der Datei "services" erforderlich. Diese befindet sich unter Windows NT im Verzeichnis "%SYSTEMROOT%\system32\drivers\etc" (meistens "C:\Windows\System32\drivers\etc").

Der Eintrag hat das Format:

Cxpp /udp

Wobei durch eine Zahl größer 1024 zu ersetzen ist. Auf dem Client und dem Server muss der gleiche Eintrag vorhanden sein. Wird auf einem der Systeme kein entsprechender Wert eingetragen, so wird der Defaultwert 11111 verwendet.

Benutzung

        Kommandozeilen Parameter

cxDBprof.exe kennt 5 Kommandozeilen Parameter. Alle sind optional, so dass sich das Programm auch ohne Parameter starten lässt. Die Parameter können in beliebiger Reihenfolge angegeben werden. Es gibt folgende Parameter:

cxDBprof.exe -HServer-Hostname -TTerminalServer-Hostname -DDatenbank -LLogging.ini -SIntervall

Hinweise:
Die Werte der Parameter müssen direkt hinter den Namen des Parameters geschrieben werden. Also z.B. "-LC:\Temp\Logging.ini".

Wenn der Parameter "-S" angegeben wurde, wird die (kumulierte) Server Statistik sofort gestartet, muss also nicht erst über das Menü gestartet werden. Das Intervall (in Millisekunden) ist als Zahl anzugeben und ist optional, z.B. "-S60000" für eine Minute. Standard ist hier 200.

Der Parameter "-D" (Datenbank) muss den kompletten Pfad zur Datenbank enthalten. Dies kann, falls die Datenbank auf einem anderen Computer ist, ein UNC Pfad sein (z.B. "\\Server\Freigabe\Classix\Projects\classix.cxd").

Aktivierung der TerminalServer-Unterstützung

Damit die Zuordnung zwischen Client-Namen und einem TerminalServer, auf dem eine ClassiX®-Anwendung ausgeführt wird, stattfinden kann, muss zunächst jeder TerminalServer registriert werden. Dies - und damit die Namenszuordnung - geht allerdings nur, wenn auf dem Computer, auf dem der ProfServ läuft, eine Serverversion von TerminalServer installiert ist.

Registriert werden kann ein TerminalServer über den Menüpunkt "Ansicht/TerminalServer-Optionen". Hier werden TerminalServer hinzugefügt (Button "Add") oder entfernt Button "Del".

wpe2.jpg (7615 Byte)

Beim Hinzufügen werden weitere Optionen abgefragt: Typ des TerminalServers (Windows-TerminalServer, Citrix Metaframe oder Automatische Erkennung) und Hostname. Wenn der angegebene Computer als TerminalServer erkannt wird so erscheint er anschließend in der Liste.

 wpe5.jpg (6617 Byte)

Anmerkung: Citrix wird aufgrund fehlender Dokumentation noch nicht unterstützt!

Serveranzeige

Unter "Datei" kann eine Verbindung zu DB-Servern und zu Clients, die auf die Datenbank zu greifen, hergestellt werden. Die Serveranzeige dient einer dynamischen Anzeige der Status aller Clients, die aktuell auf den Server zugreifen. Um eine Serveranzeige zu öffnen wird "Datei/Verbinden zu DB-Server" gewählt. Anschließen wird der Servername im Feld "DB-Server" eingetragen. Der Servername kann als reiner Hostname (z.B. "CL"), als kompletter FQDN (Fully Qualified Domain Name) (z.B. "CL.CX.DE") oder als IP-Adresse (z.B. 192.168.1.34) eingegeben werden. Der Auflösen-Button versucht, eine Namensauflösung vorzunehmen.

Auswahldbserver

Zusätzlich können Abfragegeschwindigkeit und Datenbank festgelegt werden. Aus der Datenbankangabe werden die Segmentnamen ausgelesen, die in der Anzeige von Lockingkonflikten in der Clientanzeige (s.u.) benötigt werden. Diese Angaben lassen sich später mit den DB-Server-Optionen ändern. Die Datenbankangabe kann entweder ein lokal erreichbarer Dateiname sein (sowohl vom Server als auch vom DBProf-Rechner) oder der Pfad zur Server-Datenbank (:, d.h. der Pfad lokal aus Sicht des Servers).

Wenn der SystemOut-Pfad spezifiziert ist, wird dieser genutzt, um den aktuell angemeldeten Clients in der Client-Übersicht den ClassiX®-Benutzernamen zuzuordnen.
Der Datenbank-Server und das SystemOut-Verzeichnis können durch Umgebungsvariablen gesetzt werden.

Umgebungsvariable Beschreibung
CX_DATABASE_SERVER Der Datenbank-Server
CX_SYSTEM_OUT

Das Ausgabeverzeichnis der Logs (SystemOut)

Die Overview-Checkbox öffnet neben dem Fenster mit allen Zugriffdetails (nächster Screenshot) auch eine Übersichtsanzeige, in der alle aktiven Clients samt ihrem Status angezeigt werden und Locking-Konflikte, insbesondere Locking-Cluster, farblich markiert werden.

Übersichtsanzeige

Im Titel des Übersichtsfensters wird der jeweilige Datenbankserver angezeigt. Die Clients werden im Serverfenster nach Möglichkeit mit Namen, sonst mit IP-Adressen oder Prozess-ID aufgelistet. Folgende Status sind möglich:

Ohne Status

Der Client verursacht gerade keine Datenbankaktivität, hat auch keine Server-Transaktion offen. Eine Clienttransaktion (also eine, die lediglich im Cache-Manager bekannt ist) kann jedoch trotzdem offen sein.

Idle (Txn Open)

Der Client verursacht gerade keine Datenbankaktivität, hat aber eine Transaktion auf dem Server offen.

Working

Der Client verursacht gerade Datenbankaktivität, besitzt also Locks auf mindestens ein Objekt der Datenbank. Zusätzlich wird die Last angezeigt, die der Client verursacht (Work) und die Zeit, die diese Arbeit bereits gedauert hat.

Dead

Der Client ist in einen Deadlock verwickelt

Wait...

Der Client wartet auf die Zuteilung eines Locks, welcher gerade von einer anderen Anwendung gehalten wird. Weitere Informationen beziehen sich darauf, ob der Client den Lock zum Lesen (R) oder zum Schreiben (W) haben möchte, und ob ein Lock für einen bestimmten Bereich innerhalb eines Segments (Range, der Normalfall), für ein ganzes Segment oder die ganze Datenbank geholt werden soll.

Zusätzlich werden Farben eingesetzt, um Locking-Cluster anzuzeigen. Wartet beispielsweise Client A auf Client B und Client B auf Client C, so werden A, B und C in einer Farbe angezeigt. Wartet zusätzlich Client D auf Client E, so werden D und E in einer zusätzlichen Farbe angezeigt.

Da sich die Daten sehr schnell ändern können ist es möglich die Anzeige einzufrieren. Das geschieht über den Stop-Button in der Toolbar oder das Menü „Bearbeiten/Stop“. Durch den „Laufen“-Button oder das Menü „Bearbeiten/Start“ wird die Anzeige wieder zum Leben erweckt. Diese Einstellung wirkt sich auf den Sammelprozess und die Anzeige der Clientanzeige aus.

Detailanzeige

cxDBProf mit 2 aktiven und einem toten Client

Serverfenster mit 2 aktiven und einem toten Client

 

Im Titel des Serverfensters werden der jeweilige Datenbankserver und die Anzahl der verbundenen Clients angezeigt. Die Clients werden im Serverfenster nach Möglichkeit mit Namen, sonst mit IP-Adressen aufgelistet. Zu jedem Client wird eine Reihe von Details angezeigt (siehe Abbildung). Die angezeigten Werte, sind die kumulierten Werte seit Anmeldung des Clients an den Datenbank-Server. Also nicht die kumulierten Werte seit Start von cxDBProf. Durch einen Doppelklick auf den Namen des Clients gelangt man in die Clientanzeige.

Spaltenbeschriftung Beschreibung
Client Name des Clients sowie Prozess-ID des ClassiX-Prozesses.
Locking Konflikte

Häufigkeit, mit der dieser Client warten musste, um ein Lock auf eine Page zu erhalten, weil für diese bereits ein Lock an einen anderen Client ausgegeben worden ist.

Wartezeiten

Aufsummierte Zeit, die dieser Client auf die Freigabe von Locks gewartet hat.
Deadlocks Häufigkeit mit der der Server entschieden hat, dass dieser Client Opfer eines Deadlocks geworden ist. Der Client wird daraufhin informiert, dass er eine bestimmte Transaktion abbrechen muss, damit andere Clients ihre Transaktionen beenden können.
Transaction-Aborts Anzahl der abgebrochenen Transaktionen, die dem Server bekannt sind. Ist die Transaktion bis dahin ohne Interaktion mit dem Server aus dem Cache heraus abgelaufen, so wird auch der Abbruch dem Server nicht bekannt.
Gelesene Pages

Anzahl der Pages und die entsprechende Datenmenge, die der Server an den Client geschickt hat.

Dies kann bei der Bestimmung der Cache-Size helfen, indem möglichst viele Daten im Cache gespeichert bleiben.

Geschriebene Pages

Anzahl der Pages und die entsprechende Datenmenge, die der Client an den Server geschickt hat.

Datentransfer findet ausschließlich bei erfolgreichen Commits statt. Die pro Commit übertragenen Daten sollten die Propagation Buffer-Size des Servers möglichst nicht überschreiten.

Commits

Anzahl der abgeschlossenen Transaktionen, die dem Server bekannt sind. Werden in einer Transaktion keine Daten verändert, wird der Server nicht notwendiger Weise über den Abschluss informiert.

Dies sollte in etwa der Anzahl aller Transaktionen entsprechen.

Readonly Commits Anzahl der abgeschlossenen Transaktionen, für die der Server festgestellt hat, dass diese keine Daten verändert haben.
Locking Konflikt mit Welcher Client hält aktuell ein Lock, auf das dieser Client wartet.
Konflikt in Segment In welchem Segment wird ein Lock gehalten, auf das dieser Client wartet.

Zu Beginn enthält die Liste nur aktive Clients. Meldet sich ein Client ab, wird sein Eintrag in der Liste grau markiert. Durch einen Klick auf den "Tote Clients löschen" Button (rotes "X") können die inaktiven (toten) Clients aus der Liste gelöscht werden.

Muss ein Client auf einen (oder mehrere) Clients warten (Locking), wird sein Eintrag in der Liste rot eingefärbt und in der Spalte "Locking Konflikt mit" werden der/die Client(s) aufgelistet auf die der Client warten muss.

Clientanzeige

image2.gif

Die Clientanzeige wird mit "Datei/Verbinden zu Client" geöffnet. Im Feld "Client" wird der Name des zu überwachenden Clientrechners eingegeben. Der Auflösen-Button entspricht dem Feld "DB-Server" bei der Serveranzeige (s.o.).

Die "maximale Tiefe" wird momentan nicht berücksichtigt, soll aber später dazu dienen, InstantView®-Befehle nur bis einer bestimmten Verschachtelungstiefe anzuzeigen.

Unter den "Server Infos" wird eingetragen, auf welchen DB-Server der Client zugreift. Das Feld "DB-Server" wird erst aktiviert, wenn Statusinformationen vom DB-Server bezogen werden sollen.

Die Clientanzeige ist zweigeteilt. In der Mitte des Fensters ist ein Slider, der nach links und rechts gezogen werden kann. Wenn das remote-Profiling auf dem Client aktiviert ist werden auf der linken Seite die InstantView®-Profile-Statements angezeigt.

Auf der rechten Seite werden die erweiterten Statusinformationen vom Server angezeigt, wenn diese in den Clientoption angewählt wurden. Die interessanteste Anzeige dürften die Lock-Einträge darstellen. Zum besseren Verständnis: "Read-lock" bedeutet nicht, dass eine Anwendung einen Read-Lock hält, sondern dass sie auf einen Read-Lock wartet. Read- und Writelocks hält eine Anwendung in den Working-Abschnitten.

Im Beispiel (Abbildung unten) wartet eine Anwendung auf dem Rechner CL.CX.DE auf die Erteilung eines Read-Locks auf einen Bereich im Segment 1080 ("salesOrderSlaveS"). Der Bereich beginnt bei Sektor 104 und hat eine Länge von 8 Sektoren. Der Read-Lock kann nicht erteilt werden, weil eine Anwendung auf MOBIL2.CX.DE eines der Objekte in diesem Bereich bereits mit einer höheren Priorität gesperrt hat.

profserv03.gif

Es gibt eine InstantView®-Anwendung, mit der ausgehend von diesen Informationen alle Objekte, die sich in dem angegebenen Bereich befinden, angezeigt werden können (siehe "Die einen Locking-Konflikt verursachenden Objekte anzeigen").

Wird anstelle eines Segmentnamens "unknown" angezeigt, so muss der DB-Serveranzeige über den Menüpunkt "Anzeige/DB-Server-Optionen" die Datenbank bekannt gemacht werden, damit die zur Datenbank gehörigen Segmente geladen werden können (siehe Serveranzeige).

Logging

Die folgenden Informationen können auch mit Hilfe des Dienstes cxosdblog gesammelt und geloggt werden.

Statistische Daten zum Server und allen Clients können in ein Logfile protokolliert werden. Das gleiche gilt für Locking-Konflikte. Zunächst ist eine Konfigurationsdatei zu erstellen:

log4cplus.rootLogger=INFO, FILE_LOGGER log4cplus.appender.FILE_LOGGER=log4cplus::RollingFileAppender log4cplus.appender.FILE_LOGGER.MaxFileSize=5MB log4cplus.appender.FILE_LOGGER.MaxBackupIndex=10 log4cplus.appender.FILE_LOGGER.File=cxdbprof.log log4cplus.appender.FILE_LOGGER.ImmediateFlush=true log4cplus.appender.FILE_LOGGER.Append=true log4cplus.appender.FILE_LOGGER.layout=log4cplus::PatternLayout log4cplus.appender.FILE_LOGGER.layout.ConversionPattern=%D{%Y-%m-%d %H:%M:%S,%%q} %5p %c - %m%n log4cplus.logger.cxdbprof=INFO

 

Ggf. ist hier der Dateiname anzugeben (relativ zum aktuellen Verzeichnis). Auf Umgebungsvariablen kann über ${VARIABLE} zugegriffen werden, absolute Pfade sind natürlich auch möglich.

cxDBprof protokolliert Ereignisse drei verschiedener Kategorien:

Kategorie Bedeutung Beispiel
cxdbprof.main Start und Ende ClassiX Profile-Server 1.35 started
ClassiX Profile-Server terminated
cxdbprof.stat Statistik s.u.
cxdbprof.lock Locking-Konflikt s.u.

Statistische Daten über den Server oder einen Client werden immer dann ins Protokoll geschrieben, wenn sich etwas verändert hat:

2006-05-11 15:37:59,762 INFO cxdbprof.stat - ; client, clientID, time, receive_msgs, callback_msgs, KB_read, KB_written, commit, readonly_commit, abort,lock_timeouts, lock_waits, deadlocks, total_lock_wait_time [,propagations, KB_propagated, KB_direct] 2006-05-11 15:38:08,762 INFO cxdbprof.stat - . 9 84 0 276 0 0 1 0 0 0 0 0 0 0 0 2006-05-11 15:38:09,762 INFO cxdbprof.stat - . 10 2 0 0 0 0 0 0 0 0 0 0 0 0 0 2006-05-11 15:38:12,980 INFO cxdbprof.stat - . 13 792 0 1267 0 0 5 0 0 0 0 0 0 0 0 2006-05-11 15:38:13,980 INFO cxdbprof.stat - md 231 14 792 0 1267 0 0 5 0 0 0 0 0 2006-05-11 15:38:13,980 INFO cxdbprof.stat - . 14 65 0 247 0 0 1 0 0 0 0 0 0 0 0 2006-05-11 15:38:14,980 INFO cxdbprof.stat - md 231 15 64 0 247 0 0 1 0 0 0 0 0

 

Die erste Zeile beschreibt die einzelnen Datenfelder. Im Logfile sind diese durch das Tabulator-Zeichen getrennt.

Datenfeld Beschreibung
client Name des Client, wobei der Punkt für den Server steht
clientID ID, die der ObjectStore-Server jedem Client gibt. Sie ist nicht zu verwechseln mit der Prozess-ID!
time Seit Programmstart (von cxDBprof) verstrichene Zeit in Sekunden
receive_msgs Anzahl der Nachrichten, die der Server von Clients empfangen hat. Eine Nachricht kann eine Anfrage für eine Aktion wie das Öffnen der DB, holen einer Page, DB updaten, Ausführen einer Transaktion, Abbrechen einer Transaktion, Schließen der DB, sowie andere Dinge. Die Anzahl sagt aus wie oft Clients mit dem Server kommunizieren. Dementsprechend ist die Anforderung an den Server gering, wenn die Anzahl klein ist.
callback_msgs Anzahl Callback-Nachrichten die der Server zu den Clients schickt. Eine Callback-Nachricht ist eine Nachricht die der Server zu Client A sendet, wenn Client B Daten einer Page anfordert die von Client A gecached ist.
Ist diese Anzahl hoch bedeutet dies, dass eine Applikation oft auf Daten schreiben will, die von anderen Clients  gelesen oder beschrieben werden wollen.
KB_read Gelesene Datenmenge, in KBytes
 
Number of kilobytes of data that the server sent to clients to read. Monitor this statistic to help determine whether you need to enlarge client cache files. Compare kilobytes read for a given client with the number of commits and the size of the client cache file.
KB_written Geschriebene Datenmenge, in KBytes
 
Number of kilobytes of modified data that the clients sent to the server. Written data is data involved in a commit. It must be buffered, and it is logged if it cannot go directly to a database because it is not being written past the current end of a cluster. When analysis is concerned with the number of transactions per second, the number of kilobytes written is an important factor.
commit Anzahl Commits (abgeschlossenen R/W  Transaktionen) von denen der Server weiß. Falls ein Client Daten während einer Transaktion nicht verändert, informiert der Client eventuell nicht den Server, dass eine Transaktion abgeschlossen ist.
Mit dieser Anzahl lassen sich die Transaktionen pro Sekunde berechnen.
readonly_commit Anzahl Readonly-Commits: 

Ausgeführte Transaktionen die laut Feststellung des Servers nicht in Daten Änderungen involviert waren. Normalerweise informiert der Client den Server nicht über solche Commits, weswegen die Anzahl gering sein sollte. Read-only Commits sind wie einfache Aborts und kosten nicht viel Zeit?

abort Anzahl der abgebrochenen Transaktionen die der Server protokolliert hat. Wenn der Client keine Nachricht an den Server geschickt hat, kann er eine Transaktion abbrechen ohne den Server zu benachrichtigen.

Bricht ClassiX® nur Transaktionen wegen Lock Konflikten ab? (Timeouts?)

lock_timeouts Anzahl Lock-Timeouts:
 
Anzahl aller Versuche der Clients eine Page zu sperren, die bereits gesperrt ist, weil die eingestellte Wartezeit bereits abgelaufen war.
lock_waits Anzahl Blockaden, die nicht zu einem Timeout führten

Anzahl der Versuche aller Clients eine Page zu sperren, die bereits von einem anderen Client gesperrt ist. Neben der Anzahl der lock waits steht in runden Klammern die durchschnittliche Zeit auf die man einen Lock wartet. (ObjectStore dividiert die gesamte Zeit durch die Anzahl der Lock waits.

deadlocks Anzahl Deadlocks
 

Anzahl wie oft der Server einen Client für ein Deadlock "Opfer" erklärt und bemerkte, dass er eine einzelne Transaktion beendet muss, sodass andere Clients ihre Transaktionen abschließen können.

total_lock_wait_time Wartezeit auf Locks, kumuliert (in msec)

Ereignisse wie Deadlock oder Blockaden (Leseoperation blockiert Schreiboperation, und umgekehrt) werden ebenfalls protokolliert:

2006-05-11 14:37:35,740 INFO cxdbprof.lock - st 219 mr(564) 205 Segment 32
2006-05-11 14:37:35,740 INFO cxdbprof.lock - ct 207 mr(564) 205 Segment 32

2006-05-11 15:39:11,245 INFO cxdbprof.lock - cl 234 st(2148) 233 mr(1868) 231 Segment 32

Die einzelnen Spalten sind durch das Tabulator-Zeichen getrennt (im Beispiel durch _ dargestellt).

Client st wird von mr blockiert
Client ct wird ebenfalls von mr blockiert

Client cl wird von den Clients st und mr blockiert

Die Lesart von links nach rechts: Client xxx wird blockiert von Client(s) yyy (und zzz und ...) in Segment abc. Die Zahl in Klammern ist die Prozessnummer, die Zahl rechts vom Clientnamen ist die Client-ID von ObjectStore.

Remote Profiling

Damit die InstantView®-Statements eines Clients mit dem cxDBProf angezeigt werden können muss auf Clientseite das Remote-Profiling aktiviert werden. Dies erfolgt mit dem InstantView®-Kommando

Profile()

wobei der der Name des Servers sein muss, auf dem cxDBProf läuft. Zwar resultiert die Angabe eines Rechnernamens, der erreichbar ist aber auf dem der cxDBProf nicht läuft, nicht in einen Fehler; die gesendeten Informationen liefen allerdings ins Leere (in eine Senke, wie Theoretiker oder Workflow-Experten sagen würden).

Zum Abschalten wird das übliche Kommando zum Deaktivieren des Profilings verwendet:

Profile(OFF)

Über eine Remote-Message kann das Remote-Profiling auch ferngesteuert aktiviert werden. Dazu muss zunächst das "ClassiX® Remote Message Protocol" (cxrmp) eingestellt sein. Dazu muss sowohl auf Sender, als auch auf Empfängerseite in der Datei "Services" (siehe "Konfiguration") der Eintrag

cxrmp /udp

vorhanden sein. <Port#> ist ein auf Client- und Serverseite identisch zu wählender Wert ab 1024.

Ist das Remote-Messaging eingerichtet, so kann der Sender durch eine InstantView®-Anweisung das Remote-Profiling auf Empfängerseite in folgender Form aktivieren bzw. deaktivieren:

"Profile()" "" SendMsg(, REMOTE)

"Profile(OFF)" "" SendMsg(, REMOTE)

Der Empfänger muss zum Empfang eine InstantView®-Anwendung ausführen, die folgendermaßen auf die Message reagiert:

: Execute

cxDBProf-Servername und Empfängername sind entsprechend der Konfiguration zu wählen. muss eine auf Sender- und Empfängerseite einheitlich verstandene Message sein.