Base de datos Core: Nodos de configuración de SDK

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

En este tema se describen los nodos de configuración de SDK que afectan la base de datos. En cada servicio Core hay algunos elementos de configuración adicionales que afectan la base de datos, pero que no afectan realmente la manera en que la base de datos almacena o recupera los datos. Estas configuraciones existen en la carpeta /sdk/config.

max.concurrent.queries

Esta configuración controla cuántas operaciones de consulta se permiten simultáneamente en la base de datos. La autorización de más operaciones de consulta simultáneas puede mejorar la capacidad de respuesta general para más usuarios, pero si la carga de consultas del servicio Core está muy enlazada a las I/O, un valor max.concurrent.queries alto puede tener un efecto perjudicial. Se recomienda un valor cercano a la cantidad de cores del sistema, incluido el Hyper Threading. De esta forma, en un dispositivo con 16 cores, el valor debe estar en torno a 32. Reste algunos hilos de ejecución de agregación e hilos de ejecución de respuesta generales del sistema. Reste algunos más si se trata de un sistema híbrido (por ejemplo, un Decoder y un Concentrator que se ejecutan en el mismo dispositivo). No hay un número mágico, pero un valor entre 16 y 32 debe funcionar bien.

max.pending.queries

Esta configuración controla el tamaño de trabajos pendientes para el motor de consultas de la base de datos. Los valores más altos permiten que la base de datos ponga en línea de espera más operaciones para ejecución. Una consulta en línea de espera no avanza hacia su ejecución. Por lo tanto, puede ser más útil hacer que el sistema produzca errores cuando la línea de espera está llena que permitir que la línea de espera crezca mucho. Sin embargo, en un sistema que ejecuta principalmente operaciones por lotes, como informes, puede que no sea perjudicial tener una línea de espera grande.

cache.window.minutes

Esta configuración controla una función del motor de consultas que tiene como objetivo mejorar la capacidad de respuesta de las consultas cuando hay una gran cantidad de usuarios simultáneos. Para obtener más información sobre la ventana de caché, consulte Técnicas de optimización.

max.where.clause.cache

La caché de la cláusula Where controla cuánta memoria pueden consumir las operaciones de consulta que deben producir un conjunto de datos temporales grande para evaluar la clasificación y el conteo. Si se desborda el tamaño de la caché de la cláusula Where, la consulta funciona de todos modos, pero es mucho más lenta. Si la caché de la cláusula Where es demasiado grande, es posible que se asigne tanta memoria para las consultas que el servicio se vería forzado a un intercambio o quedaría sin memoria. Por lo tanto, este valor multiplicado por max.concurrent.queries siempre debe ser mucho menor que el tamaño de la RAM física. Esta configuración comprende los tamaños en la forma de un número seguido de una unidad, por ejemplo 1.5 GB.

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

Esta configuración está disponible en Security Analytics 10.4 y en versiones anteriores.

En Security Analytics 10.4 y anteriores, la base de datos Core es compatible con tres niveles de prioridad de consulta. A cada usuario principal se asigna uno de los niveles de prioridad. Por lo tanto, se pueden definir hasta tres grupos de usuarios con fines de ajuste del rendimiento. Estas configuraciones controlan cuánto tiempo se permite ejecutar consultas a cada nivel de usuario. Por ejemplo, los usuarios con privilegios inferiores pueden tener un valor menor de modo que no puedan usar todos los recursos del servicio Core con consultas de ejecución prolongada.

query.timeout

Esta configuración está disponible en Security Analytics 10.5 y en versiones superiores.

Los niveles de consulta se reemplazaron en Security Analytics 10.5 y superior por tiempos de espera de consulta por cuenta de usuario. Para las conexiones de confianza, estos tiempos de espera se configuran en el servidor de Security Analytics. Para cuentas en servicios Core, hay un nuevo nodo de configuración bajo cada cuenta, denominado query.timeout, que corresponde a la cantidad máxima de tiempo, en minutos, que se puede ejecutar cada consulta. Si este valor se configura en cero, significa que el servicio Core no impondrá ningún tiempo de espera de consulta.

max.where.clause.sessions

Esta configuración está disponible en Security Analytics 10.5 y en versiones superiores.

Impone un límite en la cantidad de sesiones que puede escanear una única consulta. Por ejemplo, si un usuario selecciona todos los metadatos de la base de datos, esta deja de procesar los resultados una vez que la cantidad de sesiones leídas para la consulta alcanza este valor de configuración. Un valor de 0 inhabilita este límite.

La cantidad de sesiones que se requieren para procesar por completo una consulta es igual a la cantidad de sesiones que coinciden con la cláusula WHERE de la consulta, bajo el supuesto de que todos los términos de la cláusula where tienen un índice apto. Si hay términos de la cláusula where que no están indexados, la base de datos debe leer más sesiones y metadatos y alcanza este límite antes.

max.query.groups

Esta configuración está disponible en Security Analytics 10.5 y en versiones superiores.

Impone un límite en la cantidad de grupos únicos que se recopilan en una única consulta. Por ejemplo, si una consulta tiene una cláusula group by con múltiples metadatos que tienen altos conteos de valores únicos, la cantidad de memoria necesaria para esa consulta podría sobrepasar fácilmente la cantidad de RAM disponible en el servidor. De este modo, este límite existe para impedir que se produzcan condiciones de falta de memoria.

Si se configura un valor de 0, se inhabilita este límite.

packet.read.throttle

Esta es una configuración solo de Decoder que afecta al acceso a la base de datos de paquete. Si packet.read.throttle se configura en un valor mayor de 0, el Decoder intenta regular las lecturas de paquetes cuando detecta un conflicto de paquetes en la base de datos de paquete. Los números mayores proporcionan más regulación. Los cambios se aplican de inmediato.

cache.dir, cache.size

Todos los servicios Security Analytics Core mantienen una pequeña caché de archivos de contenido crudo extraído del dispositivo. Estos parámetros controlan la ubicación (cache.dir) y el tamaño (cache.size) de este caché.

parallel.values

Esta configuración está disponible en Security Analytics 10.5 y en versiones superiores.

Esta configuración permite que las operaciones de valores de SDK se ejecuten en paralelo. Si se configura en 0, se deshabilita la ejecución en paralelo. Si se configura en un valor mayor de 0, representa la cantidad de hilos de ejecución que se crean cuando se ejecuta cada operación de valores de SDK. El valor máximo es la cantidad de CPU lógicos disponibles cuando se inició el proceso. 

La configuración de un valor más alto para parallel.values es útil cuando hay pocos usuarios simultáneos, puesto que permite la ejecución de investigaciones más complejas con mayor rapidez. Si hay muchos usuarios simultáneos, es mejor usar un valor bajo, ya que se ejecutarán simultáneamente muchas operaciones de valores de SDK independientes.

parallel.query

Esta configuración está disponible en Security Analytics 10.5 y en versiones superiores.

Esta configuración se asemeja al ajuste parallel.values en que el valor máximo es la cantidad de CPU lógicos. La configuración de parallel.query en un valor específico debe considerar la cantidad de usuarios simultáneos para maximizar la utilización del CPU sin que se superen constantemente los recursos disponibles. 

La configuración de un valor más alto para parallel.query es útil cuando hay pocos usuarios y consultas simultáneos, puesto que permite la ejecución de consultas más complejas con mayor rapidez. Si hay muchos usuarios y consultas simultáneos, es mejor usar un valor bajo, ya que se ejecutarán simultáneamente muchas operaciones de consultas de SDK independientes.

Las operaciones de consultas están limitadas por la velocidad de lectura de la base de datos de metadatos; por lo tanto, si parallel.query se configura en un valor mayor de 4, es poco probable obtener resultados mucho mejores que con el valor predeterminado de 0. El mejor número que se debe usar para parallel.query dependerá del tipo de almacenamiento conectado. Experimente con distintos valores de parallel.query para determinar los mejores resultados para el sistema de almacenamiento.

You are here
Table of Contents > Configuración avanzada de la base de datos > Nodos de configuración de SDK

Attachments

    Outcomes