Datenbanktuning: SDK-Konfigurations-Nodes

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

In diesem Thema werden die SDK-Konfigurations-Nodes beschrieben, die die Datenbank betreffen. Es gibt einige zusätzliche Konfigurationselemente in jedem Core-Service, die sich zwar auf die Datenbank auswirken, aber keine tatsächlichen Auswirkungen darauf haben, wie die Datenbank Daten speichert oder abruft. Diese Einstellungen befinden sich in dem Ordner /sdk/config .

max.concurrent.queries

Diese Einstellung legt fest, wie viele Abfragevorgänge gleichzeitig auf der Datenbank erlaubt sind. Das Erlauben mehrerer gleichzeitiger Abfragevorgänge kann die allgemeine Reaktionsgeschwindigkeit für mehr Benutzer verbessern, aber wenn die Abfragelast des Core-Services sehr I/O-gebunden ist, kann ein hoher Wert für „max.concurrent.queries“ schädliche Auswirkungen haben. Der empfohlene Wert ist nahe der Anzahl von Cores auf dem System, einschließlich Hyper-Threading. So sollte der Wert für eine Appliance mit 16 Cores etwa bei 32 liegen. Ziehen Sie einige ab für Aggregationsthreads und allgemeine Systemreaktionsthreads. Ziehen Sie einige weitere ab, wenn dies ein hybrides System ist (wenn zum Beispiel sowohl ein Decoder als auch ein Concentrator auf derselben Appliance laufen). Es gibt keine magische Anzahl, aber jede zwischen 16 und 32 sollte gut funktionieren.

max.pending.queries

Diese Einstellung kontrolliert die Größe des Backlogs für die Abfrage-Engine der Datenbank. Größere Werte erlauben, dass die Datenbank mehr Vorgänge zur Ausführung in die Warteschlange stellen kann. Eine Abfrage, die in die Warteschlange gestellt wurde, macht keinen Fortschritt bei ihrer Ausführung, daher kann es nützlicher sein, das System Fehler machen zu lassen, wenn die Warteschlange voll ist, anstatt zu erlauben, dass die Warteschlange sehr groß wird. Allerdings kommt es bei einem System, das in erster Linie Batchvorgänge wie Berichte durchführt, möglicherweise nicht zu negativen Auswirkungen durch eine große Warteschlange.

cache.window.minutes

Diese Einstellung steuert eine Funktion der Abfrage-Engine, die die Reaktionsgeschwindigkeit der Abfrage verbessern soll, wenn gleichzeitig viele Benutzer zugreifen. Weitere Informationen über das Cachefenster finden Sie unter Optimierungstechniken .

max.where.clause.cache

Der Where-Klausel-Cache legt fest, wie viel Arbeitsspeicher von Abfragevorgängen konsumiert werden kann, die eine große temporäre Datenmenge produzieren müssen, um das Sortieren oder Zählen auszuwerten. Wenn die Größe des Where-Klausel-Caches nicht ausreicht, funktioniert die Abfrage zwar noch, aber sie ist viel langsamer. Wenn der Where-Klausel-Cache zu groß ist, ist es möglich, dass Abfragen so viel Arbeitsspeicher allokieren, dass der Service in den Swap-Modus gezwungen würde oder zu wenig Arbeitsspeicher hätte. Daher sollte dieser Wert, multipliziert mit dem Wert max.concurrent.queries, immer kleiner sein als die Größe des physischen RAM. Diese Einstellung versteht Größen in Form einer Zahl, gefolgt von einer Einheit, zum Beispiel 1.5 GB .

max.unique.values

Die maximalen eindeutigen Werte begrenzen, wie viel Arbeitsspeicher von der Funktion „SDK-Werte“ beansprucht werden kann. SDK-Werte erzeugt eine sortierte Liste eindeutiger Werte. Damit genauere Ergebnisse erzeugt werden können, müssen möglicherweise eine große Anzahl eindeutiger Werte aus vielen Slices zusammengeführt werden. Dieser zusammengeführte Satz an Werten muss im Arbeitsspeicher eingeschränkt werden. Dieser Parameter existiert, um zu begrenzen, wie viel Arbeitsspeicher der zusammengeführte Wertesatz belegen kann. Der Standardwert wird begrenzt die Nutzung des Arbeitsspeichers auf ca. 1/10 der gesamten RAM.

query.level.1.minutes , query.level.2.minutes , query.level.3.minutes

Diese Einstellungen sind in NetWitness Suite 10.4 und älteren Versionen verfügbar.

In NetWitness Suite 10.4 und älteren Versionen unterstützt die Core-Datenbank drei Abfrageprioritätsstufen. Jeder Benutzer wird einem der Prioritätslevel zugewiesen. Daher gibt es bis zu drei Gruppen von Benutzern, die für die Zwecke des Performance-Tuning definiert werden können. Diese Einstellungen legen fest, wie lange es jeder Benutzerebene erlaubt ist, die Abfragen auszuführen. Beispielsweise kann für Benutzer mit geringeren Berechtigungen ein niedrigerer Wert festgelegt werden, sodass sie nicht durch lange dauernde Abfragen die gesamten Ressourcen des Core-Services verbrauchen können.

query.timeout

Diese Einstellung ist in NetWitness Suite 10.5 und neueren Versionen verfügbar.

Abfrageebenen wurden in NetWitness Suite 10.5 und neueren Versionen durch Abfrage-Timeouts pro Benutzerkonto ersetzt. Für vertrauenswürdige Verbindungen werden diese Timeouts auf dem NetWitness Suite-Server konfiguriert. Für Konten auf Core-Services gibt es einen neuen Konfigurations-Node mit der Bezeichnung query.timeout unter jedem Konto. Dieser gibt die maximale Zeit in Minuten an, die jede Abfrage ausgeführt werden kann. Das Festlegen der Werte auf null bedeutet, dass kein Abfragetimeout durch den Core-Service durchgesetzt wird.

max.where.clause.sessions

Diese Einstellung ist in NetWitness Suite 10.5 und neueren Versionen verfügbar.

Diese Einstellung begrenzt, wie viele Sitzungen durch eine einzige Abfrage gescannt werden können. Beispiel: Wenn ein Benutzer alle Metadaten einer Datenbank auswählt, beendet die Datenbank die Verarbeitung der Ergebnisse, sobald die Anzahl der Sitzungslesevorgänge für die Abfrage diesen Konfigurationswert erreicht. Der Wert 0 deaktiviert diese Begrenzung.

Die Anzahl der für die vollständige Verarbeitung einer Abfrage erforderlichen Sitzungen entspricht der Anzahl der Sitzungen, die mit der WHERE-Klausel dieser Abfrage übereinstimmen, vorausgesetzt für alle Begriffe in der Where-Klausel ist ein passender Index vorhanden. Wenn die Where-Klausel nicht indexierte Begriffe enthält, muss die Datenbank mehr Sitzungen und Metadaten lesen und die Begrenzung wird schneller erreicht.

max.query.groups

Diese Einstellung ist in NetWitness Suite 10.5 und neueren Versionen verfügbar.

Diese Einstellung begrenzt die Anzahl der eindeutigen Gruppen, die in einer einzigen Abfrage gesammelt werden. Beispiel: Wenn eine Abfrage eine Gruppierungsklausel mit mehreren Metadaten mit hohen eindeutigen Wertanzahlen enthält, kann der Speicherbedarf für diese Abfrage leicht den auf dem Server verfügbaren Arbeitsspeicher überschreiten. Diese Begrenzung gibt es also, um das Auftreten von „Out of Memory“-Bedingungen zu verhindern.

Das Festlegen des Werts 0 deaktiviert diese Begrenzung.

packet.read.throttle

Dies ist eine reine Decoder-Einstellung, die Auswirkungen auf den Zugriff auf die Pakete in der Datenbank hat. Wenn packet.read.throttle auf einen Wert größer 0 festgelegt wird, versucht der Decoder, das Lesen von Paketen zu drosseln, wenn ein Paketkonflikt in der Paketdatenbank erkannt wird. Hohe Zahlen entsprechen einer stärkeren Drosselung. Die Änderungen werden sofort wirksam.

cache.dir , cache.size

Alle NetWitness Suite-Core-Services verfügen über einen kleinen Dateicache mit Rohinhalten, die von dem Gerät extrahiert wurden. Diese Parameter steuern den Speicherort (cache.dir) und die Größe (cache.size) dieses Caches.

parallel.values

Diese Einstellung ist in NetWitness Suite 10.5 und neueren Versionen verfügbar.

Diese Einstellung ermöglicht das parallele Ausführen von SDK-Wertoperationen. Wird hier 0 festgelegt, wird die parallele Ausführung deaktiviert. Wenn ein Wert größer 0 festgelegt wird, steht dieser für die Anzahl an Threads, die erstellt werden, wenn jede SDK-Wertoperation ausgeführt wird. Der Maximalwert ist gleich der Anzahl der beim Start des Prozesses verfügbaren logischen CPUs.

Das Festlegen eines höheren Wertes für parallel.values ist bei einer geringen Anzahl an gleichzeitigen Benutzer hilfreich, da dadurch eine schnellere Ausführung komplexerer Ermittlungen ermöglicht wird. Bei vielen gleichzeitigen Benutzern ist ein niedrigerer Wert besser, da viele unabhängige SDK-Wertoperationen gleichzeitig ausgeführt werden.

parallel.query

Diese Einstellung ist in NetWitness Suite 10.5 und neueren Versionen verfügbar.

Diese Konfiguration ähnelt der Einstellung parallel.values insofern, als dass der Maximalwert gleich der Anzahl an logischen CPUs ist. Beim Festlegen von parallel.query auf einen bestimmten Wert sollte die Anzahl der gleichzeitigen Benutzer berücksichtigt werden, um die CPU-Auslastung zu maximieren, ohne dabei ständig die verfügbaren Ressourcen zu überschreiten.

Das Festlegen eines höheren Wertes für parallel.query ist bei einer geringen Anzahl an gleichzeitigen Benutzer und Abfragen hilfreich, da dadurch eine schnellere Ausführung komplexerer Abfragen ermöglicht wird. Bei vielen gleichzeitigen Benutzern und Abfragen ist ein niedrigerer Wert besser, da viele unabhängige SDK-Abfrageoperationen gleichzeitig ausgeführt werden.

Abfrageoperationen werden durch die Lesegeschwindigkeit der Metadatenbank beschränkt. Durch das Festlegen von parallel.query auf einen Wert über 4 werden daher vermutlich keine signifikant besseren Ergebnisse als beim Standardwert von 0 erzielt werden. Die optimale Anzahl für parallel.query ist abhängig von dem installierten Speicher. Testen Sie verschiedene Werte für parallel.query, um das optimale Ergebnis für Ihr Speichersystem zu ermitteln.

You are here
Table of Contents > Erweiterte Datenbankkonfiguration > SDK-Konfigurations-Nodes

Attachments

    Outcomes