Consideraciones acerca del rendimiento de la base de datos (DB2)
La base de datos suele ser una de las áreas potenciales de cuellos de botella que hacen que WebSphere Commerce no pueda escalar y ejecutar correctamente. Por consiguiente, es crucial que la base de datos se ajuste a la implementación.
Consideraciones acerca del entorno físico
Las consideraciones acerca del entorno físico están relacionadas con el modo en que se distribuyen los datos entre los discos y con el modo en que se gestiona la memoria para las bases de datos.
Diseño en disco
Es posible que en cualquier aplicación que acceda a una base de datos se produzca un cuello de botella al leer en la base de datos y volver a grabar en ella (E/S de disco). El diseño adecuado de la base de datos puede ayudar a reducir el potencial para este cuello de botella. Dado que el cambio de diseño físico de la base de datos una vez que ésta se crea representa un esfuerzo significativo, la planificación correcta en las etapas iniciales es importante.
La primera consideración es asegurarse de que los registros de transacciones de DB2 residen en el propio disco físico. Cada actualización que se emite en la base de datos se graba en los registros (además de actualizarse en la memoria). De este modo hay muchas E/S de disco en la ubicación donde residen los registros de transacciones de DB2. Es conveniente asegurarse de que toda la actividad de lectura/grabación en disco sólo está relacionada con los registros de transacciones, eliminando de este modo cualquier contención de E/S con otros procesos que puedan acceder al disco.
Para establecer la ubicación de los registros de transacciones de DB2, emita el mandato siguiente:
db2 update db cfg for dbalias using NEWLOGPATH path
Antes de que se almacenen los registros en la ubicación que se especifique, desconecte todas las sesiones o desactive la base de datos emitiendo el mandato db2 deactivate.
La segunda consideración en términos de diseño de disco es determinar cómo gestionar los espacios de tabla de forma eficiente. Un principio de rendimiento en la gestión de RDBMS (Relational Database Management Systems - sistemas de gestión de bases de datos relacionales) es separar los datos de tabla de base de datos y los datos de índice de base de datos en discos físicos diferentes. Esta separación permite un mejor rendimiento de las consultas, puesto que se pueden ejecutar exploraciones de índice en paralelo con operaciones de captación de datos porque están en discos físicos diferentes.
En DB2, los espacios de almacenamiento de tabla automáticos se utilizan de forma predeterminada. Es decir, los tipos de espacio de tabla de almacenamiento gestionado por el sistema (SMS) y de almacenamiento gestionado por la base de datos (DM) están en desuso para espacios de tabla permanentes definidos por el usuario y pueden eliminarse en un release futuro.
- Dispone de tablas más grandes o de tablas que es probable que crezcan más rápidamente
- No desea tomar decisiones regulares sobre cómo gestionar el crecimiento del contenedor.
- Desea poder almacenar diferentes tipos de objetos relacionados (por ejemplo tablas, LOBs, índices) en diferentes espacios de tabla para mejorar el rendimiento.
Para obtener más información, consulte Comparison of automatic storage, SMS, and DMS table spaces.
Memoria
DB2 asocia memoria para la base de datos mediante objetos de agrupación de almacenamiento intermedio. Una agrupación de almacenamiento intermedio tiene un tamaño de página asociado y está enlazada con uno o más espacios de tabla. De este modo, si se crean espacios de tabla de tamaños de página diferentes, son necesarias agrupaciones de almacenamiento intermedio correspondientes a los diferentes tamaños de página.
Aunque pueda crear varias agrupaciones de almacenamiento intermedio que tengan el mismo tamaño de página, se recomienda crear sólo una agrupación de almacenamiento intermedio por tamaño de página, a fin de realizar el uso más eficiente de la memoria en el servidor de bases de datos.
La cuestión es siempre la cantidad de memoria que se debe asignar a las agrupaciones de almacenamiento intermedio. Para implementaciones de DB2 de 32 bits, existe un límite, basado en el sistema operativo, que puede estar disponible para las agrupaciones de almacenamiento intermedio.
Suponiendo un servidor de bases de datos dedicado, asigne una gran proporción de memoria disponible en el servidor, entre el 75% y 80%, pero sin exceder los límites de plataforma.
Tenga en cuenta que para implementaciones de 64 bits de DB2, los límites se incrementan. En este caso, será necesario supervisar la proporción de accesos a la agrupación de almacenamiento intermedio para determinar el valor óptimo de las agrupaciones de almacenamiento intermedio. También puede supervisar la proporción de accesos para la implementación de 32 bits utilizando instantáneas de base de datos utilizando el mandato siguiente:
db2 get snapshot for database on <dbalias>
La salida que se genera contiene algunas estadísticas sobre lecturas lógicas y físicas de agrupación de almacenamientos intermedios :
Buffer pool data physical reads = DPR
...
Buffer pool index logical reads = ILR
Buffer pool index physical reads = IPR
En esta salida, DLR, DPR, ILR e IPR tienen valores reales. La proporción de accesos se puede calcular utilizando la fórmula siguiente:
(1 - (( DPR + IPR) / (DLR + ILR))) * 100%
El tamaño de la agrupación de almacenamiento intermedio se puede cambiar a través del mandato ALTER BUFFERPOOL o el parámetro BUFFPAGE si el tamaño de la agrupación de almacenamiento intermedio se estableció en -1.
Parámetros de base de datos de ajuste y configuración adicionales
Hay muchos parámetros a tener en cuenta para el rendimiento. Este apartado describe un subconjunto de los parámetros que se consideran importantes para las implementaciones de HCL Commerce. Para establecer los valores de los parámetros, se puede utilizar el mandato siguiente:
db2 update db cfg for <dbalias> using <paramname> <paramvalue>
Parámetros relacionados con la memoria
El almacenamiento dinámico de base de datos (DBHEAP) contiene información de bloque de control para objetos de base de datos (tablas, índices y agrupaciones de almacenamiento intermedio), así como la agrupación de memoria de la que se asignan el tamaño de almacenamiento intermedio de anotación cronológica (LOGBUFSZ) y el tamaño de memoria caché de catálogo (CATALOGCACHE_SZ). Su valor depende del número de objetos de la base de datos y del tamaño de los dos parámetros mencionados.
En general, se puede utilizar la fórmula siguiente para calcular el tamaño del almacenamiento dinámico de base de datos:
DBHEAP=LOGBUFSZ + CATALOGCACHE_SZ + (SUM(# PAGES in each bufferpool) * 3%)
El almacenamiento intermedio de registro se asigna del almacenamiento dinámico de base de datos y se utiliza para poner las grabaciones en almacenamiento intermedio en los registros de transacciones para proporcionar una E/S más eficiente. El tamaño predeterminado de este valor es 128 páginas de 4 K. Un punto de partido recomendado para el tamaño de almacenamiento intermedio de registro (LOGBUFSZ) en implementaciones de HCL Commerce es 256.
Parámetros relacionados con las anotaciones cronológicas de transacciones
Al considerar los valores para el tamaño de archivo de anotaciones cronológicas de transacciones (LOGFILSIZ) y el número de registros primarios (LOGPRIMARY) y secundarios (LOGSECOND), se pueden aplicar generalizaciones para las aplicaciones OLTP. Dado que en los sistemas OLTP es típico tener un alto número de transacciones cortas, el tamaño del archivo de registro debe ser relativamente grande o, de lo contrario, se empleará más tiempo de proceso gestionando archivos de registro, en lugar de grabar en los registros de transacciones. Un buen punto de partida para el tamaño del archivo de registro en las implementaciones de HCL Commerce es establecer el valor en 10000.
Los archivos de anotaciones cronológicas primarios se asignan cuando se activa la base de datos o en la primera conexión. Si una transacción de larga ejecución llena todas los registros primarios, se asignan los registros secundarios a medida que se necesiten hasta que se alcance el límite de LOGSECOND. La asignación de un archivo de anotaciones cronológicas secundarias representa un impacto significativo en el rendimiento y se deberá minimizar si no se puede evitar.
Para determinar los valores correctos para estos parámetros, necesita supervisar la base de datos y ver si se están asignando archivos de anotaciones cronológicas secundarias. Si se están asignando, necesita aumentar el número de archivos de registros primarios. Puede realizar la supervisión tomando una instantánea de base de datos y buscando las dos líneas siguientes:
Maximum secondary log space used (Bytes) = 0
Secondary logs allocated currently = 0Un buen punto de partida para el número de archivos de registro primarios (LOGPRIMARY) es cualquiera entre 6 y 10.
Parámetros relacionados con la E/S de disco
Además del diseño de disco físico, se pueden manipular varios parámetros de ajuste para influir en la E/S de disco. Dos parámetros clave son NUM_IOSERVERS y NUM_IOCLEANERS.
NUM_IOSERVERS especifica el número de procesos para que inician para captar previamente los datos de disco en las páginas de agrupación de almacenamiento intermedio. Para maximizar el paralelismo de lectura, este parámetro se deberá establecer en el número de discos físicos utilizados por la base de datos, para permitir la lectura de cada disco en paralelo.
NUM_IOCLEANERS especifica el número de procesos que se inician para desechar en disco las páginas de agrupación de almacenamiento intermedio sucias. Para maximizar el uso de recursos del sistema, este parámetro se deberá establecer en el número de CPU del sistema.
La frecuencia con la que se desechan en disco las páginas de agrupación de almacenamiento intermedio sucios puede quedar influenciada por el parámetro CHNGPGS_THRESH. El valor representa el límite de suciedad, en forma de porcentaje, que puede tener una página de agrupación de almacenamiento intermedio antes de que se fuerce la acción de desechar en el disco. Para aplicaciones OLTP, se recomienda un valor menor. Para implementaciones de HCL Commerce, el valor se deberá establecer en 40.
Un parámetro final a tener en cuenta es MAXFILOP. Representa el número máximo de archivos que DB2 puede tener abiertos en cualquier momento. Si se establece en un valor demasiado bajo, se ocupan recursos de procesador valiosos para abrir y cerrar archivos. Es necesario supervisar que este parámetro se establezca en el valor correcto, pero como punto de partida es aconsejable establecer este valor en 128. Puede realizar la supervisión tomando una instantánea de base de datos y buscando la línea siguiente:
Database files closed = 0
Si el valor supervisado es mayor que cero, se deberá incrementar el valor para este parámetro.
Parámetros relacionados con el bloqueo
La reducción de la contención de bloqueo es la clave para el rendimiento. Existen varios parámetros que influyen en el comportamiento de bloqueo. La cantidad total de memoria disponible en la base de datos para bloqueos la define el parámetro LOCKLIST. El parámetro MAXLOCKS define la cantidad máxima de memoria disponible para cada conexión a la base de datos. Se representa como porcentaje de LOCKLIST.
El tamaño de ambos parámetros debe ajustarse para evitar escaladas de bloqueo. Una escalada de bloqueo se produce cuando se utiliza toda la memoria disponible para una conexión y se intercambian varios bloqueos de fila en una tabla para un solo bloqueo de tabla. La cantidad de memoria que se utiliza para el primer bloqueo en un objeto es de 72 bytes y cada bloqueo adicional del mismo objeto es de 36 bytes.
Se puede obtener un valor de inicio aproximado adecuado para LOCKLIST suponiendo que una conexión necesita aproximadamente 512 bloqueos en un momento dado. Se puede utilizar la fórmula siguiente:
LOCKLIST = (512 locks/conn * 72 bytes/lock * # of database connections) / 4096 bytes/page
MAXLOCKS se puede establecer en 10 y 20 para empezar. Para ajustar estos dos valores es necesario realizar supervisión adicional. En la salida de instantánea de base de datos, busque las líneas siguientes:
Lock list memory in use (Bytes) = 432 Lock escalations = 0 Exclusive lock escalations = 0
Si se producen escaladas de bloqueo (valor mayor que 0), incremente la locklist para minimizar las escaladas y aumentar el valor de MAXLOCKS, lo que permite incrementar el límite de cantidad de LOCKLIST que una conexión puede utilizar.
Mejores prácticas
A continuación se proporcionan algunas de las mejores prácticas que se utilizan comúnmente para cualquier implementación de IBM DB2 UDB.
Reorganización de datos en espacios de tabla
Cuando se realiza un gran número de inserciones, actualizaciones y supresiones en una tabla de la base de datos, la colocación física de las filas y los índices relacionados puede no ser óptima. DB2 proporciona un programa de utilidad para reorganizar los datos de una tabla:
db2 REORG TABLE <tabschema>.<tabname>;
DB2 también proporciona un programa de utilidad para comprobar si es necesario organizar los datos de una tabla o un índice. Mientras se está conectado a una base de datos, se puede emitir el mandato siguiente:
db2 REORGCHK
Este mandato comprueba todas las tablas de la base de datos y produce un listado, primero por tabla y segundo por índice. En el listado, un asterisco('*') en cualquiera de las tres últimas columnas implica que la tabla o el índice necesita un REORG.
Recopilación de estadísticas
Cada sentencia de SQL que está sometida a la base de datos se analiza y se optimiza y se crea un plan de acceso de sentencia para su ejecución. Para crear este plan de acceso, el optimizador se basa en las estadísticas de tabla e índice. Para que el optimizador genere el mejor plan de acceso, se necesita estadísticas actualizadas. La recopilación frecuente de estadísticas (o como menos cuando cambia una cantidad significativa de datos) es una buena práctica.
Si desea recopilar estadísticas para una tabla, puede emitir el mandato siguiente:
db2 RUNSTATS ON table <tabschema>.<tabname> WITH DISTRIBUTION AND DETAILED INDEXES ALL; Se deben recopilar también estadísticas de las tablas de catálogo.