Base de données Core : Nœuds de configuration SDK

Document created by RSA Information Design and Development on Feb 3, 2017
Version 1Show Document
  • View in full screen mode
  

Cette rubrique décrit les nœuds de configuration SDK qui ont un impact sur la base de données. Il existe des éléments de configuration supplémentaires pour chaque service Core ayant un impact sur la base de données mais pas sur la façon dont la base de données stocke ou récupère les données. Ces paramètres se trouvent dans le dossier /sdk/config.

max.concurrent.queries

Ce paramètre contrôle le nombre d'opérations de requêtes autorisées simultanément dans la base de données. Autoriser un nombre plus important d'opérations de requêtes simultanées peut améliorer la réactivité pour plus d'utilisateurs, mais la charge de requêtes du service Core reste étroitement liée aux E/S, et une valeur max.concurrent.queries élevée peut avoir un effet négatif. La valeur recommandée s'approche du nombre de cœurs du système, y compris dans le cas d'hyper-threading. Ainsi, pour une appliance avec 16 cœurs, la valeur doit se rapprocher de 32. Réduisez-la un peu pour les threads d'agrégation et les threads de réponse du système général. Réduisez-la encore si le système est hybride (par exemple, un Decoder et un Concentrator s'exécutent sur la même appliance). Il n'y a pas de chiffre miracle, mais une valeur située entre 16 et 32 devrait bien fonctionner.

max.pending.queries

Ce paramètre contrôle la taille du backlog pour le moteur de requêtes de la base de données. Des valeurs élevées permettent à la base de données de mettre plus d'opérations en file d'attente d'exécution. Une requête en file d'attente ne progresse pas dans son exécution. Par conséquent, il peut être plus utile que le système produise des erreurs lorsque la file d'attente est complète, plutôt que de laisser sa taille devenir excessive. Toutefois, dans un système réalisant principalement des opérations en lot comme des rapports, une file d'attente volumineuse ne présente pas d'effet négatif.

cache.window.minutes

Ce paramètre contrôle une fonction du moteur de requêtes conçue pour améliorer la réactivité des requêtes lorsqu'il existe de nombreux utilisateurs simultanés. Pour plus d'informations sur la fenêtre de cache, consultez Techniques d'optimisation.

max.where.clause.cache

Le cache de clause Where contrôle la taille de la mémoire pouvant être consommée par les opérations de requêtes qui doivent produire un ensemble important de données temporaires pour évaluer le tri ou la comptabilisation. Si la taille du cache de clause Where présente un dépassement de capacité, la requête fonctionne quand même, mais elle est beaucoup plus lente. Si le cache de clause Where est trop volumineux, les requêtes peuvent allouer tellement de mémoire que le service est obligé de permuter ou manque de mémoire. Ainsi, la valeur multipliée par max.concurrent.queries doit toujours être bien inférieure à la taille de la RAM physique. Ce paramètre comprend les tailles sous la forme d'un nombre suivi d'une unité, par exemple 1.5 GB.

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

Ces paramètres sont disponibles dans Security Analytics 10.4 et versions antérieures.

Dans Security Analytics 10.4 et versions antérieures, la base de données Core prend en charge trois niveaux de priorité des requêtes. Un niveau de priorité est attribué à chaque utilisateur principal. Ainsi, jusqu'à trois groupes d'utilisateurs peuvent être définis pour améliorer les performances. Ces paramètres contrôlent le temps que chaque utilisateur est autorisé à exécuter les requêtes. Par exemple, cette valeur sera moins élevée pour les utilisateurs disposant de privilèges inférieurs et ils ne pourront pas utiliser toutes les ressources du service Core avec des requêtes de longue durée.

query.timeout

Ce paramètre est disponible dans Security Analytics 10.5 et versions ultérieures.

Les niveaux de requête ont été remplacés dans Security Analytics 10.5 et versions ultérieures par l'expiration du délai des requêtes des comptes utilisateur. Pour les connexions approuvées, ces délais d'expiration sont configurés sur le serveur Security Analytics. Pour les comptes sur les services Core, il existe un nouveau nœud de configuration sous chaque compte appelé query.timeout. C'est le nombre maximum de minutes d'exécution de chaque requête. Lorsque cette valeur est définie sur zéro, le service Core n'applique aucune expiration du délai des requêtes.

max.where.clause.sessions

Ce paramètre est disponible dans Security Analytics 10.5 et versions ultérieures.

Ce paramètre impose une limite au nombre de sessions qui peuvent être scannées par une requête unique. Par exemple, si un utilisateur sélectionne toutes les méta de sa base de données, la base de données arrête de traiter les résultats une fois que le nombre de sessions lues pour cette requête atteint cette valeur de configuration. La valeur 0 désactive cette limite.

Le nombre de sessions nécessaires au traitement complet d'une requête est égal au nombre de sessions qui correspondent à la clause WHERE de la requête, en supposant que tous les termes de la clause Where disposent d'un index adapté. S'il existe des termes non indexés dans la clause Where, la base de données doit lire plus de sessions et de méta, et atteint cette limite plus vite.

max.query.groups

Ce paramètre est disponible dans Security Analytics 10.5 et versions ultérieures.

Ce paramètre impose une limite au nombre de groupes uniques collectés dans une requête unique. Par exemple, si une requête présente un groupe par clause avec plusieurs méta ayant un nombre élevé de valeurs uniques, la quantité de mémoire nécessaire à cette requête pourrait facilement dépasser la quantité de RAM disponible sur le serveur. Ainsi, cette limite existe pour éviter les insuffisances de mémoire.

La valeur 0 désactive cette limite.

packet.read.throttle

Ce paramètre réservé au Decoder a un impact sur l'accès à la base de données de paquets. Lorsque packet.read.throttle est défini sur une valeur supérieure à 0, le Décoder tente de réguler la lecture de paquets lorsqu'il détecte un conflit d'accès des paquets sur la base de données de paquets. Les nombres élevés proposent une régulation plus forte. Les modifications prennent effet immédiatement.

cache.dir, cache.size

Tous les services Security Analytics Core conservent un petit cache de fichiers de contenu brut extrait du périphérique. Ces paramètres contrôlent l'emplacement (cache.dir) et la taille (cache.size) de ce cache.

parallel.values

Ce paramètre est disponible dans Security Analytics 10.5 et versions ultérieures.

Ce paramètre permet à des opérations SDK de s'exécuter en parallèle. S'il est défini sur 0, l'exécution parallèle est désactivée. S'il est défini sur une valeur supérieure à 0, il représente le nombre de threads créées lorsque chaque opération SDK s'exécute. La valeur maximale est le nombre de CPU logiques disponibles au début du processus. 

Il est utile de définir une valeur élevée pour le paramètre parallel.values dans le cas où le nombre d'utilisateurs simultanés est faible, car cela permet d'exécuter plus rapidement des procédures d'enquête plus complexes. Si le nombre d'utilisateurs simultanés est élevé, il est préférable d'utiliser ici une valeur faible car il y aura un grand nombre d'opérations SDK indépendantes exécutées en même temps.

parallel.query

Ce paramètre est disponible dans Security Analytics 10.5 et versions ultérieures.

Cette configuration est similaire au paramètre parallel.values en ce sens que la valeur maximum est le nombre de CPU logiques. La définition du paramètre parallel.query sur une valeur spécifique doit prendre en compte le nombre d'utilisateurs simultanés afin d'optimiser l'utilisation de la CPU sans dépasser régulièrement les ressources disponibles. 

Il est utile de définir une valeur élevée pour le paramètre parallel.query dans le cas où le nombre de requêtes et d'utilisateurs simultanés est faible, car cela permet d'exécuter plus rapidement des requêtes plus complexes. Si le nombre de requêtes et d'utilisateurs simultanés est élevé, il est préférable d'utiliser une valeur faible car le nombre d'opérations de requêtes SDK indépendantes exécutées simultanément sera élevé.

Les opérations de requêtes sont limitées par le taux de lecture de la base de données méta. Par conséquent, la définition du paramètre parallel.query sur une valeur supérieure à 4 aura peu de chances de produire des résultats significativement supérieurs à la valeur par défaut de 0. La valeur parallel.query la mieux adaptée dépendra du type de stockage connecté. Essayez différentes valeurs pour parallel.query afin de déterminer les meilleurs résultats avec votre système de stockage.

You are here
Table of Contents > Configuration avancée de la base de données > Nœuds de configuration SDK

Attachments

    Outcomes