Por Ann Harrison ? Traducido por Sergio Samayoa
Parámetros
#V4_LOCK_MEM_SIZE 98304
#ANY_LOCK_MEM_SIZE 98304
Efecto
LOCK_MEM_SIZE en todas sus variantes determina la cantidad de memoria que se adjudica a la tabla de bloqueos. En modo "Clásico" el tamaño adjudicado es usado para la asignación inicial. La tabla se expande dinámicamente hasta el límite de la memoria. En "Súper Servidor", el tamaño inicial es también el tamaño final. Usted debe reiniciar el "Súper Servidor" para cambiar el tamaño de la tabla de bloqueo. El tamaño por defecto de la memoria de bloqueo es de 98304.
Experiencia
En todas las versiones de Interbase excepto en aquellas que se ejecutan en VMS, la contención de recursos se manipula por medio de una tabla de bloqueo mantenida por Interbase. En VMS, Interbase usa el administrador de bloqueo del sistema. En arquitectura "Clásica", la tabla de bloqueo es mantenida en memoria compartida. En "Súper Servidor", la tabla es parte de servidor mismo.
Si bien Interbase no utiliza bloqueos para resolver los conflictos en registros individuales, si utiliza bloqueos para proteger páginas mientras éstan siendo cambiadas ? no por la duración de la transacción, pero si por la duración del cambio. Interbase también usa bloqueos para permitir que una transacción espere por otra cuando aparece un conflicto, y por otras situaciones que requieren sincronización.
Indicaciones de uso
Las condiciones que afectan el tamaño de la tabla de bloqueo son:
Parámetros
#V4_LOCK_SEM_COUNT 32
#ANY_LOCK_SEM_COUNT 32
En ambientes no multi hilos, éste asigna el número de semáforos disponibles para Interbase. El contador de semáforos por defecto depende del sistema.
EPSON SEMAPHORES 10
M88K SEMAPHORES 10
UNIXWARE SEMAPHORES 10
NCR3000 SEMAPHORES 25
SCO_UNIX SEMAPHORES 25
sgi SEMAPHORES 25
IMP SEMAPHORES 25
DELTA SEMAPHORES 25
Ultrix SEMAPHORES 25
DGUX SEMAPHORES 25
DECOSF SEMAPHORES 16
Other UNIX 32
Experiencia
Los semáforos son usados para notificación de bloqueos y eventos. En teoría, Interbase debería usar pocos semáforos y 32 debería ser suficiente.
Indicaciones de uso
Si usted ve el mensaje de error "semaphores are exhausted" (semáforos agotados) en el archivo de seguimiento de Interbase , aumente el número de semáforos en incrementos por el valor listado arriba como valor defecto.
Parámetros
#V4_LOCK_SIGNAL 16
#ANY_LOCK_SIGNAL 16
Efecto
Éste cambia la señal utilizada para indicar conflictos de bloqueo.
Experiencia
En "Clásico", cuando un proceso mantiene bloqueada una página o algún otro recurso que otro proceso necesita, el segundo proceso señaliza al primero. Cambie la señal usada asignado cualquiera de éstos parámetros (mejor si es ambos). La señal usada por defecto depende del sistema.
NETWARE_386 BLOCKING_SIGNAL 101
WINDOWS_ONLY BLOCKING_SIGNAL 101
Todos los demás: BLOCKING_SIGNAL SIGUSR1
Indicaciones de uso
Las señales tienden a ser "ruidosas", varios servicios pueden usar la misma señal. Interbase está diseñado para vivir con señales ruidosas. Cuando recibe una señal, pasa la señal a otros manipuladores de la misma señal y no es particularmente quisquilloso de recibir la señal y encontrar que no tiene nada que hacer con ésta.
Si otro proceso en el sistema está usando la misma señal que Interbase y no pasa la señal a otros manipuladores o es quisquilloso cuando ve señales que no le sirven, usted verá conexiones de Interbase que se inhiben o errores desde otros procesos. En ese caso puede usar este parámetro para seleccionar otra señal.
TAMAÑO DE MEMORIA PARA EVENTOS
Parámetros
#V4_EVENT_MEM_SIZE 32768
#ANY_EVENT_MEM_SIZE 32768
Efecto
Éste parámetro asigna el tamaño inicial de la memoria a asignar para la tabla de eventos.
Experiencia
La tabla de eventos es mantenida en memoria mapeada. En "Clásico", éste espacio es creado para cada conexión. En "Súper Servidor", hay un espacio compartido por todos los clientes.
Indicaciones de uso
La tabla se expande dinámicamente por lo que aparentemente no hay razón para asignar éste parámetro.
Parámetro
#DATABASE_CACHE_PAGES 75
Efecto
Este parámetro asigna el número de páginas para cada base de datos que pueden mantenerse en caché al mismo tiempo. Si usted incrementa éste valor, Interbase alojará más páginas en el caché para cada base de datos abierta. Por defecto, el "Súper Servidor" aloja 2048 páginas para cada base de datos abierta y el "Clásico" aloja 75 páginas por cliente por base de datos. En Windows de 16 bits, el defecto es de 50 página.
Experiencia
El caché mantiene páginas leídas desde la base de datos y páginas que están siendo creadas para luego almacenarse en la base de datos. El propósito es reducir el número de veces que una página es leída o escrita manteniéndola en caché hasta que una operación comprometer u otro evento fuerza que sea escrita. Mientras mas grande el caché, más páginas se mantienen en memoria.
El valor mínimo es 50 y el máximo es 65,535. Empíricamente, valores arriba de 10,000 reduce el desempeño.
Usted puede alterar el tamaño de caché para cada base de datos en forma individual (en "Súper Servidor") o para el par cliente / base de datos por medio de un parámetro de conexión disponible en ISQL, en el administrador de servidor y en IBConsole.
Interbase no incrementa dinámicamente el tamaño del caché debido a que un caché demasiado grande puede tener tanto efecto negativo como uno muy pequeño. Por ejemplo, una inserción masiva trabaja mejor con un caché relativamente pequeño debido a que las páginas que se llenan no son visitadas nuevamente. Aplicaciones que usan frecuentemente tablas de búsqueda pueden usan un caché más largo para mantener esas tablas en memoria.
Indicaciones de uso
Si parece que hay mucha actividad de E/S en su servidor y el número de páginas alojadas es menor a 10,000, incrementar el tamaño del caché puede mejorar el desempeño.
CLASE DE PRIORIDAD DEL SERVIDOR
Parámetro
#SERVER_PRIORITY_CLASS 1
Efecto
Asigna la clase de prioridad para "Súper Servidor" en Windows/NT/2000. Colocar un valor de 2 hace la clase de prioridad del proceso HIGH_PRIORITY_CLASS. Todos los demás valores producen NORMAL_PRIORITY_CLASS. Por defecto éste parámetro es 1.
Experiencia
Con el incremento de la prioridad del proceso, usted puede causar que el servidor obtenga más ciclos en un sistema compartido. Si usted se preocupa por el desempeño, usted debería mejor colocar el servidor en un sistema mono procesador dedicado. Si usted depende del aumento de desempeño al ejecutar clientes en el mismo sistema por el uso de memoria compartida en vez de TCP, obtenga un sistema de procesadores múltiples, amarre el servidor a uno de los procesadores y ejecute los clientes en otro.
Indicaciones de uso
Soy prejuiciosa acerca de éste parámetro, pero si quiere probar, adelante.
N del T: He usado éste parámetro en Windows 9X en instalaciones de clientes pequeños que no pueden costear el uso de un servidor dedicado y desean usar una de sus computadoras existentes como servidor de base de datos. El efecto es que el usuario de ésa computadora sufre detenciones momentáneas de sus tareas cuando otro usuario ejecuta tareas de análisis de datos. Para el procesamiento de OLTP pocas veces sufre de éstas detenciones.
Parámetro
#SERVER_CLIENT_MAPPING 4096
Efecto
Este parámetro asigna el tamaño del área reservada en el espacio mapeado usado en Windows para comunicación entre el servidor y el cliente que se ejecutan en la misma máquina. El tamaño por defecto es de 4K.
Experiencia
En sistemas Windows (y solo en sistemas Windows) un cliente ejecutándose en el mismo sistema que el servidor se comunica a través de una región de memoria compartida en vez de TCP. Use éste parámetro para controlar el tamaño de dicha región. La memoria alojada es en bloques de 1024 bytes. El rango de valores aceptado es entre 1 y 16 bloques de 1K. El valor debe ser 1024, 2048, 3072, 4096, 5120, 6144, 7165, 8192, 9216, 10240, 11264, 12288, 13312, 14336, 15360 o 16384. El valor será dividido entre 1024 internamente. ?Por qué no hacer éste parámetro entre 1 y 16?. Quién sabe.
Indicaciones de uso
Si usted tiene mucha memoria y muchos clientes "locales", incrementar el área de comunicaciones puede ayudar.
TAMAÑO DE MEMORIA DE TRABAJO DEL SERVIDOR
Parámetros
SERVER_WORKING_SIZE_MIN 0
SERVER_WORKING_SIZE_MAX 0
Efecto
Este asigna el número de bloques de 1024 bytes disponibles al "Súper Servidor" como su conjunto de trabajo en Windows/NT/2000. Si los valores son chequeados para algo, no veo donde se realiza. Por defecto, ambos valore son cero, lo que significa que no tiene límites.
Experiencia
Limitar el conjunto máximo de trabajo puede causar que el "Súper Servidor" caiga muerto antes de tiempo por falta de memoria. Incrementar el conjunto mínimo de trabajo puede causar que se aloje memoria innecesaria.
Indicaciones de uso
Aumentar el conjunto mínimo de trabajo puede eliminar algún procesamiento en el servidor mientras crece. Asignar el conjunto máximo de trabajo puede evitar que el servidor tome toda la memoria en un sistema con poca memoria. No ejecute "Súper Servidor" en sistemas con poca memoria.
ORDEN DE CONCESIÓN DE BLOQUEOS
Parámetro
#V4_LOCK_GRANT_ORDER 1
Efecto
Asigna el estado de ordenamiento de concesión de bloqueo. 1 es verdadero y habilita el ordenamiento de concesión de bloqueo. 0 es falso y deshabilita el ordenamiento de concesión de bloqueo. Por defecto, el ordenamiento de concesión de bloqueo está deshabilitado.
Background
El ordenamiento de concesión de bloqueo es bastante simple, siempre que usted comprenda bastante acerca de bloqueos. Cuando una conexión solicita un bloqueo en un objeto, lo solicita en un nivel específico:
#define LCK_none 0
#define LCK_null 1 /* Existente */
#define LCK_SR 2 /* Lectura Compartido */
#define LCK_PR 3 /* Lectura Protegido */
#define LCK_SW 4 /* Escritura Compartido */
#define LCK_PW 5 /* Escrituta Protegido */
#define LCK_EX 6 /* Exclusivo */
Se solicita LCK_none para convertir un bloqueo en no bloqueo. LCK_null es un bloqueo que ya existe y lo toma una conexión a la cuál no le importa que pase con el objeto, siempre y cuando no desaparezca. Éste es el tipo de bloqueo usado para asegurarse que se preservan los índices mientras se compila una solicitud que dependa de éstos. La interacción de los niveles de bloqueo está descrita en la tabla de compatibilidad de bloqueos. En ésta tabla, 1 indica que el bloqueo es compatible, 0 que no lo es.
/* none null SR PR SW PW EX */
/* none */ 1, 1, 1, 1, 1, 1, 1,
/* null */ 1, 1, 1, 1, 1, 1, 1,
/* SR */ 1, 1, 1, 1, 1, 1, 0,
/* PR */ 1, 1, 1, 1, 0, 0, 0,
/* SW */ 1, 1, 1, 0, 1, 0, 0,
/* PW */ 1, 1, 1, 0, 0, 0, 0,
/* EX */ 1, 1, 0, 0, 0, 0, 0 }
Cuando una conexión quiere bloquear un objeto, obtiene un bloque de solicitud de bloqueo que especifica el objeto y el nivel de bloqueo solicitado. Cada objeto bloqueado posee un bloque de solicitud de bloqueo. Los bloques de solicitud están conectados a estos bloques ya sea como solicitud concedida o como solicitud pendiente de conceder.
Originalmente, si un objeto ha sido bloqueado por una conexión para lectura protegida, otras conexiones que deseen lectura protegida (o menor) son movidas al frente de la cola, ya que pueden concederse inmediatamente. Bajo carga pesada, esto causa que conexiones que necesitan niveles de bloqueo superior esperen indefinidamente, porque nuevos lectores están llegando constantemente.
Indicaciones de uso
Si sus operaciones de escritura tienen menor prioridad que las de lectura, habilitar el ordenamiento de bloqueo puede mejorar la velocidad de los lectores, particularmente transacciones de lectura largas. Recuerde que también los lectores cambian la base de datos. Como mínimo, registran su estado de transacción.
El parámetro de ranuras hash de bloqueo ha sido removido de la versión 6 de ibconfig, al menos en la versión que vi como parte de "Súper Servidor" de NT. El código para leer e interpretar el parámetro aún existe.
Parámetro
#LOCK_HASH_SLOTS 101
Efecto
Este parámetro determina el ancho de la tabla hash usada para encontrar los bloqueos en objetos específicos. El defecto es 101. El número debe ser primo para ayudar que el algoritmo hash produzca una buena distribución. Éste debe ser entre 101 y 2048.
Experiencia
Piense en la tabla hash como un arreglo lineal con cadenas colgando en cada celda. El administrador de bloqueo aplica una función hash en el nombre del objeto y calcula el residuo de dividir el valor obtenido entre la cantidad de ranuras para determinar la celda de la cuál colgará el bloqueo. Cuando se busca un bloqueo sobre el objeto, se identifica la celda de la misma forma, entonces pasea hacia abajo en la cadena, buscando por el objeto con el nombre correcto. Si hay más de un objeto con ese nombre, camina por la cadena de homónimos que cuelga de el primer objeto en que coincide el nombre.
?Comprendió? Mientras mas largas sean las cadenas que cuelgan en cada ranura, más lento será el administrador de bloqueos. La utilidad "Lock print" le mostrará el mínimo, máximo y promedio de las cadenas. Un buen promedio es debajo de 10.
Indicaciones de uso
La primera indicación será un desempeño pobre en un sistema con muchos usuarios y mucho caché de páginas. Ejecute la utilidad "lock print". Si el largo promedio de las cadenas hash es mayor a 10, ajuste las ranuras hash. Como inicio, multiplique el largo promedio por el número actual de ranuras y divídalo entre 9, entonces ajústelo al siguiente número primo menor a 2048. Si hace este ajuste en un "Súper Servidor", usted debería incrementar el tamaño de memoria de bloqueo.
TIEMPO DE DETECCIÓN DE BLOQUEO MUTUO
Parámetro
#DEADLOCK_TIMEOUT 10
Efecto
Este parámetro determina el número de segundos que el administrador de bloqueos espera después de encontrar un conflicto antes de decidir que hay un bloqueo mutuo potencial.
Experiencia
Éste parámetro fue probado extensamente, casi veinte años atrás, en sistemas tan lentos que actualmente no podrían controlar una lavadora de platos en tiempo real. En aquel tiempo, 10 segundos era óptimo. Poco más seguido y la máquina era engullida por las búsquedas de bloqueo mutuo. Poco menos seguido y los usuarios irrumpían en el laboratorio y mataban las computadoras.
Indicaciones de uso
Los bloqueos mutuos son bastante raros en Interbase. El error de bloqueo mutuo usual, conflicto de actualización ("Update Conflict"), no es en realidad un bloqueo muto detectado por el administrador de bloqueos. Sería interesante elaborar un caso verdadero de bloqueo mutuo (A actualiza registro 1, B actualiza registro 2, entonces A intenta actualizar registro 2 y B intenta actualizar registro 1, todo sin comprometer) y variar el tiempo de detección de bloqueo mutuo para ver que implicaciones de desempeño hay.
INTENTOS DE ACCESO A TABLA DE BLOQUEOS
Parámetro
LOCK_ACQUIRE_SPINS 0
Efecto
En "Súper Servidor" ? aparentemente ninguno. En "Clásico", solo un proceso de cliente puede acceder a la tabla de bloqueos en cualquier momento. El acceso a la tabla de bloqueos es gobernada por un mutex. El mutex puede solicitarse condicionalmente ?una espera es una falla y la solicitud debe intentarse nuevamente ? o incondicional ? la solicitud esperará hasta que sea satisfecha. Éste parámetro establece el número de intentos que se harán condicionalmente. El valor defecto es cero.
Experiencia
Parece que el mutex es solicitado condicionalmente cierto número de veces, determinado por el parámetro LOCK_ACQUIRE_SPINS, luego cae en solicitud incondicional. El comentario sugiere que puede haber algún mérito en maquinas SMP. Lo dudo.
Indicaciones de uso
Ninguna.
INTERVALO DE CHEQUEO DE CONEXIÓN
Parámetro
CONNECTION_TIMEOUT 180
Efecto
Asigna el intervalo de tiempo entre cada chequeo de conexión de cliente para determinar si ésta sigue siendo válida. El defecto es 180 segundos.
Experiencia
Para detectar clientes que se han desconectado anormalmente, incluyendo clientes Windows que han apagado su computadora sin haber cerrado la aplicación, Interbase envía un "select" falso con tiempo un tiempo de espera. Si el tiempo de espera del "select" se agota, Interbase envía un paquete falso al cliente. Si el envío falla, Interbase elimina la conexión.
Usted puede ajustar el tiempo de espera asignando éste parámetro o incluyendo en el dbp ("database parameter block" ? bloque de parámetros de base de datos) la opción isc_dpb_connect_timeout.
Indicaciones de uso
Mientras mayor el valor, verá menor tráfico de paquetes falsos. Por otro lado, la detección de conexiones "muertas" será demorada. La recomendación es que incremente el valor significativamente si hay certeza que los clientes no se desconectarán anormalmente.
INTERVALO DE ENVÍO DE PAQUETE FALSO
Parámetro
DUMMY_PACKET_INTERVAL 60
Efecto
Éste parámetro determina la frecuencia con que serán enviados paquetes falsos para verificar que el cliente aún existe. El defecto es sesenta segundos.
Experiencia
Interbase cierra las conexiones cuando el cliente a dejado de responder. Para detectar que el cliente ya no responde, el servidor espera un intervalo de tiempo fijo (parámetro CONNECTION_TIMEOUT) entonces envía paquetes falsos para mantener viva la conexión. Cuando recibe un error al enviar, asume que el cliente a muerto.
Usted puede ajustar la frecuencia con la que se envían paquetes falsos ya sea con éste parámetro de configuración, o con el dbp ("database parameter block" ? bloque de parámetros de base de datos, valor: isc_dpb_dummy_packet_interval).
Indicaciones de uso
Mientras mayor el valor, verá menor tráfico de paquetes falsos. Por otro lado, la detección de conexiones "muertas" será demorada. La recomendación es que incremente el valor significativamente si hay certeza que los clientes no se desconectarán anormalmente.
DIRECTORIO PARA ARCHIVOS TEMPORALES
Parámetro
TMP_DIRECTORY
TMP_DIRECTORY 20000 "/opt/interbase/tmp"
Efecto
Éste parámetro puede usarse un número de veces arbitrario para especificar las ubicaciones de los archivos temporales. El tamaño es en bytes. Si éste parámetro de configuración no existe, Interbase chequea las siguientes variables de ambiente: INTERBASE_TMP, TMP y TEMP. Éste parámetro es válido solo para "Súper Servidor".
Experiencia
Interbase usa archivos temporales para varias operaciones, principalmente para almacenar resultados intermedios de ordenamiento. Éste parámetro de configuración le permite especificar una lista de directorios para ser usados por archivos temporales. Repita el parámetro para indicar directorios adicionales.
Dado que tengo menos del 100% de seguridad de mi destreza en scanf, he aquí la forma en que se obtiene el valor:
if ( (n = sscanf(buf + sizeof(ISCCFG_TMPDIR) - 1,
" %ld \"%[^\"]", &size, dir_name)) == 2 )
Indicaciones de uso
Éste es el modo de indicar varios directorios temporales y especificar la cantidad de espacio que será usado en cada uno de ellos.
DIRECTORIO DE FUNCIONES EXTERNAS
Parámetro
EXTERNAL_FUNCTION_DIRECTORY
EXTERNAL_FUNCTION_DIRECTORY "/opt/interbase/my_functions"
Efecto
Éste parámetro puede usarse un número de veces arbitrario para especificar las ubicaciones de las bibliotecas de funciones de usuario. Si éste parámetro de configuración no existe, Interbase chequea las siguientes directorios: INTERBASE/UDF o $INTERBASE/intl. Éste parámetro solo está disponible en "Súper Servidor".
Experiencia
Interbase busca en los directorios específicos las bibliotecas que debe cargar cuando son referenciadas. Éste parámetro le permite especificar cualquier número de directorios en los cuáles Interbase buscará las bibliotecas de funciones definidas por el usuario o definiciones de conjuntos de caracteres. Repita éste parámetro para indicar directorios adicionales.
Indicaciones de uso
Si desea usar mas directorios, o directorios diferentes al defecto, éste parámetro es para usted.
Parámetro
TCP_REMOTE_BUFFER 8192
Efecto
Éste parámetro establece el tamaño máximo de paquete TCP usado en la interfaz cliente servidor. Los valores admitidos son de 1448 a 32768, y son en bytes.
Experiencia
Interbase efectúa lecturas adelantadas y puede enviar varios registros de datos en un solo paquete. Mientras mas grande el tamaño del paquete, mas datos serán enviados en cada transferencia.
Indicaciones de uso
Tráfico de red pesado.
Éste artículo fue escrito por Ann Harrison en octubre de 2000, y es propiedad de la Sra.. Harrison e IBPhoenix Inc. Usted puede republicarlo textualmente, incluyendo esta anotación. Usted puede actualizarlo, corregirlo, expandir el material, con tal que incluya una anotación de que el material original fue producido por Sra. Harrison e IBPhoenix Inc.
La traducción original al castellano fue realizada por Sergio Samayoa (Lógica Software ? logiscasw@terra.com.gt) en julio de 2001. Usted puede actualizar, corregir, expandir el material, con tal que incluya una anotación de que la traducción original al castellano fue realizada por Sergio Samayoa.