Las empresas actuales están luchando para poder gestionar la cantidad en aumento de datos XML que generan o consumen. Intel e IBM ejecutaron el primer patrón de bases de datos XML en terabytes de la industria que se basa en un escenario de aplicaciones financieras y que muestra la factibilidad de gestionar grandes volúmenes de datos XML en un hardware rentable.

Matthias Nicola, Senior Software Engineer, IBM Silicon Valley Lab

Author photo: Matthias NicolaMatthias Nicola es un ingeniero sénior de software del Laboratorio de IBM de Silicon Valley en San Jose, CA. Se centra en el rendimiento de DB2 y benchmarking, XML, temporal data management, in-database analytics, y otras tecnologías emergentes. También trabaja en estrecha colaboración con los clientes y socios para ayudarles a diseñar, optimizar, e implementar soluciones DB2. Anteriormente, Matthias trabajó en el rendimiento del depósito de datos en Informix Software. Recibió su Doctorado en ciencias de la computación de la Universidad Técnica de Aachen, Alemania.


Nivel de autor contribuyente en developerWorks

Agustín González, Senior Staff Software Engineer, Intel

Agustín González trabaja en Intel Corp. como ingeniero sénior en software en el Grupo de Software y Soluciones, donde trabaja en la capacitación del rendimiento para las plataformas Intel Xeon. Anteriormente, trabajó en el inicio de varias empresas, donde obtuvo más de 15 años de experiencia en sistemas de gestión de datos a gran escala, en la optimización del rendimiento y en el desarrollo de software comercial.



14-01-2013

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea XML y compresión de datos

No se puede negar que XML surgió como un estándar de facto para el intercambio de datos, las arquitecturas orientadas al servicio (SOA) y el procesamiento de transacciones basadas en los mensajes. Dado que las empresas acumulan grandes cantidades de datos XML, necesitan más que tecnologías de procesamiento de mensajes que gestionen más de un documento XML a la vez. Las empresas empezaron a insistir en grandes volúmenes de documentos XML, a veces debido a los requisitos normativos y a veces por la flexibilidad de los documentos XML o por las dificultades conocidas asociadas con la conversión de los datos XML en un formato relacional y viceversa. Acostumbradas a los beneficios de las bases de datos relacionales maduras, las empresas esperan las mismas capacidades para los datos XML (la habilidad de persistir, consultar, indexar, actualizar y validar los datos XML con una total adhesión a ACID, recuperabilidad, gran disponibilidad y rendimiento).

Algunas veces, XML se considera detallado y un formato de datos lento, especialmente en lo que concierne al procesamiento de grandes cantidades de documentos. A menudo, esta visión de XML se basa en experiencias anteriores con tecnologías insuficientes. Por ejemplo, almacenar muchos documentos XML en un sistema de archivos y escribir el código de la aplicación para analizarlos, deriva fácilmente en un rendimiento insuficiente y en desilusiones. Este escenario ya no coincide con las bases de datos de última generación y con la tecnología del procesador.

Al utilizar las capacidades pureXML de DB2 y los CPU multi core de Intel, Intel e IBM ejecutaron el primer patrón de base de datos XML en terabytes de la industria para demostrar que el procesamiento de transacciones de alto rendimiento por sobre un terabyte de datos XML ya no es una ilusión. Este artículo describe estas pruebas del rendimiento, el hardware utilizado, la configuración de DB2 y los resultados y las lecciones aprendidas. Varias tecnologías DB2 demostraron ser muy importantes, incluida la compresión profunda, el almacenamiento automático, la memoria de ajuste automático y, por supuesto, pureXML. Los resultados cuantificaron la escalabilidad de usuarios múltiples de DB2 con Linux en procesadores Intel de núcleos cuádruples o séxtuples (Procesador Intel Xeon serie 7300 y 7400). Todas las configuraciones del sistema y las pruebas mencionadas en este artículo fueron llevadas a cabo por Intel en sus laboratorios.

DB2 pureXML

DB2 pureXML proporciona soporte para la gestión de datos XML, como el almacenamiento de XML, la indexación de XML, las consultas y actualizaciones de XML y la validación opcional de documentos con esquemas XML. Los usuarios pueden definir las columnas de tipo XML en la que pueden almacenar un documento XML por fila. Las tablas pueden contener una mezcla de XML y columnas relacionales, lo que realiza la integración de XML y de datos relacionales de forma sencilla. Cuando se insertan o cargan los documentos XML en una columna de XML, se analizan y almacenan en un formato de árbol analizado. Esto permite que las consultas y las actualizaciones funcionen en datos XML sin el análisis de XML; lo que representa un beneficio clave para el rendimiento. Los índices XML pueden definirse sobre elementos específicos o atribuirse para garantizar un rendimiento alto de consultas. Las consultas y las actualizaciones se basan en los estándares SQL/XML y XQuery y pueden acceder tanto a XML como a los datos relacionales en una sola declaración, si fuese necesario.


El patrón TPoX

Para probar el gran rendimiento de XML, elegimos ejecutar el patrón TPoX. TPoX (Procesamiento de transacción por sobre XML) es un patrón de base de datos XML de código abierto y a nivel de la aplicación que se basa en un escenario de aplicaciones financieras. Evalúa el rendimiento de los sistemas de bases de datos XML al focalizarse en el almacenamiento y la indexación XQuery, SQL/XML, XML, el soporte del esquema XML, las inserciones, actualizaciones y eliminaciones de XML, el registro, la concurrencia y otros aspectos de las bases de datos. TPoX simula un escenario de operaciones comerciales de seguridad y utiliza un esquema XML real (FIXML) para modelar algunos de sus datos. TPoX está diseñado para ejercer un conjunto de operaciones de XML realistas y representativas.

Las entidades principales de datos lógicos en TPoX son:

  • Cliente: Un solo cliente tiene una o más cuentas
  • Cuenta: Cada cuenta contiene una o varias tenencias
  • Tenencias: Una acción, un bono o un fondo común de inversión
  • Valor: Un solo cliente tiene una o más cuentas
  • Pedido: Cada cliente compra o vende acciones de exactamente un valor para exactamente una cuenta.

Para cada cliente, hay un documento XML que contiene toda la información personal, la información de cuenta y la información de tenencias para ese cliente (Ilustración 1). Cada pedido está representado por un mensaje XML que cumple con el esquema FIXML 4.4. FIXML es un esquema XML estándar industrial complejo para los mensajes relacionados con el comercio, como lo son los pedidos de compra y venta. Cada valor se describe con un solo documento XML. La colección de 20,833 documentos de valores representa la mayoría de las acciones, bonos y fondos comunes de inversión comercializados en los Estados Unidos. Mientras que la cantidad de documentos de valores es fija, el escenario de patrones aumenta en la cantidad de documentos custaac y en documentos de pedidos. La base de datos 1TB TPoX utiliza 300,000.000 pedidos y 60,000.000 documentos custacc.

Ilustración 1. Entidades de datos TPoX.
Figure 1. TPoX data entities.

La carga de trabajo de TPoX consiste en 17 transacciones, enumeradas en la Tabla 1. Su peso relativo en la mezcla de la transacción se muestra en la columna de la derecha. Las operaciones de inserción, actualización y eliminación llegan al 30 por cierto de la carga de trabajo; las consultas al 70 por ciento de la carga de trabajo. La validación del esquema XML se realiza en la transacción I2, U2 y U4.

Tabla 1. Descripciones comerciales de las transacciones TPoX.
Table 1. Business descriptions of TPoX transactions.

La carga de trabajo se ejecuta mediante un controlador de la carga de trabajo que inicia una cantidad configurable de amenazas concurrentes para simular usuarios concurrentes. Cada amenaza se conecta a la base de datos y ejecuta un flujo de transacciones sin tiempo para pensar. Cuando se realiza una transacción, la amenaza que envió la transacción de inmediato toma otra transacción de la Tabla 1 al azar, pero con probabilidades sesgadas según los pesos de la transacción. En el tiempo de uso, el controlador de la carga de trabajo remplaza los marcadores de parámetros en transacciones con valores concretos provenientes de distribuidores aleatorios. El código Java del controlador de la carga de trabajo está disponible como código abierto y puede utilizarse para muchos tipos de pruebas de bases de datos; no solo el patrón TPoX.


El sistema sujeto a evaluación

El sistema de prueba (Ilustración 2) está compuesto por los siguientes componentes de hardware y software:

  • Servidor de base de datos
  • Servidor de Procesador Intel Xeon 7400
  • 64GB de memoria principal
  • Maquina del cliente: Servidor de Procesador Intel Xeon 5400
  • Sistema operativo para el cliente y servidor: Linux SLES 10, 64bit
  • Software de base de datos: DB2 9.5 para Linux, UNIX y Windows, Fixpack 2
  • Software del cliente: Controlador de carga de trabajo de código abierto TPoX, Java 1.5
  • Almacenamiento
  • EMC CX3-80
  • 15 discos por LUN (RAID 0)
  • 120 discos (8 LUN) para la base de datos
  • 15 discos (1 LUN) para el registro
  • 30 discos (2 LUN) para los datos sin procesar
  • 2 tarjetas de controlador RAID (una para cada archivo plano, una para la base de datos y el registro)
  • 2 conexiones del canal de fibra (4 GB/s) por tarjeta del controlador
Ilustración 2. El sistema sujeto a evaluación
Figure 2. System under test.

Procesador Intel Xeon serie 7400 y 7300

Para analizar cómo aumenta el rendimiento de DB2 con una cantidad de núcleos por CPU en aumento, ejecutamos un patrón dos veces con procesadores diferentes. El primer conjunto de pruebas utilizadas para los CPU Intel Xeon serie 7400, que tienen seis núcleos cada uno. Luego, repetimos el patrón al utilizar cuatro CPU Intel Xeon 7300 con cuatro núcleos cada uno. La comparación de los CPU en la Tabla 2 muestra que no solo se diferencian en el número de núcleos. Mientras que el Procesador Intel Xeon serie 7400 tiene un 50 por ciento más de núcleos que el serie 7300, su velocidad reloj es 10 por ciento más lenta, pero tiene un caché de 16MB L3, que el Intel Xeon serie 7300 no tiene.

Tabla 2. Procesadores Intel Xeon utilizados en este patrón
Table 2. Intel Xeon processors used in this benchmark.

Cuando conmutamos los CPU, todos los demás datos del hardware y del software permanecieron idénticos. El procesador Xeon serie 7400 y el serie 7300 utilizan el mismo conjunto de chips, entonces remplazar uno con otro es simplemente un remplazo "sustitutivo" del procesador sin necesidad de otros cambios.


Configuración y puesta a punto de DB2

La base de datos de DB2 se creó con la función de almacenamiento automático de DB2 y el tamaño de página de 16KB al utilizar ocho volúmenes lógicos más un volumen separado para el registro. El esquema de base de datos que elegimos implementar en el escenario TPoX es muy simple. Consiste de tres columnas XML en tres tablas, una para cada uno de los tres tipos de documentos XML en TPoX (pedido, custacc y valor):

crear una tabla de custacc (cadoc xml en longitud de uso de enlaces en línea de 16288) en el índice custacc_tbs en custacc_idx_tbs compresión positiva;

crear una tabla de pedido (odoc xml en longitud de uso de enlaces en línea de 16288) en el índice orders_tbs en orders_idx_tbs compresión positiva;

crear una tabla de valor (sdoc xml en longitud de uso de enlaces en línea de 16288) en el índice secutiry_tbs en security_idx_tbs compresión positiva;

El uso de enlaces en línea XML y la compresión se utilizaron para reducir la huella de almacenamiento para el 1TB de datos XML no procesados. Creamos cinco espacios de tabla (un espacio de tabla para cada una de las tres tablas más un espacio de tabla para los índices custacc y uno para los índices de pedidos). Todos los espacios de tablas se configuraron con SIN ALMACENAMIENTO EN CACHÉ DEL SISTEMA DE ARCHIVOS y el ALMACENAMIENTO AUTOMÁTICO. Cada espacio de tabla tenía su propia agrupación de almacenamiento intermedio para el espacio de tabla temporario. Utilizamos los espacios de tablas diferentes y las agrupaciones de almacenamiento intermedio principalmente para la facilidad de supervisión. Más tarde, confirmamos que combinar todas las tablas y todos los índices en un solo espacio de tabla y una gran agrupación de almacenamiento intermedio produjo casi el mismo rendimiento (sólo un rendimiento más bajo en un 6 por ciento que la configuración manual).

Para la configuración de los tamaños de las agrupaciones de almacenamiento intermedio, almacenamiento dinámico de ordenación, caché de paquetes, num_iocleaners, num_ioservers y demás, tomamos el enfoque siguiente. Para evitar las iteraciones de ajuste repetitivas y extensas, simplemente cuestionamos los valores razonables para todos esos parámetros. Los números que elegimos no están destinados o se conocen como óptimos para esta carga de trabajo. Solo estaban destinados a ser un punto de comienzo para el comportamiento de auto ajuste del DB2. Por ejemplo, sabíamos que necesitábamos grandes agrupaciones de almacenamiento intermedio para custacc y las tablas de pedidos, pero desconocíamos qué tamaños serían los indicados. Decidimos dejar al gerente de la memoria de auto ajuste de DB2 (STMM) que descubra el tamaño indicado. Para ayudar a que el STMM converja rápidamente hacia los tamaños indicados de la agrupación de almacenamiento intermedio, no quisimos comenzar con la omisión de 1000 páginas, que sabíamos que era demasiado pequeño. Por ejemplo, en primer lugar, establecimos una agrupación de almacenamiento intermedio para la tabla custacc en 770.000 páginas y, luego, en automático, entonces se necesitarían menos ajustes de STMM iterativos para alcanzar el tamaño indicado que si hubiésemos comenzado con 1.000 páginas. Los parámetros INSTANCE_MEMORY y DATABASE_MEMORY también se establecieron en automático.

  • Puede ver nuestro guión DDL completo en el repositorio de código abierto de TPoX aquí.
  • Resultados de rendimiento

Ahora, revisemos los siguientes tipos de resultados:

  • Consumo de almacenamiento y compresión
  • Rendimiento de transacción de la carga de trabajo mixta (70 por ciento de consultas, 30 por ciento de inserciones/actualizaciones/eliminaciones)
  • Proporción de hits de agrupación de almacenamiento intermedio
  • Rendimiento listo para usar con una mínima configuración manual o ajuste
  • Escalabilidad desde CPU de 4 a 6 núcleos
  • Rendimiento de inserción en aumento

Resultados del consumo de almacenamiento y compresión

Dado que la tabla de valores es muy pequeña (20.833 documentos), investigamos el consumo de espacio y la proporción de compresión principalmente para las dos grandes tablas, custacc y pedidos (ver Tabla 3). Los 60 millones de documentos custacc se comprimen en un 64 por ciento y requieren 121,4GB en un espacio de tabla de DB2. Los 300 millones de documentos de pedidos se comprimen en un 57 por ciento y ocupan 269,2GB en DB2. Incluyendo todos los datos y los índices, el tamaño final de la base de datos era de aproximadamente 440GB. El uso de enlaces en línea XML y la compresión eran críticos para evitar los cuellos de botella de E/S.

Tabla 3. Consumo de espacio y compresión
Table 3. Space consumption and compression.

Rendimiento de transacción de una carga de trabajo mixta

La Figura 3 muestra el resultado del rendimiento de la transacción para la carga de trabajo mixta en la plataforma Intel Xeon 7400 de 2.66Ghz con 24 núcleos. El eje horizontal muestra el número diferente de usuarios concurrentes que simuló el controlador de cargas de trabajo de TPoX. Cada usuario emite un flujo de transacciones sin un tiempo de pensamiento entre las transacciones. La curva azul representa las transacciones por segundo y pertenece al eje vertical en la izquierda. La curva rosa representa la utilización del CPU y pertenece al eje vertical en la derecha. El rendimiento y la utilización del CPU crecen a medida que aumenta el número de usuarios concurrentes. Cuando el número usuarios aumenta de 100 a 150 y 200, la utilización del CPU alcanza la capacidad máxima del sistema y, como consecuencia, el rendimiento cae. En 200 usuarios el rendimiento máximo es de 6763 transacciones de TPoX por segundo.

Ilustración 3. Transacciones por segundo y utilización del CPU.
Figure 3 . Transactions per seconds and CPU utilization.

El aumento de la cantidad de usuarios superior a 200 no derivó en un rendimiento más alto, solo a tiempos de respuestas de transacciones más extensos. La curva de aplanamiento del rendimiento y el agotamiento de la capacidad del sistema en 200 usuarios se relaciona directamente con el hecho de que todos los usuarios simulados realizan transacciones sin el tiempo de pensamiento entre una transacción y la siguiente. Si cada usuario realizó, por ejemplo, una transacción por segundo, entonces el sistema podría soportar miles de usuarios.

La Ilustración 4 muestra el resultado del controlador de la carga de trabajo para la carga de trabajo mixta con 200 usuarios y una duración de la prueba de 2 horas. Las estadísticas detalladas para todas las 17 transacciones en la carga de trabajo mixta incluye sus tiempos de respuesta máximos y promedio así como también su "conteo", que el número de veces que se ejecutó cada transacción en todos los 200 usuarios. Se ejecutaron 48,5 millones de transacciones en una prueba de dos horas. Todos los tiempos de respuesta promedio son inferiores a 0,1 segundos. Dado que el controlador de la carga de trabajo se ejecutó en una maquina individual de un cliente, los tiempos de respuesta incluyeron el tiempo del viaje de ida y vuelta.

Ilustración 4. Resultados de transacciones detallados en 200 usuarios
Figure 4. Detailed transaction results at 200 users.

De forma opcional, el controlador de la carga de trabajo puede imprimir un resumen de la transacción cada diez minutos durante el periodo de prueba. Esto nos permitió confirmar que el rendimiento es estable todo el tiempo. El controlador de la carga de trabajo también puede calcular el percentil 90.º, 95.º o 99.º según los tiempos de respuesta de la transacción. Los percentiles son útiles si desea confirmar que el 90 por ciento, el 95 por ciento y el 99 por ciento de los tiempos de respuesta de transacción se encuentran por debajo de un umbral determinado.

Recuerde que el controlador de la carga de trabajo se encuentra libremente disponible como código abierto y puede utilizarse para ejecutar cualquier tipo de carga de trabajo SQL, SQL/XML o XQuery que defina. Es una herramienta muy versátil para todos los tipos de pruebas de rendimiento de la base de datos.


Rendimiento de la agrupación del almacenamiento intermedio bajo "Gestión de Memoria de Ajuste Automático"

El tamaño combinado de todas las agrupaciones de almacenamiento intermedio, ajustadas por el gestor de la memoria de ajuste automático de DB2, alcanzaron 46 GB (de una memoria física de 64 GB) Dado que el tamaño de la base de datos después de la compresión era de aproximadamente 440GB, la proporción entre las agrupaciones del almacenamiento intermedio y el tamaño de la base de datos es del 10,5 por ciento (46GB/440GB). La Ilustración 5 muestra que las agrupaciones de almacenamiento intermedio para custacc y los índices de pedidos tienen proporciones de hits entre 95 y 100 por ciento. La proporción de hits para custacc y las tablas de pedidos era de entre un 60 por ciento y un 70 por ciento. Sin la compresión DB2, esta proporción del hit sería inferior y el rendimiento sería peor.

Ilustración 5. Proporción de hits de agrupación de almacenamiento intermedio
Figure 5. Buffer pool hit ratios.

Rendimiento de DB2 listo para usar

¿Cuán difícil es afinar el DB2 para el rendimiento que alcanzamos en la prueba? Por ejemplo: ¿Es realmente necesario tener cinco espacios de tabla separados y agrupaciones de almacenamiento intermedio para las diferentes tablas e índices? ¿Podemos alcanzar un rendimiento similar con una configuración de base de datos que es más simple que el guión que usamos inicialmente?

En un intento por responder a estas preguntas, remplazamos el patrón y configuramos la base de datos de DB2 con sólo cuatro simples pasos:

  • Crear una base de datos con almacenamiento automático
  • Cambiar la ubicación del registro para una vía de almacenamiento individual
  • Crear una agrupación de almacenamiento intermedio individual para el espacio temporario en la tabla
  • Utilizar un comando AUTOCONFIGURE de DB2 para permitir que DB2 se afine solo.

Estos pasos se muestran en la Ilustración 6. Tenga en cuenta que las bases de datos utilizan solo un espacio de tabla predeterminado y una agrupación de almacenamiento intermedio predeterminada para todas las tablas y los índices. Con esta configuración, la carga de trabajo mixta con 200 usuarios alcanzó 6368 transacciones por segundo, lo que es un 6 por ciento menos que los 6763 TPS que alcanzamos con la configuración de una base de datos más detallada. Este resultado muestra que el rendimiento de alta calidad no siempre requiere el afinamiento de la base de datos de expertos y que las capacidades autonómicas de DB2 funcionan relativamente bien.

Ilustración 6. Configuración de la base de datos en cinco comandos
Figure 6. Configuring the database in five commands..

Escalabilidad en CPU de núcleos múltiples

La Ilustración 7 compara el rendimiento medido en tres casos diferentes Desde la izquierda a la derecha son

  • 150 usuarios concurrentes, cuatro CPU Intel Xeon 7300 (16 núcleos en total, 2,93 GHz)
  • 150 usuarios concurrentes, cuatro CPU Intel Xeon 7400 (24 núcleos en total, 2,66 GHz)
  • 200 usuarios concurrentes, cuatro CPU Intel Xeon 7400 (24 núcleos en total, 2,66 GHz)

En la primera prueba, los CPU de núcleo cuádruple Intel Xeon 7300 están saturados con los 150 usuarios concurrentes. La carga de trabajo alcanza un rendimiento máximo de 45558 transacciones por segundo en una utilización del CPU de 99,3. En la prueba 2, al cambiar de CPU con cuatro núcleos (Xeon 7300) a seis núcleos (Xeon 7400) aumenta la velocidad de la transacción para 150 usuarios en un 42 por ciento en solo 84,7 por ciento de la utilización del CPU. Dado que la máquina no está saturada, la prueba 3 aumenta la cantidad de usuarios a 200. Esto deriva en un 95,2 por ciento del uso del CPU y 6763 transacciones por segundo, una ganancia de rendimiento del 48 por ciento de los seis núcleos por sobre los procesadores de cuatro núcleos.

La ganancia en rendimiento de 1,42x y de 1,48x en la Ilustración 7 es notable porque al considerar solo la cantidad de núcleos y la velocidad del reloj, se espera que los CPU Intel Xeon 7400 proporcionen 1,36x más de rendimiento que los CPU Intel Xeon 7300. El aumento adicional de la velocidad se debe principalmente al caché L3 de 16MB que es nuevo en los procesadores Intel Xeon serie 7400. La misma importancia tiene el hecho de que los CPU Intel Xeon 7400 proporcionan un rendimiento más elevado y mantienen el mismo consumo de potencia que los CPU Intel Xeon 7300. El rendimiento en aumento por watt es importante para que la informática sea más económica y rentable.

Ilustración 7. Escalabilidad desde los CPU Intel de cuatro núcleos a seis núcleos
Figure 7. Scalability from Intel quad-core to six-core CPUs.

Rendimiento de inserción de XML

La inserción de filas en una tabla en blanco con índices vacíos puede ser más rápido que insertarlas en una tabla que ya contiene grandes volúmenes de datos. Para obtener una evaluación significativa del rendimiento de inserción de XML, medimos un carga de trabajo de solo inserción en además de la base de datos 1TB ocupada. La prueba de inserción agregó 2 millones de documentos XML a la tabla de custacc y 3 millones de documentos a la tabla de pedidos (ver Ilustración 8). Ambas tablas tienen dos índices XML No se realizó la validación del esquema XML Los documentos custacc se insertaron a una velocidad de 4.900 documentos por segundo, lo que equivale a ~100GB/hora. Los documentos de pedidos más pequeños se insertaron a 11.900 documentos por segundo y a 69 GB/hora. Para ambos tipos de documentos, las pruebas de inserción utilizaron 600 usuarios concurrentes que emitieron declaraciones de inserción sin tiempo de pensamiento. Se realizó una confirmación después de cada inserción. Confirmaciones menos frecuente so la utilización del servicio de carga de DB2 puede proporcionar incluso velocidades de ingestión de XML más altas.

Ilustración 8. Rendimiento de inserción de XML en aumento
Figure 8. Incremental XML insert performance.

Lecciones aprendidas

¿Qué aprendimos del estudio del rendimiento de XML de 1TB? Además del rendimiento real y los resultados de escalabilidad, se valoran varias observaciones.

Una de las lecciones aprendidas consiste en que la afinación de DB2 para el procesamiento de la transacción basada en XML no es demasiado dura. La estrategia para utilizar las funciones de afinamiento automáticas y autonómicas de DB2, en la medida de lo posible, demostró ser muy exitosa. Dentro de una cantidad de tiempo razonable, no pudimos alcanzar un rendimiento más alto con la afinación manual que con la automática.

Un pre requisito para un buen rendimiento es el hardware bien equilibrado, es decir, la utilización de la proporción "correcta" entre el número de CPU, la memoria principal y la cantidad de discos. Con 24 núcleos, 64GB de memoria y 120 discos de datos nuestro sistema de prueba tiene 5 discos por núcleo y 2,66GB de memoria por núcleo. La proporción indicada depende de la carga de trabajo. En la carga de trabajo mixta de TPoX observamos un promedio de 1,7 solicitudes físicas de E/S por transacción. Por lo tanto, en una velocidad pico de transacción de 6763 TPS, el sistema de almacenamiento tenía que sostener aproximadamente 11.500 operaciones de E/S por segundo (IOPS). Al seguir la regla general que indica que el disco SCSI moderno puede soportar aproximadamente 100 IOPS con latencias relativamente bajas, se necesitan cerca de 115 discos para evitar los cuellos de botella de E/S y permitir la buena utilización del CPU.

La compresión del DB2 era importante. Sin compresión, más discos y más memoria se requerirían para alcanzar el mismo rendimiento. La compresión redujo la E/S requerida, que es un beneficio que sobrepasó los ciclos extra del CPU para comprimir y descomprimir los datos.

Para entender el comportamiento de rendimiento de la base de datos, es muy útil utilizar un monitor para la captura de pantallas de DB2 en intervalos regulares, por ejemplo cada 5 minutos. Por ejemplo, los datos recopilados le permiten analizar la E/S y el comportamiento de limpieza de la página con el paso del tiempo.

Para los sistemas Linux y UNIX, DB2 9.5 tiene un modelo de proceso fundamentalmente diferente que el DB2 9.1. Mientras que el DB2 9.1 inicia un proceso individual para cada agente, el DB2 9.5 se ejecuta como un proceso individual con una amenaza por agente. Nuestros resultados confirman que el motor amenazado del DB2 explota muy bien los CPU de núcleos múltiples y alcanza un buen aumento en la velocidad desde procesadores Intel Xeon de 4 núcleos a 6 núcleos.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=854795
ArticleTitle=Cómo dominar un terabyte de datos XML
publish-date=01142013