Optimizando Transacciones en ASE 12.5

El sistema de log de transacciones es uno de los componente más críticos de un servidor de bases de datos. Para poder llevar a cabo el objetivo de brindar recuperabilidad de bases de datos, las transacciones graban registros de log sobre almacenamiento persistente. Dado que un gran número de tales escrituras de registros de log es directamente dependiente del número de transacciones en ejecución, el sistema de log de transacciones puede potencialmente convertirse en un cuello de botella en ambientes OLTP altamente transaccionales.

Todos los usuarios que se encuentren trabajando en una misma base de datos comparten el mismo log de transacciones; en consecuencia, para garantizar el buen rendimiento de la aplicación, es esencial para el DBA monitorear y configurar el log para garantizar la ejecución del mayor número de transacciones por minuto y los tiempos de respuesta de la aplicación. Recién instalado, Adaptive Server Enterprise (ASE) brinda un subsistema de log de transacciones que permite escalar hasta miles de usuarios y ambientes de bases de datos de gran tamaño (VLDB). ASE también provee opciones para el DBA que le permiten personalizar el subsistema de log para satisfacer cada ambiente particular, obteniendo el mejor rendimiento posible.

Existen dos aspectos en la optimización del subsistema de log:

1. Seguir las mejores prácticas en el diseño de aplicaciones basadas en SQL de tal manera que el subsistema de log sea usado eficazmente.
2. Configurar y afinar el subsistema de log para obtener de él el mejor rendimiento posible.

El primer aspecto es responsabilidad de los diseñadores de aplicación, mientras que el segundo es responsabilidad del DBA. En este documento discutiremos sólo los aspectos relacionados a la configuración del sistema, correspondiente al segundo aspecto.

ASE provee un amplio conjunto de opciones para monitorear y configurar el subsistema de log para ambientes OLTP de alto volumen transaccional. Aparte de implementar varias soluciones de alta tecnología para resolver asuntos relacionados a la contención sobre el log, ASE permite al administrador afinar el subsistema de log para responder a las necesidades y requerimientos de la aplicación. En éste documento presentamos la arquitectura del subsistema de log de ASE y explicamos cómo podemos monitorear y afinar el subsistema para sacar de él el mejor rendimiento posible.

Subsistema de Log de Transacciones

La figura 1 ilustra cómo se lleva a cabo el registro de transacciones en ASE. Cada tarea de usuario tiene un caché privado de log, el cual utiliza para grabar los registros de log durante el procesamiento transaccional. Este se conoce como el Caché de Log del Usuario (ULC por las siglas en inglés de User Log Cache). El Caché de Log del Usuario es privado de la tarea y no es visible para otras tareas. Esto resuelve los principales problemas de contención que de otra manera serían causados por cada tarea al intentar insertar su registro de log en el caché compartido de log. La figira 1 muestra que la transacción de usuario ha populado 3 páginas de log, L1, L2 y L3 en el ULC.

{mosimage}

Durante una operación de commit, estas páginas son primero transferidas al caché compartido de log. Para llevar esto a cabo, la tarea de usuario adquiere un candado para bloquear la porción final de log y luego copia el contenido del ULC al caché compartido del log. Esta operación es conocida como un vaciado ("flush") del ULC. Una vez el vaciado se completa, la tarea libera el bloqueo sobre el log y procede a escribir estas páginas a disco. Esto lo lleva a cabo recorriendo las páginas sucias del caché compartido de log y ejecutando escrituras sobre estas páginas. Una vez las escrituras se completan la tarea indica la finalización de la operación de commit. En caso de que la transacción aborte o de que haya una caída del sistema, el log es leído para reversar cualquier modificación causada por esta transacción.

Existen tres clases de recursos involucrados al subsistema de log de transacciones. Estos son:

• Dispositivo de log

• Caché Compartido de Log

• ULC

Es esencial entender cómo estos recursos son consumidos y manipulados, de tal manera que uno pueda configurarlos apropiadamente.

{mospagebreak} 

El Dispositivo de Log

Es vital para el tiempo de respuesta y para el volumen de transacciones procesadas por una aplicación, configurar apropiadamente el dispositivo de log. Una de las principales características del registro de log, es que los datos se escriben secuencialmente.

Elección del dispositivo de Disco

Los discos de log demandan tiempos de respuesta más rápidos que otros dispositivos de datos. Lo ideal sería que el tiempo de servicio de un dispositivo de log esté por debajo de los 5 milisegundos. Con la cada vez mayor velocidad de las CPUs, las aplicaciones OLTP pueden alcanzar el tope de procesamiento de transacciones muy rápidamente con un disco de log lento. He aquí algunas de las prácticas más recomendadas al momento de seleccionar el disco de log:

• Arreglo tipo RAID 0/1 con controladora con NV RAM para llevar a cabo almacenamiento en caché los datos escritos.
• El tamaño del stripe del RAID debe ser igual o menor que el tamaño de página de log (por ejemplo, si el tamaño de página de log es de 2K, usted puede tener un tamaño de stripe de 1K o 2K).
• Para mejores resultados, el log debe ser mantenido en un disco físico separado. Dado que el acceso a los datos se lleva a cabo de manera aleatoria, el mezclar log y datos puede causar un excesivo movimiento de los brazos del disco. Tales movimientos irregulares del brazo pueden resultar en mayores latencias y tiempos de servicio. Cualquier demora en la escritura de páginas de log puede causar que recursos críticos, como candados, sean mantenidos por mayor tiempo.
• Es recomendado usar "raw devices" en vez de archivos del sistema de archivos para alojar los logs. Por su naturaleza, el log es una operación intensiva en escrituras y un sistema de archivos siempre se comporta pobremente cuando hay más escrituras que lecturas.
• Es recomendado mantener el dispositivo de log bajo una controladora separada para eliminar cualquier contención de dispositivo a nivel de sistema operativo.

Tamaño de pagina del log

La elección del tamaño de página de la base de datos tiene un impacto directo en el rendimiento, por su influencia directa en el número de páginas de log generadas. Si el tamaño de página del servidor es de 2K y si cada transacción genera un gran número de páginas de log, entonces el servidor llevará a cabo demasiadas escrituras de páginas de log. En tales casos, aumente el tamaño de página para ver si el número de operaciones de Lectura/Escritura (incluyendo páginas de log) baja. Es muy importante notar que al aumentar el tamaño de página para la base de datos, no solamente afectamos las operaciones de Lectura/Escritura en las páginas de log, sino también en las páginas de datos.

De otra parte, con un tamaño de página grande, si el sistema no está escribiendo suficientes registros para llenar la página de log, entonces es posible que el servidor esté llevando a cabo escrituras sobre la última página del log más de una vez. La escritura de páginas a medio llenar al final de log puede causar que la tarea salga de su contexto de ejecución (y pase por ejemplo a un estado de SLEEP). El sistema de log de ASE utiliza un algoritmo que reduce el número de tales escrituras parciales sobre la última página del log. Pero si la página se llena muy lentamente, entonces no es práctico demorar la escritura sobre la última página del log hasta que ésta esté completamente llena. En consecuencia, es esencial seleccionar el tamaño de página apropiado basado en la velocidad a la cual las páginas de log son llenadas.

Log en un dispositivo de Base de Datos separado

Las escrituras al log ocurren frecuentemente así que es imperativo que el dispositivo de log no entre en contienda con otras operaciones de Lectura/Escritura en la base de datos, que son típicamente aleatorias por naturaleza. Es recomendable que el log sea mantenido en un dispositivo de base de datos separado, residente sobre un disco aislado. Mantener datos y log sobre el mismo dispositivo puede resultar en:

• Escrituras mezcladas con lecturas.
• Patrones irregulares de escritura que resultan en mayor latencia de los discos.
• Escrituras adicionales del servidor para asegurar la consistencia al tratar de mantener log y datos en el mismo dispositivo.

Recomendaciones para la configuración de los discos de log

• Asegúrese que el disco de log esté aislado de otros discos de datos y de que tenga tiempos óptimos de respuesta; es recomendado que se tenga redundancia a nivel de hardware para asegurar la recuperabilidad (por ejemplo RAID 0/1).
• Selecciones apropiadamente el tamaño de página de la base de datos basándose en el volumen de transacciones y número de páginas de log generadas por cada transacción individual.
• Siempre mantenga el log sobre un dispositivo de bases de datos separado.

{mospagebreak}

Configuración del Caché de Log

El caché de log representa el conjunto de trabajo de las páginas de log que residen en memoria. Si no hubiera un caché con nombre configurado para el log de transacciones, las páginas de log residirían en el default data cache. Sin embargo, hacer que las páginas de log residan en el default data cache puede resultar en tiempos de respuesta muy malos, bajo un ambiente OLTP de alto volumen transaccional. Esto es debido a que las páginas de log pueden reemplazar páginas de datos que residen en caché. Para evitar tales operaciones de Lectura/Escritura, es recomendado asociar el log a su propia caché y separarlo de las páginas de datos. A continuación se muestra cómo se puede hacer esto.

Primero, configure un cache para el log poniendo las siguientes opciones en el archivo de configuración de ASE:

[Named Cache:log_cache]
        cache size = tamaño
        cache status = log only
        cache replacement policy = DEFAULT
        local cache partition number = 1

Asocie el caché al log ejecutando el siguiente comando:

sp_bindcache "log_cache", base_de_datos, "syslogs"
go

Note que la base de datos debe estar en modo mono usuario (opción "single user") y se requiere ejecutar un checkpoint una vez se defina la opción.

El tamaño del caché del log depende de número de transacciones y del tiempo de respuesta para las operaciones de rollback. Un caché más grande ayudará a reducir el tiempo de respuesta de las operaciones de rollback, ya que potencialmente puede poner en caché una gran parte de las páginas de log requeridas para el rollback.

Es más recomendado definir la opción "local cache paritition" para el caché del log en 1 debido a la naturaleza serial del log.

 Configuración del Tamaño de Página de Log

El tamaño de página de log especifica la unidad de Lectura/Escritura sobre el log de transacciones. Para conseguir una unidad particular de Lectura/Escritura para el log, el caché para el log de transacciones debe ser configurado con un banco ("pool") memoria de tamaño adecuado. En general, los sistemas OLTP altamente transaccionales se ven beneficiados de usar unidades más grandes de Lectura/Escritura para el log de transacciones. La siguiente sección brinda algunas recomendaciones sobre cómo determinar el tamaño de Lectura/Escritura de log ideal para un ambiente de producción. Ejecutando sp_sysmon sobre el sistema de producción puede brindar pistas sobre lo que debe hacerse. Basándose en el reporte generado por sp_sysmon, uno puede inferir el afinamiento del tamaño de Lectura/Escritura.

• Aumente el tamaño de Lectura/Escritura del log si:

	El dispositivo de log está sobrecargado ya que el servidor está llevando a cabo demasiadas escrituras; con un tamaño de Lectura/Escritura mayor, múltiples escrituras son llevadas a cabo en una sola operación.
	El volumen de transacciones por minuto es un requerimiento muy importante y la lógica de commit en Grupo es efectiva; mire la línea "Task Log Page Writes" en la sección "Task Management" de sp_sysmon, y asegúrese que todos los valores sean relativamente bajos.

Task Management                       per sec  per xact count % of total
---------------------            ------------ --------- ------- --------
Task Context Switches by Engine
   Engine 0
  :
  :
Last Log Page Writes                     13.8      0.01     256    0.05 %

Existen requerimientos rigurosos sobre los tiempos de respuesta y el volumen de transacciones del sistema es alto también, en tales casos asegúrese de que haya suficientes recursos de CPU disponibles para asegurar que el commit en Grupo funcione; para mayor información sobre éste tema haga referencia a la sección "Task Management" del capítulo "Monitoring Performance with sp_sysmon" del manual "Performance & Tuning".

• Reduzca el tamaño de Lectura/Escritura del log si:

-	La sección de perfil de transacciones ("transaction profile") de sp_sysmon indica una baja rata de transacciones.
-	El tiempo de respuesta es un requerimiento crítico para la aplicación y el volumen de transacciones procesadas no es tan importante. Uno debe asegurarse de que el subsistema de Lectura/Escritura tiene suficiente ancho de banda para ser capaz de manejar las operaciones de Lectura/Escritura adicionales. De no ser así, reducir el tamaño de Lectura/Escritura del log podría potencialmente causar degradación de tiempos de respuesta.
-	El valor de "Avg # writes per log page" del reporte de sp_sysmon es mucho más alto que el valor mínimo posible (por ejemplo 0.5 en el caso de un servidor con tamaño de página de 2K donde el tamaño de Lectura/Escritura de log es de 4K).

Para poder aumentar el tamaño de Lectura/Escritura del log es necesario llevar a cabo los siguientes pasos.

[Named Cache:log_cache]
        cache size = 100M
        cache status = log only
        cache replacement policy = DEFAULT
        local cache partition number = 1

[4K I/O Buffer Pool]
        pool size = 50M
        wash size = 4000K
        local async prefetch limit = DEFAULT

1> use my_db
2> go
1> sp_logiosize "4K"
2> go

Log I/O size is set to 4 Kbytes.
The transaction log for database 'my_db' will use I/O size of 4 Kbytes.
(return status = 0)

El tamaño predeterminado de Lectura/Escritura para el log es de 4K. Así que, si existe un "pool" de "buffers" de 4K para el default data cache cuando no existen cachés con nombre para el log de transacciones o para el caché con nombre al cual el log de transacciones está asociado, el servidor automáticamente llevará acabo operaciones usando bloques de 4K.

{mospagebreak}

Recomendaciones para Configurar el Caché de Log

La siguiente sección brinda un conjunto general de recomendaciones sobre cómo configurar el caché de log para mejores resultados.

1. Para bases de datos OLTP de alto volumen transaccional, es recomendado dedicar un caché con nombre para el log de transacciones de la base de datos.
2. También se recomienda tener un "pool" de "buffers" de tamaño grande para el caché con nombre. El tamaño predeterminado de Lectura/Escritura de log para un servidor con tamaño de página de 2K es de 4K. Así que tener un "pool" de "buffers" de 4K ayudará a mejorar el rendimiento de las operaciones de Lectura/Escritura de log bajo ciertos escenarios que fueron explicado antes.
3. Si la aplicación es sensitiva al tiempo de respuesta de las operaciones de rollback, entonces es importante tener eso en cuenta al definir el tamaño del caché con nombre y de los "pools" de "buffers" asociados.
4. Si la aplicación usa triggers que hacen referencia a las tablas inserted y deleted extensivamente, eso también jugará un rol en determinar el tamaño del caché con nombre.
5. Si la aplicación lleva a cabo actualizaciones en modo diferido frecuentemente, entonces el tamaño del caché con nombre para el log de transacciones también debe tomar en cuenta eso.

El caché de Log de Usuario

Existe un caché de log de usuario por cada conexión de usuario configurada. ASE usa estos cachés de usuario para almacenar allí los registros de log de la transacción del usuario, lo que reduce la contención al final del log de transacciones, espacialmente en sistemas SMP. Cuando un caché de log de usuario se llena o cuando otro evento ocurre (tal como cuando la transacción finaliza), ASE lleva a cabo un "vaciado" de todos los registros de log del caché de log de usuario hacia el log de transacciones de la base de datos. El parámetro de configuración del servidor "user log cache size" controla el tamaño del ULC asignado a cada conexión de usuario. Esta opción puede ser cambiada editando el archivo de configuración o usando el procedimiento sp_configure, como se muestra a continuación.

[User Environment]
user log cache size = 4096
userlog cache spinlock ratio = DEFAULT

o

1> sp_configure "user log cache size", 4096
2> go
Parameter Name         Default  Memory Used  Config Value  Run Value  Unit   Type
--------------         -------  -----------  ------------  ---------  ----   ----
user log cache size    2048               0          4096       2048  bytes  static

Note que esta opción es estática y requiere que el servidor sea reiniciado para que el cambio entre en efecto.

Recomendaciones para Configurar el Caché de Log de Usuario

Para determinar el tamaño correcto del caché de log de usuario, identifique el máximo número de registros de log escritos por las transacciones de la aplicación y configure el "user log cache size" en ese valor. El tamaño del ULC también debe ser validado, ejecutando sp_sysmon durante un período de cargue representativo. Si el valor de "ULC Flushes to Xact Log" es alto por cuenta de "by Full ULC", entonces aumentar el "user log cache size" podría ayudar. En el siguiente ejemplo, el porcentaje de vaciados del ULC ("ULC Flushes") en razón a que el ULC estaba lleno ("by Full ULC") es de 70%, así que aumentar el tamaño del ULC en este caso podría ayudar.

ULC Flushes to Xact Log    per sec    per xact    count    % of total
-------------------------  -------    --------   ------     ---------
by Full ULC                   21.0        55.0     5435        70.0 %

Si hay un alto porcentaje de "ULC Flushes to Xact Log" por cuenta de "By change of database", ayudaría ver si la aplicación puede potencialmente usar una sola base de datos.

ULC Flushes to Xact Log    per sec    per xact    count    % of total
-------------------------  -------    --------    -----    ----------
by change of database         13.0        30.0     4356        57.0 %

Si hay un alto porcentaje de "ULC Flushes to Xact Log" por cuenta de "By Other", una de las causas potenciales podría ser por tener un número de tablas con bloqueo a nivel de fila. Selectivamente identificando las tablas que requieren bloqueo a nivel de fila usando sp_object_stats y utilizando bloqueo a nivel de página para las demás, podría potencialmente aliviar éste problema.

ULC Flushes to Xact Log    per sec    per xact    count    % of total
------------------------- --------    --------    -----    ----------
by Other                       0.0         0.0     8934      89.0 %

Si el valor de "Log Semaphore Requests" tiene un alto porcentaje, podría ser bueno evaluar algunas de las características de "Registro Avanzado de Transacciones en ASE", tales como el "Async Log Service". Más detalles en la siguiente sección.

{mospagebreak}

Registro Avanzado de Transacciones en ASE

Sybase ASE ha demostrado ser el servidor de bases de datos más utilizado para aplicaciones OLTP de alto volumen transaccional con exigentes requerimientos de tiempos de respuesta. La consolidación a nivel de servidor y a nivel de base de datos son tendencias reales que emergen en el mercado. Los clientes constantemente están actualizando sus sistemas de 4-8 CPUs a 16-32 CPUs, y aún hasta máquinas de 64 CPUs, capaces de ejecutar millones de transacciones, y brindando una más fácil administración y un menor costo de propiedad. La arquitectura de ASE se mantiene al paso con el constantemente creciente número de CPUs. Las CPUs adicionales aumentan la contención sobre los recursos compartidos clave tales como el log y los "spinlocks" que sirven de guardianes para otros recursos importantes. Para permitir que ASE escale sobre estas potentes máquinas, un nuevo servicio llamado "Asynchronous Logging" se introdujo en ASE 12.5.0.3. La idea principal de este servicio es eliminar el sobrecosto de que sean las tareas de usuario las que escriban los datos de log, creando "threads" dedicados a escribir datos del ULC al caché del log y a vaciar el caché de log a disco. 

Para habilitar el servicio de "Asynchronous Logging" en una base de datos específica en ASE 12.5.0.3, ejecute el siguiente comando:

1> use master
2> go
1> sp_dboption base_de_datos, "async logging service", "true"
2> go
1> use base_de_datos
2> go

Este servicio debería ser usado si la base de datos experimenta alguno de los siguientes síntomas:

• Alta contención sobre la última página del Log:

Log Semaphore Requests
   Granted                      0.8   2.0   20   20.0 %
   Waited                       3.2   8.0   80   80.0 %
-------------------------    ------ ----- ----   ------
Total Log Semaphore Req               4.0  1.0    100

• Alta contención sobre el "spinlock" del administrador del log para el caché del log:

Cache: default data cache
                             per sec   per xact   count   % of total
   ----------------------    -------   --------   -----   ----------
   Spinlock contention          n/a        n/a      n/a       54.0 %

• El ancho de banda el dispositivo de log está subutilizado.

Habilitando los servicios de "Asynchronous Logging" sobre una base de datos específica, dos "threads" dedicados del sistema serán utilizados para llevar a cabo los vaciados del ULC y para escribir las páginas de log del caché compartido de log a disco, para esa base de datos. No se recomienda habilitar esta característica bajo condiciones de poca carga del sistema, o en sistemas de menos de 4 CPUs. Para mayor información haga referencia a la documentación de ASE 12.5.0.3.

Conclusión

Un subsistema de log de transacciones óptimo es crítico a la hora de proveer altos niveles de procesamiento transaccional y para satisfacer requerimientos exigentes de tiempos de respuesta. Este documento cubrió los aspectos críticos del subsistema de log de transacciones de ASE y resumió las principales recomendaciones para afinar cada componente:

• Dispositivo de Log

-	Asegúrese de que los tiempos de respuesta de las operaciones de Lectura/Escritura sobre el dispositivo de log están dentro de los límites razonables
-	No mezcle datos y log sobre el mismo dispositivo

• Caché del Log

-	Se recomienda configurar Lectura/Escritura de 4K para sistemas típicos OLTP con alto volumen transaccional
-	También es muy recomendado tener un caché con nombre separado para el log de transacciones de las bases de datos de alto volumen transaccional

• ULC

-	Asegúrese de que el tamaño del ULC es adecuado basándose en la cantidad de registros de log que cada transacción de la aplicación genera
-	El ULC puede reducir significativamente la carga sobre el subsistema de log de transacciones en ambiante OLTP altamente concurrentes

• "Asynchronous Logging Service"

-	Use esta característica para resolver la contención sobre el log en sistemas OLTP de alto volumen transaccional que corran sobre máquinas SMP de gran escala

Sybase ASE ha demostrado excepcionales niveles de escalabilidad en pruebas de rendimiento OLTP tales como TPC-C y otras pruebas de clientes. Esto ha sido posible gracias al eficaz y escalable sistema de log de transacciones de ASE. Más información detallada sobre cada uno de los temas cubiertos en éste documento puede ser encontrada en http://sybooks.sybase.com/asg1250e.html.