Hola comunidad,

Quería compartir mi experiencia trabajando en proyectos con grandes volúmenes de datos. A lo largo de los años, he tenido la oportunidad de manejar enormes cantidades de datos de pacientes, datos de aseguradoras y registros transaccionales mientras trabajaba en la industria hospitalaria. He tenido la oportunidad de crear informes muy extensos que requerían usar lógicas avanzadas para obtener datos de múltiples tablas, cuyos índices no me ayudaban a escribir un código eficiente.

Esto es lo que he aprendido sobre cómo gestionar grandes volúmenes de datos de manera eficiente.

Elegir el método de acceso a datos adecuado

Como todos sabemos en esta comunidad, IRIS ofrece múltiples formas de acceder a los datos. Elegir el método correcto dependerá de lo que necesitemos.

• Acceso directo a los Globales: el más rápido para operaciones masivas de lectura/escritura. Por ejemplo, si tengo que recorrer índices y obtener datos de pacientes, puedo iterar sobre los globales para procesar millones de registros. Esto ahorra mucho tiempo.

Set ToDate=+HSet FromDate=+$H-1ForSet FromDate=$O(^PatientD("Date",FromDate)) Quit:FromDate>ToDate  Do
. Set PatId=""ForSet PatId=$Order(^PatientD("Date",FromDate,PatID)) Quit:PatId=""Do
. . Write$Get(^PatientD("Date",FromDate,PatID)),!

• Uso de SQL: útil para requisitos de generación de informes o análisis, aunque más lento para conjuntos de datos muy grandes.

Algo que he aprendido a lo largo de los años es que, por muy pulida que esté vuestra lógica de aplicación, el rendimiento de la base de datos acabará haciendo o deshaciendo la experiencia de usuario. Trabajando con InterSystems IRIS, recientemente me topé con esto de primera mano. Un cliente nuestro estaba construyendo un panel de informes que funcionaba a la perfección en las pruebas, pero cuando el conjunto de datos de producción creció hasta millones de registros, los tiempos de respuesta se arrastraban.

InterSystems ha estado a la vanguardia de la tecnología de bases de datos desde su creación, siendo pionera en innovaciones que superan constantemente a competidores como Oracle, IBM y Microsoft. Al centrarse en un diseño eficiente del núcleo y adoptar un enfoque sin concesiones en el rendimiento de los datos, InterSystems se ha hecho un hueco en las aplicaciones de misión crítica, garantizando fiabilidad, velocidad y escalabilidad.

Una historia de excelencia técnica

Desde la introducción de Embedded Python siempre ha estado la duda sobre su rendimiento respecto a ObjectScript y en más de una ocasión lo he comentado con @Guillaume Rongier , pues bien, aprovechando que estaba haciendo una pequeña aplicación para capturar los datos de los concursos públicos en España y poder realizar búsquedas utilizando las capacidades de VectorSearch he visto la oportunidad de realizar una pequeña prueba.

Datos para la prueba

Motivación

Empecé a programar en 2015, cuando estaba haciendo la carrera de informática. No conocía ObjectScript hasta que empecé en mi nuevo trabajo hace cuatro meses. ObjectScript en realidad no es un lenguaje de programación joven. Comparado con C++, Java y Python, la comunidad no es tan activa, pero queremos hacer que este espacio sea más dinámico, ¿verdad?  

Me he dado cuenta de que a algunos de mis compañeros les cuesta entender las relaciones entre clases en estos proyectos tan enormes. No hay ninguna herramienta moderna y fácil de usar para crear diagramas de clases en ObjectScript.

Si eres administrador de sistemas y/o de base de datos y trabajas con InterSystems IRIS, este curso te puede ayudar a mantener tus instancias bien configuradas y con rendimiento óptimo. 

Con el curso de Fundamentos de Administración aprenderás la información esencial y necesaria para configurar la plataforma de datos de InterSystems, realizar tareas de mantenimiento como copias de seguridad, monitorización, resolución de problemas y control de acceso de usuario.

En nuestro portal de formaciónpuedes consultar todos los cursos oficiales programados. 

El auge de los proyectos de Big Data, las analíticas en tiempo real con herramientas self-service, los servicios de consultas en línea y las redes sociales, entre otros, han habilitado escenarios para consultas masivas y de alto rendimiento. En respuesta a este desafío, se creó la tecnología MPP (procesamiento masivamente paralelo) y rápidamente se consolidó. Entre las opciones de MPP de código abierto, Presto (https://prestodb.io/) es la más conocida. Surgió en Facebook y se utilizó para análisis de datos, pero luego se convirtió en código abierto. Sin embargo, desde que Teradata se unió a la

Recientemente hemos puesto a disposición una nueva versión de InterSystems IRIS en el Programa de Acceso Anticipado a Vector Search (o búsqueda vectorial), que utiliza el índice ANN (Aproximate Nearest Network) basado en el algoritmo de indexación Hierarchical Navigable Small World (HNSW). Esta incorporación permite realizar búsquedas aproximadas de vecinos-más-cercanos (nearest-neighbours) de manera mucho más eficiente, sobre grandes conjuntos de datos vectoriales, mejorando drásticamente el rendimiento de las consultas y la escalabilidad.

InterSystems IRIS 2024 ha introducido recientemente los tipos de vectores. Esta adición os permite trabajar con búsquedas por vectores, habilitando búsquedas eficientes de similitud, agrupación y una amplia gama de otras aplicaciones. En este artículo, profundizaremos en las complejidades de los tipos de vectores, exploraremos sus aplicaciones y os proporcionaremos ejemplos prácticos para guiar vuestra implementación.

En su esencia, un tipo de vector es una colección estructurada de valores numéricos dispuestos en un orden predefinido. Estos valores sirven para representar diferentes atributos, características o rasgos de un objeto.

SQL-Embedding: Una Herramienta Versátil

Para simplificar la creación y el uso de embeddings para búsquedas por vectores dentro de las consultas SQL, hemos introducido la herramienta SQL-Embedding. Esta función os permite aprovechar una amplia gama de modelos de embedding directamente dentro de vuestras bases de datos SQL, adaptados a vuestras necesidades específicas.

Ejemplo Práctico: Búsqueda de Similitud

Consideremos un escenario donde queréis determinar la similitud entre dos textos utilizando el modelo fastembed y SQL-Embedding. La siguiente consulta SQL muestra cómo se puede lograr esto:

SELECT
 VECTOR_DOT_PRODUCT(
 embFastEmbedModel1,
 dc.embedding('my text', 'fastembed/BAAI/bge-small-en-v1.5')
 ) AS "Similarity between 'my text' and itself",
 VECTOR_DOT_PRODUCT(
 embFastEmbedModel1,
 dc.embedding('lorem ipsum', 'fastembed/BAAI/bge-small-en-v1.5')
 ) AS "Similarity between 'my text' and 'lorem ipsum'"
FROM testvector;

Almacenamiento en caché

Uno de los beneficios significativos de usar SQL-Embedding en InterSystems IRIS es su capacidad para almacenar en caché las solicitudes de embedding repetidas. Este mecanismo de caché mejora considerablemente el rendimiento al reducir la sobrecarga computacional asociada con la generación de embeddings para entradas idénticas o similares.

Cómo Funciona la Caché

Cuando ejecutáis una consulta SQL-Embedding, InterSystems IRIS comprueba si el embedding para la entrada dada ya ha sido almacenado en caché. Si existe, el embedding en caché se recupera y se utiliza directamente, eliminando la necesidad de volver a generarlo. Esto es particularmente ventajoso en escenarios donde los mismos embeddings se solicitan con frecuencia, como en sistemas de recomendación o aplicaciones de búsqueda.

Beneficios de la caché

• Reducción de la Latencia: Al evitar cálculos redundantes de embeddings, la caché puede reducir significativamente los tiempos de respuesta de las consultas.
• Mejora de la Escalabilidad: La caché puede gestionar cargas de trabajo incrementadas de manera más eficiente, ya que reduce la presión sobre los modelos de embedding subyacentes.
• Optimización del Uso de Recursos: La caché ayuda a conservar recursos computacionales al evitar cálculos innecesarios.

En conclusión, la introducción de los tipos de vectores en InterSystems IRIS presenta una herramienta robusta para trabajar con representaciones numéricas de objetos. Al aprovechar las búsquedas de similitud, SQL-Embedding y diversas aplicaciones, los desarrolladores pueden desbloquear nuevas posibilidades y mejorar sus soluciones basadas en datos.

Si encontrasteis nuestra aplicación interesante y os ha aportado algún conocimiento, votad por sql-embeddings y ayudadnos en este viaje.

Entonces, si estáis siguiendo desde la publicación anterior o si os incorporáis ahora, pasemos al mundo de las aplicaciones eBPF y echemos un vistazo a Parca. Este se basa en nuestra breve investigación sobre cuellos de botella en el rendimiento utilizando eBPF, pero añade una aplicación revolucionaria sobre vuestro clúster para monitorizar todas vuestras cargas de trabajo de IRIS de forma continua, ¡a nivel de todo el clúster!

Perfilado continuo con Parca, cargas de trabajo IRIS en todo el clúster

Asistí a la Cloud Native Security Con en Seattle con la plena intención de aprovechar el día de OTEL, para luego profundizar en el tema de la seguridad aplicada a las cargas de trabajo nativas en la nube en los días siguientes, culminando con el CTF como ejercicio profesional. Esto fue felizmente interrumpido por un nuevo entendimiento de eBPF, lo cual supuso una mejora muy necesaria para mis pantallas, carrera, cargas de trabajo y actitud, gracias a nuevos enfoques para resolver problemas relacionados con las cargas de trabajo.

Así que llegué a la "fiesta" de eBPF y desde entonces he estado asistiendo a clínica tras clínica sobre el tema. Aquí me gustaría "desempaquetar" eBPF como una solución técnica, mapeada directamente a lo que hacemos en la práctica (aunque no siempre coincida del todo), y recorrer eBPF a través de mis experimentos en el soporte de las cargas de trabajo de InterSystems IRIS, particularmente en Kubernetes, pero sin excluir las cargas de trabajo independientes.

Pasos de eBee con eBPF y Cargas de Trabajo de InterSystems IRIS

Hacía mucho tiempo que no escribía un post de actualización en IoP (Interoperabilidad en Python).

¿Qué hay de nuevo desde el lanzamiento de la interfaz de línea de comandos de IoP?

Dos nuevas grandes características se han añadido a IoP:

• Rebranding: el módulo grongier.pex fue renombrado a iop para reflejar el nuevo nombre del proyecto.
• Soporte asíncrono**: IoP ahora soporta funciones asíncronas y corrutinas.

Rebranding

El módulo grongier.pex ha sido renombrado a iop para reflejar el nuevo nombre del proyecto.

El módulo grongier.pex sigue disponible para compatibilidad con versiones anteriores, pero se eliminará en el futuro.

Soporte Async

IoP soporta llamadas asíncronas desde hace mucho tiempo, pero no era posible utilizar funciones asíncronas y corrutinas directamente en IoP.

Antes de saltar a esta nueva característica, voy a explicar cómo funcionan las llamadas async en InterSystems IRIS y presentar dos ejemplos de cómo utilizar las llamadas async IoP.

Llamadas asíncronas heredadas

Veamos cómo funcionan las llamadas async legacy:

from iop import BusinessProcess
from msg import MyMessage


class MyBP(BusinessProcess):

    def on_message(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        self.send_request_async("Python.MyBO", msg_one,completion_key="1")
        self.send_request_async("Python.MyBO", msg_two,completion_key="2")

    def on_response(self, request, response, call_request, call_response, completion_key):
        if completion_key == "1":
            self.response_one = call_response
        elif completion_key == "2":
            self.response_two = call_response

    def on_complete(self, request, response):
        self.log_info(f"Received response one: {self.response_one.message}")
        self.log_info(f"Received response two: {self.response_two.message}")

Básicamente funcionan de la misma manera que las llamadas asíncronas en IRIS. El método send_request_async envía una petición a una Operación de Negocio y el método on_response es llamado cuando se recibe la respuesta.

Podéis distinguir las respuestas por el parámetro completion_key.

Enviar múltiples peticiones de sincronización

No es exactamente una nueva característica, pero vale la pena mencionar que se pueden enviar múltiples solicitudes de sincronización en paralelo:

from iop import BusinessProcess
from msg import MyMessage


class MyMultiBP(BusinessProcess):

    def on_message(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        tuple_responses = self.send_multi_request_sync([("Python.MyMultiBO", msg_one),
                                                        ("Python.MyMultiBO", msg_two)])

        self.log_info("All requests have been processed")
        for target,request,response,status in tuple_responses:
            self.log_info(f"Received response: {response.message}")

Aquí estamos enviando dos peticiones a la misma Operación de Negocio en paralelo.

La respuesta es una tupla con el objetivo, la petición, la respuesta y el estado de cada llamada.

Es realmente útil cuando necesitáis enviar múltiples peticiones y no te importa el orden de las respuestas.

Funciones asíncronas y corrutinas

Ahora vamos a ver cómo utilizar funciones asíncronas y corrutinas en IoP:

import asyncio

from iop import BusinessProcess
from msg import MyMessage


class MyAsyncNGBP(BusinessProcess):

    def on_message(self, request):

        results = asyncio.run(self.await_response(request))

        for result in results:
            print(f"Received response: {result.message}")

    async def await_response(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        # use asyncio.gather to send multiple requests asynchronously
        # using the send_request_async_ng method
        tasks = [self.send_request_async_ng("Python.MyAsyncNGBO", msg_one),
                 self.send_request_async_ng("Python.MyAsyncNGBO", msg_two)]

        return await asyncio.gather(*tasks)

En este ejemplo, estamos enviando múltiples peticiones a la misma Operación de Negocio en paralelo usando el método send_request_async_ng.

Si habéis leído atentamente este post hasta este punto, comentad «Boomerang». Esto puede ser un simple detalle para vosotros, pero para mi significa mucho. Gracias.

El método await_response es una corrutina que envía múltiples peticiones y espera a recibir todas las respuestas. Gracias a la función asyncio.gather, podemos esperar a que se reciban todas las respuestas en paralelo.

Las ventajas de utilizar funciones asíncronas y corrutinas son:

• Mejor rendimiento: podéis enviar múltiples peticiones en paralelo.
• Más fácil de leer y mantener: podéis usar la palabra clave await para esperar las respuestas.
• Más flexibilidad: podéis utilizar el módulo asyncio para crear flujos de trabajo complejos.
• Más control: podéis utilizar el módulo asyncio para manejar excepciones y tiempos de espera.

Conclusión

¿Cuáles son las diferencias entre send_request_async, send_multi_request_sync y send_request_async_ng?

• send_request_async: envía una petición a una Operación de Negocio y espera la respuesta **si** se implementa el método on_responsey se utiliza el parámetrocompletion_key`.
  • ventaja: podéis utilizar las llamadas async de la forma habitual.
  • desventaja: puede ser difícil de mantener si necesitáis enviar múltiples peticiones en paralelo.
• send_multi_request_sync`: envía múltiples peticiones a la misma Operación de Negocio en paralelo y espera a que se reciban todas las respuestas.
  • ventaja: es fácil de usar.
  • desventaja: se puede controlar el orden de las respuestas (es decir, la lista de respuestas no está ordenada).
• send_request_async_ng`: envía múltiples peticiones a la misma Operación de Negocio en paralelo y espera a que se reciban todas las respuestas.
  • ventaja: se puede controlar el orden de las respuestas.
  • desventaja: es necesario utilizar funciones asíncronas y coroutines.

¡Feliz multithreading!

Un cliente preguntó recientemente si IRIS soporta OpenTelemetry, dado que estaban buscando medir el tiempo que los servicios SOAP implementados por IRIS tardan en completarse, y  el cliente ya tenía varias otras tecnologías que soportan OpenTelemetry para el seguimiento de procesos.

Parece que fue ayer cuando hicimos un pequeño proyecto en Java para probar el rendimiento de IRIS, PostgreSQL y MySQL (podéis revisar el artículo que escribimos allá por Junio al final de este artículo). Si recordáis IRIS se mostró superior a PostgreSQL y claramente superior a MySQL en las inserciones, no habiendo gran diferencia en las consultas.

Poco después @Dmitry Maslennikov me dijo "¿Por qué no pruebas desde un proyecto en Python?" pues bien, aquí está la versión en Python de las pruebas que realizamos mediante las conexiones JDBC previamente.

Continuando con la serie de análisis de rendimiento, en este artículo voy a mostrar un método para dimensionar los requisitos de memoria compartida para aplicaciones de base de datos que se ejecutan en plataformas de datos de InterSystems, incluyendo los Global y Routine Buffers, gmheap y locksize. También daré algunos consejos de rendimiento que se deberían tener en cuenta al configurar servidores y al virtualizar aplicaciones de Iris. Como siempre, cuando hablo de Iris o Caché , me refiero a toda la plataforma de datos. Este artículo tiene algunos años pero mantiene su esencia, por lo que me referiré a Iris o Caché indistintamente ya que la teoría es exáctamente igual para todos los productos con kernel Caché/Iris. 

YASPE es el sucesor de YAPE (Yet Another pButtons Extractor). YASPE ha sido escrito desde cero con muchos cambios internos para facilitar el mantenimiento y añadir mejoras.

Funcionalidades de YASPE:

• Analizar y representar gráficamente los archivos de InterSystems Caché pButtons e InterSystems IRIS SystemPerformance para un rápido análisis de rendimiento de las métricas de IRIS y del Sistema Operativo.
• Facilitar un análisis profundo, creando gráficos tanto ad-hoc como combinando métricas de IRIS y del Sistema Operativo con la opción "Pretty Performance".
• La opción "System Overview" te ahorra tener que buscar en los archivos SystemPerformance detalles del sistema u opciones de configuración comunes.

YASPE está escrito en Python y está disponible en GitHub como código fuente o para contenedores Docker en:

• https://github.com/murrayo/yaspe

YASPE está más centrado en las versiones y Sistema Operativo actuales de IRIS. Si tienes versiones más antiguas y tienes problemas con YASPE, comprueba si puedes ejecutar correctamente tus archivos de rendimiento con YAPE. Si tienes problemas, no dudes en preguntarme a través de GitHub.

Ejemplos

Archivos de salida

Las opciones incluyen:

• Gráficos en HTML o PNG para todas las columnas en mgstat y vmstat o windows perfmon y salida a carpetas.
• Es opcional crear gráficos para iostat ya que puede llevar mucho tiempo si hay una lista de discos grande.
• Un fichero CSV para posterior procesado manual, por ejemplo, con Excel.

Pretty Performance

Debajo está el gráfico de ejemplo, Glorefs (mgstat) y Uso Total de CPU (vmstat).

Esta es una de las imágenes predeterminadas, que incluye un zoom para un momento específico (o por defecto de 13:00-14:00).

Descripción del sistema

yaspe incluye una descripción del sistema y una comprobación básica de la configuración (-s)

Esta comprobación está diseñada para evitar estar rebuscando en el archivo SystemPerformance para encontrar los detalles del sistema. Este es un ejemplo deoverview.txt:

System Summary for your site name

Hostname         : YOURHOST
Instance         : SHADOW
Operating system : Linux
Platform         : N/A
CPUs             : 24
Processor model  : Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz
Memory           : 126 GB
Shared memory    : globals 71680 MB + routines 1023 MB + gmheap 1000 MB = 73,703 MB
Version          : Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2018.1.4 (Build 505_1U) Thu May 28 2020 10:11:16 EDT
Date collected   : Profile run "24hours" started at 16:15:00 on Nov 22 2021.

Warnings:
- Journal freeze on error is not enabled. If journal IO errors occur database activity that occurs during this period cannot be restored.
- swappiness is 10. For databases 5 is recommended to adjust how aggressive the Linux kernel swaps memory pages to disk.
- Hugepages not set. For performance, memory efficiency and to protect the shared memory from paging out, use huge page memory space. It is not advisable to specify HugePages much higher than the shared memory amount because the unused memory are not be available to other components.
- dirty_background_ratio is 10. InterSystems recommends setting this parameter to 5. This setting is the maximum percentage of active memory that can be filled with dirty pages before pdflush begins to write them.
- dirty_ratio is 30. InterSystems recommends setting this parameter to 10. This setting is the maximum percentage of total memory that can be filled with dirty pages before processes are forced to write dirty buffers themselves during their time slice instead of being allowed to do more writes. These changes force the Linux pdflush daemon to write out dirty pages more often rather than queue large amounts of updates that can potentially flood the storage with a large burst of updates

Recommendations:
- Review and fix warnings above
- Set HugePages, see IRIS documentation: https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCI_prepare_install#GCI_memory_big_linux
- Total memory is 128,755 MB, 75% of total memory is 96,566 MB.
- Shared memory (globals+routines+gmheap) is 73,703 MB. (57% of total memory).
- Number of HugePages for 2048 KB page size for (73,703 MB + 5% buffer = 77,388 MB) is 38694

All instances on this host:
- >SHADOW            2018.1.4.505.1.a  56772  /cachesys

¡Hola desarrolladores! Quería compartir hoy un ejemplo muy interesante por parte de Tani Frankel. Se trata de una aplicación sencilla sobre la utilidad SystemPerfomance.

Repasando nuestra documentación sobre la rutina de monitorización ^SystemPerformance (conocida como ^pButtons en versiones anteriores a IRIS), un cliente me dijo «Entiendo todo esto pero ojalá fuese más simple, más sencillo para definir perfiles y gestionarlos, etc.».

Entonces pensé que sería interesante como ejercicio facilitar una pequeña interfaz para hacer esas tareas más sencillas.

El primer paso era envolver en una API basada en clases la rutina actual de ^SystemPerformance.

Hace varios años, estaba enseñando los conocimientos básicos de nuestro framework %UnitTest durante la clase de Fundamentos de Caché (ahora llamada Developing Using InterSystems Objects and SQL). Un alumno preguntó si era posible recoger estadísticas de rendimiento mientras se ejecutan pruebas unitarias. Unas semanas más tarde, añadí un código adicional a los ejemplos de %UnitTest para responder a esa pregunta. Ahora lo comparto con la Comunidad.

Al igual que los servidores hardware, los servidores virtuales en nubes públicas y privadas pueden generar cuellos de botella en los recursos, según aumentan las cargas de trabajo. Si utilizas y administras instancias de InterSystems IRIS implementadas en nubes públicas o privadas, es posible que te hayas encontrado la situación en la que para solucionar problemas de rendimiento o de otro tipo se requiere aumentar la capacidad del servidor de una instancia (es decir, escalar verticalmente).

Un motivo frecuente es la memoria insuficiente. Como se describe en la Administración de la memoria y escalamiento de InterSystems IRIS que se encuentra en la Guía de escalabilidad, proporcionar suficiente memoria para todas las estructuras que se ejecutan en el servidor de una instancia de InterSystems IRIS en todas las circunstancias normales de funcionamiento, es un factor crítico tanto para el rendimiento como para la disponibilidad. En un escenario común, conforme aumenta la carga de trabajo en una instancia de InterSystems IRIS, su conjunto de trabajo se vuelve demasiado grande para ser contenido por la memoria caché reservada para las estructuras de la base de datos. Esto lo obliga a que algunas consultas tengan que ir a disco, lo que aumenta significativamente el número de lecturas requeridas del disco y crea un problema importante de rendimiento. Aumentar el tamaño de esta memoria caché resuelve ese problema, pero si al hacerlo no queda suficiente memoria para otros propósitos, también habrá que aumentar la memoria física total del servidor para evitar que el cuello de botella se desplace hacia otra parte del sistema.

Afortunadamente, escalar un servidor virtual generalmente es mucho más sencillo que escalar uno hardware. En esta publicación se analizan las dos etapas del proceso:

• Cómo escalar los recursos del servidor virtual 

Se puede cambiar la especificación de recursos de un servidor virtual en AWS, GCP y Azure, utilizando la línea de comandos, la API o el portal de la plataforma. VMWare vSphere permite modificar fácilmente varios parámetros de los recursos para una máquina virtual mediante su interfaz de cliente vSphere.

• Cómo reconfigurar InterSystems IRIS para aprovechar los recursos escalados

Hay varias maneras de reconfigurar InterSystems IRIS para aprovechar los recursos del servidor escalado. Este documento describe el uso de la función Combinar la configuración, que combina nuevos valores de los parámetros, especificados en un archivo combinado, en el CPF de una instancia. Combinar la configuración es un método sencillo y eficaz porque permite ocuparse únicamente de la configuración que se quiere modificar, hacer varios cambios en la configuración de una instancia con una sola operación y realizar fácilmente el mismo conjunto de cambios en varias instancias.

Los procedimientos descritos aquí son manuales, pero en producción muy probablemente serían automatizados, por ejemplo usando un script que aplicaría un archivo combinado específico en una ubicación accesible para una lista de instancias.

Cómo escalar los recursos del host virtual

Las plataformas publicas en la nube ofrecen una variedad de plantillas de recursos para elegir, que especifican el CPU, la memoria, las interfaces de red y otros recursos para hosts virtuales (el almacenamiento se suministra y se dimensiona por separado). Para cambiar el tamaño de un servidor, hay que cambiar la plantilla seleccionada cuando se creó el host a una permita especificar los recursos que necesitas aumentar. En Amazon Web Services, la plantilla de recursos se denomina un tipo de instancia, por ejemplo, el tipo de instancia t3.large especifica 2 CPUs y 8 GB de memoria. En la plataforma Google Cloud es un tipo de máquina, como la e2-standard-2 (que también incluye 2 CPUs y 8 GB), y en Microsoft Azure es un tamaño (el Standard_B2ms requiere igualmente 2 CPUs y 8 GB). Al redefinir el tipo de instancia, tipo de máquina o tamaño del servidor de una nube pública existente, se pueden escalar las especificaciones de sus recursos. En una nube privada de VMware vSphere, se puede utilizar la interfaz de cliente vSphere en la consola de administración vCenter Server para modificar directamente una o más configuraciones de los recursos individuales de una máquina virtual existente. (También se pueden escalar simultáneamente grupos de servidores en cada plataforma).

En las siguientes secciones se ofrecen breves ejemplos sobre cómo redimensionar servidores virtuales individuales en distintas plataformas, con enlaces a la documentación para todos los métodos disponibles. Ten en cuenta que estos métodos (API, interfaces de línea de comandos e interfaces del portal) se proporcionan y mantienen gracias a los proveedores en la nube, y los ejemplos que aquí se incluyen son con propósitos informativos, para ilustrar con qué facilidad se puede adaptar InterSystems IRIS para aprovechar el aumento en los recursos. 

AWS

Para modificar el tipo de instancia de un servidor AWS (denominada instance, no debe confundirse con una instancia de InterSystems IRIS) se puede utilizar el comando CLI modify-instance-attribute, como se muestra en el siguiente ejemplo:

$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-0abcdef1234567890,
            "InstanceId": "i-1234567890abcdef0,
            "InstanceType": "m5n.large",
            ...
$ aws ec2 stop-instances --instance-ids i-01519f663af48a55e
{
    "StoppingInstances": [
        {
            "InstanceId": "i-1234567890abcdef0",
            ...
$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            ...
            "State": {
            "Code": 80, 
            "Name": "stopped"
            }
            ...
$ aws ec2 modify-instance-attribute --instance-ids i-01519f663af48a55e \
      --instance-type "{\"Value\": \"m5n.xlarge\"}"
$ aws ec2 start-instances --instance-ids i-01519f663af48a55e
{
    "StartingInstances": [
        {
            "InstanceId": "i-1234567890abcdef0",
            "CurrentState": {
                "Code": 0,
                "Name": "pending"
            },
            "PreviousState": {
                "Code": 80,
                "Name": "stopped"
            ...
$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-0abcdef1234567890,
            "InstanceId": "i-1234567890abcdef0,
            "InstanceType": "m5n.xlarge",
            ...

También se puede hacer este cambio mediante la llamada a la API de AWS ModifyInstanceAttribute o con la consola AWS EC2. 

GCP

Para modificar el tipo de máquina de un servidor GCP (también conocida como una instance), se puede usar el comando gcloud CLI para detener, modificar y reiniciar la instancia. Por ejemplo, se podrían usar los siguientes comandos para modificar el tipo de máquina de una instancia llamada scalingTest por n1-highmem-96:

$ gcloud compute instances stop scalingTest
$ gcloud compute instances set-machine-type scalingTest --machine-type n1-highmem-32
$ gcloud compute instances start scalingTest

También se puede hacer este cambio usando la Google Cloud Console o la API de la GCP.

Azure

Cuando se utiliza Azure CLI para modificar el tamaño de una máquina virtual con Linux, se puede ver una lista de los tamaños disponibles en el clúster de hardware donde se aloja la máquina virtual usando el comando list-vm-resize-options, por ejemplo:

az vm list-vm-resize-options --resource-group testingGroup --name scalingTest --output table

Se puede utilizar el comando resize para cambiar el tamaño de la máquina virtual a una de las opciones en la lista, como se muestra en el ejemplo. Este comando reinicia la máquina virtual automáticamente.

az vm resize --resource-group testingGroup --name scalingTest --size Standard_E32d_v4

Si el tamaño al que quieres cambiar la máquina virtual no está disponible, puede anular la asignación de la máquina virtual, que puede ser redimensionada a cualquier tamaño que esté soportado por la región y reiniciarse. Los comandos relacionados se muestran a continuación:

az vm deallocate --resource-group testingGroup --name scalingTest
az vm resize --resource-group testingGroup --name scalingTest --size Standard_M128s
az vm start --resource-group testingGroup --name scalingTest

Se puede cambiar el tamaño de una máquina virtual de Windows en Azure utilizando el portal de Azure o los comandos de Powershell.

vSphere

Para cambiar el tamaño de una máquina virtual de VMware vSphere, hay que hacer lo siguiente:

1. Abrir el cliente vSphere o el cliente web y mostrar el inventario de la máquina virtual.
2. Haga clic con el botón derecho en la máquina virtual que quieres modificar y seleccionar Edit Settings.
3. En la etiqueta Virtual Hardware
   • Expande Memory y cambia la cantidad de RAM configurada para la máquina virtual.
   • Expande CPU y cambia el número de núcleos y, de manera opcional, el número de núcleos por socket.
   • Realiza cualquier otro cambio que quieras en los recursos de hardware asignados a la máquina virtual.

Cómo reconfigurar InterSystems IRIS para aprovechar los recursos escalados

Cuando hayas escalado el servidor, el siguiente paso es reconfigurar InterSystems IRIS para aprovechar el aumento de recursos cambiando uno o más parámetros en el archivo de parámetros de configuración de la instancia (CPF). Por ejemplo, para continuar con el escenario mencionado al principio de esta publicación, ahora que has aumentado los recursos de memoria del servidor, querrás aprovecharte de esto aumentando el tamaño de la caché de la base de datos de la instancia de InterSystems IRIS (que se realiza cambiando el valor del parámetro globals) para que pueda mantener más datos en la memoria.

Una manera sencilla de realizar este tipo de cambios, y con mucho la forma más fácil y repetible para realizar varios cambios en la configuración de una instancia en una sola operación o de realizar los mismos cambios en varias instancias, es utilizar la función Combinar la configuración, que está disponible en los sistemas UNIX® y Linux. Como se describe en Cómo usar la función Combinar la configuración para implementar instancias personalizadas de InterSystems IRIS en Cómo ejecutar productos de InterSystems en contenedores y en Cómo usar la función Combinar la configuración en la Referencia del Archivo de Configuración de Parámetros, la función Combinar la configuración permite especificar un archivo de combinación que contenga la configuración que quieres combinar en el CPF de una instancia, inmediatamente antes de un reinicio.  (En la versión 2021.1 podrás hacer esto en una instancia que está en ejecución sin reiniciarla). Esto no solo es más conveniente que editar directamente el CPF de una instancia, sino que es altamente repetible en varias instancias, y es compatible con una gestión de cambios confiables, ya que permite mantener un historial preciso de los cambios simplemente adaptando la configuración de los archivos combinados a los que los aplique.

Para realizar la función Combinar la configuración, hay que hacer lo siguiente:

1. Crear el archivo combinado con los parámetros que quieres modificar.
2. Colocar el archivo combinado en una ubicación accesible a la instancia. Si la instancia que estás modificando se encuentra en un contenedor (el cual es probable que esté en un host de la nube), puedes preparar el archivo en el directorio %SYS duradero de la instancia (consulta %SYS duradero para datos persistentes de la instancia en Cómo ejecutar productos de InterSystems en contenedores).
3. Especifique la ubicación del archivo combinado utilizando la variable de entorno ISC_CPF_MERGE_FILE antes de reiniciar la instancia.

Por ejemplo, siguiendo con el caso de la caché de la base de datos que necesita una actualización, supongamos que queremos aumentar a 100 GB el tamaño de la caché de la base de datos de una instancia en un contenedor. La configuración, en la sección [config] del CPF, sería globals=102400, que establece la caché de la base de datos para bloques de 8 kilobytes en 102,400 MB, o 100 GB. (Como se explica en la descripción de los globals en la Referencia del Archivo de Configuración de Parámetros, el parámetro establece el tamaño de la caché para varios tamaños de bloque; sin embargo, si solo se proporciona un valor, se aplica al tamaño de bloque de 8 kilobytes, y se asume **** [zero] para los otros tamaños; globals=102400 es, por lo tanto, el equivalente a globals=0,0,102400,0,0,0).

Para realizar este cambio, se puede realizar lo siguiente en el host de la nube:

1. Crear una configuración en el archivo combinado, denominado por ejemplo mergefile2021.06.30.cpf, que contenga estas líneas:

[config]
globals=102400

2. Colocar el archivo combinado en el directorio %SYS duradero que se encuentra en el sistema de archivos del host, el cual si se instaló el volumen externo /data como /external en el contenedor y se usó la variable ISC_DATA_DIRECTORY para especificar /external/iris_durable como el directorio %SYS duradero para la instancia, sería /data/iris_durable.

3. Utilizar el comando docker exec en la línea de comandos del host para especificar la variable y reiniciar la instancia con el comando iris si el contenedor de la instancia se llama iris y la instancia se llama IRIS, por ejemplo, el comando tendrá el siguiente aspecto:

docker exec iris ISC_CPF_MERGE_FILE=/data/iris_durable/mergefile2021.06.30.cpf 
iris stop IRIS restart

4. Cuando la instancia se reinicie, se podrá confirmar la nueva configuración de globals con este comando:

docker exec iris grep globals /data/iris_durable/iris.cpf

Me gustaría compartir algunas funciones de almacenamiento que también existen en Caché y que son prácticamente desconocidas y en su mayoría no se utilizan. Por supuesto, están disponibles en IRIS y son más relevantes con arquitecturas de almacenamiento extensas y distribuidas.

Aunque la integridad de las bases de datos Caché e InterSystems IRIS está completamente protegida de las consecuencias de un fallo de sistema, los dispositivos de almacenamiento físico sí que pueden fallar, corrompiendo los datos que almacenan.

Por esa razón, muchos sitios optan por realizar chequeos o verificaciones periódicas de integridad de bases de datos, sobre todo en coordinación con las copias de seguridad, para validar que se pueda confiar en una determinada copia de seguridad en caso de que ocurra algún desastre. El chequeo de integridad también puede ser muy necesario para el administrador del sistema, como respuesta a un desastre que implique la corrupción del almacenamiento. El chequeo de integridad ha de leer todos los bloques de los globals que están en el proceso de verificación (si actualmente no están en los buffers), y en el orden dictado por la estructura del global. Esto lleva mucho tiempo, pero el chequeo de integridad es capaz de leer tan rápido como el subsistema de almacenamiento pueda soportar.  En algunas situaciones, es aconsejable ejecutarlo de esta manera para obtener resultados lo más rápido posible. En otras situaciones, el chequeo de integridad debe ser más conservador para evitar consumir demasiado ancho de banda del subsistema de almacenamiento. 

Plan de Ataque

El siguiente esquema se adapta a la mayoría de las situaciones. El análisis detallado del resto de este artículo proporciona la información necesaria para actuar sobre cualquiera de ellos, o para derivar otras líneas de acción. 

1. Si utilizas Linux y el chequeo de integridad es lento, consulta la información que encontrarás más abajo sobre la activación de la E/S asíncrona. 
2. Si el chequeo de integridad debe completarse lo más rápido posible (ejecutándose en un entorno aislado, o porque los resultados se necesitan urgentemente), utiliza el chequeo de Integridad Multiproceso para comprobar varios globals o bases de datos en paralelo. El número de procesos multiplicado por el número de lecturas asíncronas simultáneas que cada proceso realizará (8 de forma predeterminada, o 1 si se utiliza Linux con la E/S asíncrona deshabilitada) es el límite del número de lecturas simultáneas sostenidas. Considera que el promedio puede ser la mitad de eso y después compara con las características del subsistema de almacenamiento.  Por ejemplo, con el almacenamiento dividido en 20 unidades y las 8 lecturas simultáneas predeterminadas por proceso, pueden ser necesarios cinco o más procesos para capturar toda la capacidad del subsistema de almacenamiento (5*8/2=20).
3. Al equilibrar la velocidad del chequeo de integridad contra su impacto en producción, primero ajusta el número de procesos en el chequeo de integridad multiproceso; después, si es necesario, consulta el ajuste SetAsyncReadBuffers. Consulta el chequeo de Integridad de Aislamiento indicado más abajo para obtener una solución a largo plazo (y para eliminar falsos positivos).
4. Si ya está limitado a un solo proceso (por ejemplo, hay un global extremadamente grande u otras restricciones externas) y la velocidad de el chequeo de integridad necesita un ajuste hacia arriba o hacia abajo, consulta más abajo el ajuste SetAsyncReadBuffers.

Chequeo de Integridad Multiproceso

La solución general para obtener un chequeo de integridad que se complete más rápido (usando recursos del sistema a un mayor ritmo) es dividir el trabajo entre varios procesos paralelos. Algunas de las interfaces de usuario y APIs de chequeo de integridad lo hacen, mientras que otras utilizan un solo proceso. La asignación a los procesos es una por global, por lo que el chequeo de un único global siempre se realiza mediante un solo proceso (las versiones anteriores a Caché 2018.1 dividían el trabajo por base de datos en vez de por global).

La API principal para verificar la integridad de varios procesos es CheckLIst Integrity (consulta la documentación para más detalles). Recopila los resultados en un global temporal para ser mostrados por Display^Integrity. El siguiente es un ejemplo de verificación de tres bases de datos usando cinco procesos. Si se omite el parámetro de la lista de bases de datos, se verifican todas las bases de datos.

set dblist=$listbuild(“/data/db1/”,”/data/db2/”,”/data/db3/”)
set sc=$$CheckList^Integrity(,dblist,,,5)
do Display^Integrity()
kill ^IRIS.TempIntegrityOutput(+$job)

/* Note: evaluating ‘sc’ above isn’t needed just to display the results, but...
   $system.Status.IsOK(sc) - ran successfully and found no errors
   $system.Status.GetErrorCodes(sc)=$$$ERRORCODE($$$IntegrityCheckErrors) // 267
                           - ran successfully, but found errors.
   Else - a problem may have prevented some portion from running, ‘sc’ may have 
          multiple error codes, one of which may be $$$IntegrityCheckErrors. */

El uso de CheckLIst^Integrity de esta manera es la forma más sencilla de lograr el nivel de control que nos interesa. Tanto la interfaz del Portal de administración como la Tarea de Chequeo de Integridad (incorporada, pero no programada) utilizan varios procesos, pero puede que no ofrezca un control suficiente para nuestros propósitos.*

Otras interfaces de chequeo de integridad, especialmente la interfaz de usuario del terminal, ^INTEGRIT o ^Integrity, así como Silent^Integrity, realizan el chequeo de integridad en un solo proceso. Por lo tanto, estas interfaces no completan el chequeo tan rápido como es posible conseguir, y utilizan menos recursos. Sin embargo, una ventaja es que sus resultados son visibles, se registran en un archivo o se envían al terminal, según se verifica cada global, y en un orden bien definido.

E/S asíncronas

Un proceso de chequeo de integridad recorre cada bloque puntero de un global, uno cada vez, validando cada uno contra el contenido de los bloques de datos a los que apunta. Los bloques de datos se leen con E/S asíncrona para mantener un número de solicitudes de lectura sostenidos para que el subsistema de almacenamiento las procese, y la validación se va completando cada lectura. 

En Linux, la E/S asíncrona solo es efectiva en combinación con la E/S directa, que no está habilitada de forma predeterminada hasta InterSystems IRIS 2020.3. Esto explica un gran número de casos en los que el chequeo de la integridad tarda demasiado tiempo en Linux. Afortunadamente, se puede habilitar en Cache 2018.1, IRIS 2019.1 y posteriores, al establecer wduseasyncio=1 en la sección [config] del archivo .cpf y reiniciando. Este parámetro se recomienda en general para la escalabilidad de E/S en sistemas con mucha carga y es el predeterminado en plataformas que no son de Linux desde Caché 2015.2. Antes de habilitarlo, asegúrate de que has configurado suficiente memoria de caché de base de datos (global buffers) porque con Direct E/S, las bases de datos ya no serán almacenadas en la caché (de forma redundante) por Linux. Si no se activan, las lecturas realizadas por el chequeo de integridad se completan de forma sincróna y no se puede utilizar el almacenamiento de forma eficiente. 

En todas las plataformas, el número de lecturas que un proceso de chequeo activa esta fijado en 8 por defecto. Si tienes que alterar la velocidad a la que un solo proceso de chequeo lee del disco, este parámetro se puede ajustar: hacia arriba para conseguir que un solo proceso se complete más rápido o hacia abajo para utilizar menos ancho de banda de almacenamiento. Ten en cuenta que:

• Este parámetro se aplica a cada proceso de chequeo de integridad. Cuando se utilizan varios procesos, el número de procesos multiplica este número de lecturas sostenidas. Cambiar el número de procesos de chequeo de integridad paralelos tiene un impacto mucho mayor y, por tanto, normalmente es lo primero que se hace. Cada proceso también está limitado por el tiempo computacional (entre otras cosas), por lo que aumentar el valor de este parámetro tiene un beneficio limitado.
• Esto solo funciona dentro de la capacidad del subsistema de almacenamiento para procesar lecturas simultáneas. Valores más altos no tienen ningún beneficio si las bases de datos se almacenan en una sola unidad local, mientras que una matriz de almacenamiento con striping a lo largo de docenas de unidades, puede procesar docenas de lecturas de forma simultánea.

Para ajustar este parámetro desde el namespace %SYS, do SetAsyncReadBuffers^Integrity(value). Para ver el valor actual, write $$GetAsyncReadBuffers^Integrity(). El cambio tiene efecto cuando se verifica el siguiente global. La configuración no persiste tras un reinicio del sistema, aunque se puede añadir a SYSTEM^%ZSTART.

Hay un parámetro similar para controlar el tamaño máximo de cada lectura cuando los bloques son contiguos (o cercanos) en el disco. Este parámetro se necesita con menos frecuencia, aunque los sistemas con alta latencia de almacenamiento o bases de datos con tamaños de bloque más grandes podrían beneficiarse de un ajuste más fino. El valor tiene unidades de 64KB, por lo que un valor de 1 es 64KB, 4 es 256KB, etc. 0 (el valor predeterminado) permite que el sistema seleccione automáticamente,y, actualmente selecciona 1 (64KB). La función ^Integrity para este parámetro, paralela a las mencionadas anteriormente, son SetAsyncReadBufferSize y GetAsyncReadBufferSize.

Aislamiento del Chequeo de integridad

Muchos sitios realizan chequeos periódicos de integridad directamente en el sistema de producción. Esto es lo más sencillo de configurar, pero no es lo ideal. Además de las preocupaciones sobre el impacto de el chequeo de integridad en el ancho de banda de almacenamiento, la actualización simultánea de la base de datos a veces puede conducir a errores de falsos positivos (a pesar de las mitigaciones incorporadas en el algoritmo de verificación). Como resultado, los errores reportados por una chequeo de integridad ejecutado en producción deben ser evaluados y/o verificados de nuevo por un administrador.

Con frecuencia, existe una mejor opción. Un snapshot del almacenamiento o una imagen de la copia de seguridad se pueden montar en otro servidor, donde una instancia aislada de Caché o IRIS ejecuta el chequeo de integridad. Esto no solo evita cualquier posibilidad de falsos positivos, sino que si el almacenamiento también se aísla de la producción, el chequeo de integridad se puede ejecutar para utilizar completamente el ancho de banda del almacenamiento y completarse mucho más rápido. Este enfoque encaja bien en el modelo donde el chequeo de integridad se utiliza para validar copias de seguridad; una copia de seguridad validada ratifica de forma efectiva la producción, desde el momento en que se hizo la copia de seguridad. Las plataformas en la nube y de virtualización también pueden facilitar el establecimiento de un entorno aislado utilizable a partir de un snapshot.

*La interfaz del Portal de Gestión, la tarea de Chequeo de integridad y el método IntegrityCheck de SYS.Database, seleccionan un número bastante grande de procesos (igual al número de núcleos de la CPU), sin que exista un control que puede ser necesario en muchas situaciones. El Portal de Gestión y la tarea también hacen un doble chequeo de cualquier global que haya informado de un error, en un intento por identificar falsos positivos, que pueden ser debidos a actualizaciones simultáneas. Este nuevo chequeo va más allá de la mitigación de falsos positivos incorporada en los algoritmos de verificación de integridad, y puede ser molesta en algunas situaciones, debido al tiempo adicional que requiere (el nuevo chequeo se ejecuta en un solo proceso y verifica todo el global). Este comportamiento se podrá modificar en el futuro.

Siguiendo la serie de artículos de mi compañero Murray vamos a centrarnos en el artículo donde analizamos la CPU.

Un cliente me pidió que le aconsejara sobre el siguiente escenario: sus servidores de producción se están acercando al final de su vida útil y es el momento de actualizar el hardware. También están pensando en consolidar los servidores por medio de la virtualización y quieren ajustar la capacidad, ya sea con servidores de hardware dedicado o virtualizados.

Hoy analizaremos la CPU. En artículos posteriores explicaré el enfoque para dimensionar correctamente otros "grupos alimenticios de hardware": la memoria y las Entradas/Salidas.

Entonces las preguntas son:

• ¿Cómo se traducen los requisitos de un procesador de hace más de cinco años a los procesadores actuales?
• De los procesadores actuales, ¿cuáles son adecuados?
• ¿Cómo afecta la virtualización a la planificación de la capacidad de la CPU?

Añadido en junio de 2017: Para profundizar en los aspectos específicos de las consideraciones y la planificación de la CPU en VMware y para conocer algunas preguntas y problemas comunes, puedes consultar esta publicación: Virtualización de grandes bases de datos: Planificación de la capacidad de la CPU en VMware

Cómo comparar el rendimiento de la CPU usando los análisis de rendimiento (benchmarks) spec.org

Para traducir el uso de la CPU entre los distintos tipos de procesadores para aplicaciones desarrolladas con las plataformas de datos de InterSystems (Caché, Ensemble, HealthShare), puedes usar los análisis de rendimiento de SPECint como un cálculo aproximado para escalar entre procesadores. La página web http://www.spec.org ofrece resultados fiables de un conjunto de análisis de rendimiento estandarizados, ejecutados por proveedores de hardware.

Específicamente, SPECint es una forma de comparar distintos modelos de procesadores de los mismos proveedores y de diferentes proveedores (por ejemplo: Dell, HP, Lenovo e Intel, AMD, IBM POWER y SPARC). Puedes utilizar SPECint para entender los requisitos esperados de la CPU para tu aplicación cuando se vaya a actualizar el hardware o si tu aplicación se implementará en varios hardwares de distintos clientes y necesitas establecer una línea de base para una métrica de tamaño, por ejemplo, máximo número de transacciones por núcleo de la CPU para Intel Xeon E5-2680 (o cualquier procesador que elijas).

En el sitio web de SPECint se utilizan varios análisis de rendimiento, pero los resultados de SPECint_rate_base2006 son los mejores para Caché, ya que se han confirmado a lo largo de muchos años analizando datos de clientes y en nuestros propios análisis de rendimiento.

Como ejemplo, en este artículo vamos a comparar la diferencia entre el servidor Dell PowerEdge de los clientes con procesadores Xeon 5570, y un servidor Dell actual con procesadores Intel Xeon E5-2680 V3. La misma metodología se puede aplicar con los procesadores de servidor Intel Xeon V4 disponibles de forma generalizada.

Ejemplo: Comparando procesadores

Busca SPECint2006_Rates en la base de datos de spec.org, por nombre del procesador, por ejemplo E5-2680 V3. Puedes afinar aún más los resultados de tu búsqueda si conoces la marca y el modelo de tu servidor objetivo (por ejemplo, Dell R730); si no, utiliza un proveedor popular. En mi experiencia, creo que los modelos de Dell o HP son buenas bases de referencia de servidores estándar, generalmente no hay gran variación entre los procesadores de diferentes proveedores de hardware.

Al final de esta publicación mostraré un ejemplo paso a paso de cómo buscar resultados con el sitio web spec.org

Supongamos que buscaste en spec.org y encontraste el servidor actual y un posible servidor nuevo, así:

Actual: Dell PowerEdge R710 con Xeon 5570, 2.93 GHz: 8 núcleos, 2 chips, 4 núcleos/chips, 2 hilos/núcleos: SPECint_rate_base2006 = 251

Nuevo: PowerEdge R730 con Intel Xeon E5-2680 v3, 2.50 GHz: 24 núcleos, 2 chips, 12 núcleos/chips, 2 hilos/núcleos: SPECint_rate_base2006 = 1030

No sorprende que el nuevo servidor de 24 núcleos aumente más de 4 veces el rendimiento del análisis de rendimiento SPECint_rate_base2006 con respecto al servidor anterior de 8 núcleos, a pesar de que el servidor nuevo tiene una menor velocidad del reloj. Ten en cuenta que los ejemplos son servidores de dos procesadores que tienen ambas ranuras del procesador ocupadas.

¿Por qué se utiliza SPECint_rate_base2006 para Caché?

El sitio web spec.org tiene explicaciones de las distintos análisis de rendimiento, pero el resumen es que el análisis de rendimiento SPECint_rate2006 es un punto de referencia completo a nivel de sistema que utiliza todos los CPU con HyperThreading.

Para un análisis de rendimiento SPECint_rate2006 en particular, se reportan dos métricas: base y pico. Base es un análisis de rendimiento conservador, mientras que Pico es agresivo. Para planificar la capacidad, utiliza los resultados de SPECint_rate_base2006..

¿Un SPECint_rate_base2006 cuatro veces mayor significa una capacidad cuatro veces mayor para usuarios o transacciones?

Posiblemente si se utilizaran los 24 núcleos, el rendimiento de la aplicación pudiera escalar a cuatro veces la capacidad del servidor anterior. Sin embargo, hay varios factores que pueden hacer que los resultados sean distintos. SPECint te permitirá conocer el tamaño y el rendimiento que debería ser posible, pero hay algunas advertencias.

Aunque SPECint ofrece una buena comparación entre los dos servidores del ejemplo anterior, no garantiza que el servidor E5-2680 V3 tenga un 75% más de capacidad para los picos de usuarios concurrentes o para el pico de rendimiento de las transacciones que el servidor anterior basado en Xeon 5570. Hay que tener en cuenta otros factores, como el hecho de que los demás componentes de hardware de nuestros "grupos alimenticios de hardware" estén actualizados, por ejemplo, si el almacenamiento nuevo o el actual es capaz de dar servicio al aumento del rendimiento (pronto publicaré un análisis profundo sobre el almacenamiento).

Basado en mi experiencia analizando el rendimiento de Caché y observando los datos de rendimiento de los clientes, Caché es capaz de escalar linealmente a tasas de rendimiento extremadamente altas en un solo servidor a medida que se añaden recursos informáticos (núcleos de la CPU). Esto es aún más cierto con las mejoras que Caché recibe año tras año. Dicho de otro modo, veo un escalado lineal del rendimiento máximo de la aplicación, por ejemplo de las transacciones de la aplicación o reflejado en las glorefs (referencias globales) de Caché conforme se añaden núcleos en la CPU. Sin embargo, si hay cuellos de botella en las aplicaciones, pueden empezar a aparecer con tasas de transacción más altas y repercutir en el escalado lineal. En artículos posteriores explicaré dónde se pueden buscar síntomas de cuellos de botella en las aplicaciones. Una de las mejores medidas que se pueden tomar para mejorar la capacidad de rendimiento de las aplicaciones es actualizar Caché a la última versión.

Nota: Para Caché, los servidores Windows 2008 con más de 64 núcleos lógicos no son compatibles. Por ejemplo, un servidor de 40 núcleos debe tener desactivado el Hyper Threading. Para Windows 2012 se admiten hasta 640 procesadores lógicos. No hay límites en Linux.

¿Cuántos núcleos necesita la aplicación?

Las aplicaciones varían y cada uno conoce el perfil de sus propias aplicaciones, pero el enfoque común que utilizo cuando planifico la capacidad de la CPU para un servidor (o máquina virtual) es a partir de la monitorización cuidadosa del sistema, comprender que un cierto número de núcleos de CPU de un determinado procesador "estándar" puede sostener una tasa de transacción máxima de n transacciones por minuto. Estas podrían ser episodios, o encuentros, o pruebas de laboratorio o lo que sea. El punto es que el rendimiento del procesador estándar se basa en las métricas que ha recogido en tu sistema actual o un sistema de clientes.

Si conoces el pico de uso de recursos actual de la CPU en un procesador conocido con n núcleos, se puede traducir al número de núcleos necesarios en un procesador más nuevo o diferente para la misma tasa de transacciones utilizando los resultados de SPECint. Con un escalado lineal esperado, 2 x n transacciones por minuto se traduce aproximadamente en 2 x el número de núcleos necesarios.

Cómo elegir un procesador

Como se puede ver en spec.org o analizando la oferta de tu proveedor, hay muchas opciones de procesadores. El cliente de este ejemplo está contento con Intel, por lo que me limitaré a recomendarle servidores Intel actuales. Una forma de proceder es buscar la mejor relación coste-beneficio, o la mejor relación SPECint_rate_base2006 por dólar y por núcleo. Por ejemplo, el siguiente gráfico muestra los servidores básicos de Dell - tu precio variará, pero esto ilustra que hay puntos más favorables en el precio y recuentos de núcleo más altos adecuados para la consolidación de los servidores utilizando la virtualización. Creé el gráfico fijando el precio de un servidor de producción de calidad, por ejemplo, el Dell R730, y luego examinando distintas opciones de procesadores.

Según los datos del gráfico y la experiencia en sitios de los clientes, el procesador E5-2680 V3 presenta un buen rendimiento a un precio adecuado por SPECint, o por núcleo.

También entran en juego otros factores, por ejemplo, si estás buscando procesadores de servidor para la implementación virtualizada, puede ser más barato aumentar el número de núcleos por procesador, lo que tiene un coste mayor pero logra reducir el número total de servidores necesarios para soportar todas tus máquinas virtuales. De esta forma ahorrarás en software (p. ej. VMware o sistemas operativos) que cobran licencias por ranura de procesador. También tendrás que equilibrar el número de servidores con los requisitos de alta disponibilidad (HA). En artículos posteriores volveré a hablar de VMware y HA.

Por ejemplo, un clúster de VMware HA formado por tres servidores host de 24 núcleos proporciona una buena disponibilidad y una potencia de procesamiento significativa (por número de núcleos), permitiendo configuraciones flexibles de máquinas virtuales de producción y de no producción. Recuerda que VMware HA tiene un tamaño de N+1 servidores, por lo que tres servidores de 24 núcleos equivalen a un total de 48 núcleos disponibles para tus máquinas virtuales.

Núcleos vs GHz: ¿Qué es lo mejor para Caché?

Si tienes que elegir entre núcleos de CPU más rápidos o más núcleos de CPU, debes considerar lo siguiente:

• Si tu aplicación requiere muchos hilos/procesos de cache.exe, un mayor número de núcleos permitirá que más de ellos se ejecuten exactamente al mismo tiempo.
• Si tu aplicación tiene menos procesos, desearás que cada uno se ejecute lo más rápido posible.

Otra forma de ver esto es pensar que si tienes una aplicación de tipo cliente/servidor con muchos procesos, por ejemplo, uno o más por usuario simultáneo, querrás tener más núcleos disponibles. Para aplicaciones basadas en el navegador que utilizan CSP, en las que los usuarios se agrupan en menos procesos de servidor CSP muy ocupados, tu aplicación se beneficiaría de tener un número potencialmente menor de núcleos, pero más rápidos.

En un mundo ideal, ambos tipos de aplicaciones se beneficiarían de contar con muchos núcleos rápidos, asumiendo que no hay contención de recursos cuando varios procesos cache.exe se ejecutan simultáneamente en todos esos núcleos. Como señalé anteriormente, pero merece la pena repetirlo, cada versión de Caché presenta mejoras en el uso de los recursos de la CPU, por lo que actualizar las aplicaciones a las últimas versiones de Caché puede beneficiarse de más núcleos disponibles.

Otra consideración importante es maximizar los núcleos por servidor cuando se utiliza la virtualización. Es posible que las máquinas virtuales individuales no tengan un elevado número de núcleos, pero en conjunto hay que encontrar un equilibrio entre el número de servidores necesarios para la disponibilidad y minimizar el número de hosts para la administración y la consideración de los costes mediante el aumento del número de núcleos.

Virtualización de VMware y CPU

La virtualización de VMware funciona bien para Caché cuando se utiliza con los componentes de almacenamiento y del servidor actuales. Al seguir las mismas reglas que la planificación de la capacidad física, no hay un impacto significativo en el rendimiento usando la virtualización de VMware en el almacenamiento, la red y los servidores configurados correctamente. La compatibilidad con la virtulaización es mucho mejor en procesadores Intel Xeon posteriores, en concreto solo deberías considerar la virtualización en Intel Xeon 5500 (Nehalem) y versiones posteriores, es decir: Intel Xeon 5500, 5600, 7500, serie E7 y serie E5.

Ejemplo: Actualización de hardware, cómo calcular los requerimientos mínimos de CPU

Poniendo en práctica los consejos y procedimientos anteriores, nuestro ejemplo es una actualización de servidor de una carga de trabajo que se ejecuta en Dell PowerEdge R710 con 8 núcleos (dos procesadores de 4 núcleos Xeon 5570).

Al hacer un gráfico del uso actual de la CPU en el servidor de producción primario en el cliente, vemos que el servidor está alcanzando un máximo de menos del 80% durante la parte más activa del día. La fila de ejecución no está bajo presión. La Entrada/Salida y la aplicación también funcionan bien, por lo que no hay cuellos de botella que superen supriman la CPU.

Regla general: Comienza por dimensionar los sistemas para un uso máximo del 80% de la CPU al final de la vida útil del hardware, teniendo en cuenta el crecimiento esperado (por ejemplo, un aumento de usuarios/transacciones). Esto permite crecimientos inesperados, eventos inusuales o picos inesperados de actividad.

Para que los cálculos sean más claros, vamos a suponer que no se espera un crecimiento del rendimiento durante la vida del nuevo hardware:

El escalado por núcleo se puede calcular como: (251/8) (1030/24) o un aumento del 26% en el rendimiento por núcleo.

El 80% de la CPU con 8 núcleos en el servidor anterior equivale aproximadamente al 80% de la CPU con 6 núcleos en los nuevos procesadores E5-2680 V3. Así, el mismo número de transacciones podría estar soportado por seis núcleos.

El cliente tiene varias opciones, puede comprar nuevos servidores hardware dedicados que cumplan el requisito mínimo de seis núcleos de CPU E5-2680 V3 o su equivalente, o avanzar con sus planes para virtualizar su carga de trabajo de producción en VMware.

Virtualizar tiene sentido para aprovechar las ventajas de la consolidación, flexibilidad y alta disponibilidad de los servidores. Dado que hemos calculado los requisitos de la CPU, el cliente puede avanzar con confianza para ajustar correctamente el tamaño de las máquinas virtuales de producción en VMware. Como nota al margen, comprar servidores actuales con una baja cantidad de núcleos es una opción cara o de difícil acceso, lo cual hace que la virtualización sea una opción aún más atractiva.

Virtualizar también ofrece ventajas si se espera un crecimiento significativo. Los requisitos de la CPU se pueden calcular en función del crecimiento en los primeros años. Si se realiza una monitorización constante, una estrategia válida es añadir recursos adicionales solo cuando sea necesario y antes de necesitarlos.

Consideraciones sobre la CPU y la virtualización

Como hemos visto, los sistemas de producción en Caché son dimensionados en función de los análisis de rendimiento y las medidas realizadas en los clientes. También es válido dimensionar los requerimientos de la CPU virtual (vCPU) de VMware a partir de la monitorización de los equipos de hardware dedicado. La virtualización por medio del almacenamiento compartido añade muy poca sobrecarga a la CPU comparado con el hardware dedicado**. Para los sistemas de producción, utiliza una estrategia de ajustar el tamaño inicial del sistema igual que los núcleos de CPU de hardware dedicado.

**Nota: Para implementaciones de VMware VSAN debes añadir un búfer de la CPU a nivel host del 10% para el procesamiento de vSAN.

Se deben considerar las siguientes reglas para asignar CPUs virtuales:

Recomendación: No asignes más CPUs virtuales de las necesarias para lograr un rendimiento adecuado.

• Aunque se puede asignar un gran número de CPUs virtuales a una máquina virtual, la práctica recomendada es no asignar más de las necesarias, ya que puede haber una sobrecarga de rendimiento (normalmente baja) para administrar las CPUs virtuales no utilizadas. La clave es monitorizar tus sistemas frecuentemente para asegurarse de que las máquinas virtuales tengan el tamaño adecuado.

Recomendación: Los sistemas de producción, especialmente los servidores de bases de datos, inicialmente ajustan el tamaño para 1 CPU física = 1 CPU virtual.

• Se espera que los servidores de producción, especialmente los de bases de datos, tengan un alto nivel de uso. Si necesitas seis núcleos físicos, ajusta el tamaño para seis núcleos virtuales. Consulta también la nota sobre el Hyper Treading que se encuentra más abajo.

Sobresuscripción

La sobresuscripción se refiere a varios métodos por los cuales más recursos de los disponibles en el servidor físico se pueden asignar hacia los servidores virtuales que son compatibles con ese host. En general, es posible consolidar los servidores por medio de la sobresuscripción de recursos de procesamiento, memoria y almacenamiento en máquinas virtuales.

La sobresuscripción del servidor sigue siendo posible cuando se ejecutan bases de datos de producción en Caché; sin embargo, para ajustar el tamaño inicial de los sistemas de producción se asume que la CPU virtual tiene dedicación completa del núcleo. Por ejemplo, si tienes un servidor E5-2680 V3 de 24 núcleos (2 de 12 núcleos), ajusta el tamaño para una capacidad total de hasta 24 CPUs virtuales, sabiendo que podría haber espacio libre disponible para consolidación. En esta configuración se asume que el Hyper Threading está habilitado a nivel del servidor. Una vez que hayas pasado tiempo monitorizando la aplicación, el sistema operativo y el rendimiento de VMware durante las horas pico de procesamiento, puedes decidir si es posible una mayor consolidación.

Si estás mezclando máquinas virtuales que no son de producción, una regla general que uso a menudo para ajustar el tamaño del sistema y calcular los núcleos de CPU totales es ajustar inicialmente las CPUs que no son de producción en 2:1 físicas a virtuales. Sin embargo, esta es definitivamente un área en la que los resultados podrían variar y se deberá monitorizar el sistema para ayudar a planificar la capacidad. Si tienes dudas o no tienes experiencia, puedes separar las máquinas virtuales de producción de las que no lo son a nivel de servidor o por medio de la configuración de vSphere hasta comprender las cargas de trabajo.

VMware vRealize Operations y otras herramientas de terceros ofrecen la posibilidad de monitorizar los sistemas a lo largo del tiempo, y sugerir la consolidación o alertar de que se requieren más recursos para las máquinas virtuales. En un artículo posterior hablaré sobre otras herramientas de monitorización disponibles.

La conclusión es que, en el ejemplo de nuestros clientes, pueden estar seguros de que su máquina virtual de producción con 6 CPUs virtuales funcionará bien; siempre y cuando los otros "grupos alimenticios" principales, como las Entradas/Salidas y el almacenamiento, tengan capacidad suficiente ;-D

Hyper Threading y planificación de la capacidad

Un buen punto de partida para ajustar el tamaño de las máquinas virtuales basado en reglas conocidas para los servidores físicos es calcular los requisitos de la CPU del servidor físico, con el objetivo por procesador con Hyper Threading activado, y después simplemente hacer la traducción:

una CPU física (incluido el Hyper Threading) = una CPU virtual (incluido el Hyper Threading).

Un concepto erróneo común es que el Hyper Threading duplica de alguna manera la capacidad de la CPU virtual. Esto NO es cierto para los servidores físicos o para las CPUs virtuales lógicas. Como regla general, el Hyper Threading en un servidor de hardware dedicado puede ofrecer un 30% de capacidad de rendimiento adicional comparado con el mismo servidor sin Hyper Threading. La misma regla del 30% se aplica a los servidores virtualizados.

Licencias y CPUs virtuales

En vSphere, se puede configurar una máquina virtual con una cierta cantidad de ranuras o núcleos. Por ejemplo, si tienes una máquina virtual con doble procesador, se puede configurar para que tenga dos ranuras de CPU, o una única ranura con dos núcleos de CPU. Desde el punto de vista de la ejecución no hay mucha diferencia porque el hipervisor decidirá en última instancia si la máquina virtual se ejecuta en una o dos ranuras físicas. Sin embargo, especificar que la máquina virtual de doble CPU en realidad tiene dos núcleos en lugar de dos ranuras podría marcar una diferencia para las licencias de software que no son de Caché.

Resumen

En este artículo describí cómo comparar procesadores entre proveedores, servidores o modelos usando los resultados del análisis de rendimiento SPECint. También cómo planificar la capacidad y elegir los procesadores en función del rendimiento y la arquitectura, tanto si se utiliza la virtualización como si no.

Estos son temas complejos, en los que es fácil irse por las ramas… Por eso, al igual que en mis otras publicaciones, no dejes de hacer comentarios o preguntas si deseas profundizar en algún tema relacionado.

—

EJEMPLO: Búsqueda de resultados de SPECint_rate2006.

En la siguiente imagen se muestra la selección de los resultados de SPECint_rate2006.

Utiliza la pantalla de búsqueda para reducir resultados.

Ten en cuenta que también se pueden descargar todos los registros a un archivo .csv de aproximadamente 20 MB para su procesamiento local, por ejemplo con Excel.

Los resultados de la búsqueda muestran el Dell R730.

Selecciona HTML para dar el resultado completo del análisis de rendimiento.

Puedes ver los siguientes resultados para servidores con los procesadores de nuestro ejemplo.

Dell PowerEdge R710 con 2.93 GHz: 8 núcleos, 2 chips, 4 núcleos/chips, 2 hilos/núcleos con Xeon 5570: SPECint_rate_base2006 = 251

PowerEdge R730 (Intel Xeon E5-2680 v3, 2.50 GHz) de 24 núcleos, 2 chips, 12 núcleos/chips, 2 hilos/núcleos con Xeon E5-2680 v3: SPECint_rate_base2006 = 1030

La cobertura del código y su optmización del rendimiento ya han surgido muchas veces, así que la mayoría de vosotors seguro que ya conocéis la herramienta SYS.MONLBL.

A menudo, un enfoque visual para revisar el código es mucho más intuitivo que los números puros. Este es principalmente el objetivo de esta serie de artículos. Esta vez vamos a hacer una pequeña excursión lejos de Python y sus herramientas, y vamos a explorar la generación de mapas de calor de los informes ^%SYS.MONLBL.

Como recordatorio rápido, un mapa de calor es solo una herramienta de visualización concreta, que nos da una visión general de los datos, en la que los colores representan un determinado valor. En nuestro caso, los datos serán líneas de código, con el tiempo que se dedica a ellas representado en colores.

^%SYS.MONLBL

Para obtener más información sobre cómo ejecutar la monitorización línea a línea, consulta esta documentación. En resumen, vamos a trabajar con un archivo CSV como salida completa de un análisis. Es mucho más útil si realmente tenemos el código fuente que estamos tratando de analizar. Asegúrate de compilar tu código con la marca k (mantén la fuente).

Cómo preparar la salida

Como salida objetivo vamos a utilizar un documento ya preparado en html. Solo incluirá un diseño muy básico y una pequeña función en javascript para realizar el coloreado final.

<!doctype html>
<html class="no-js" lang="">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="x-ua-compatible" content="ie=edge">
        <title></title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        
        <!-- Place favicon.ico and apple-touch-icon.png in the root directory -->
        <link rel="apple-touch-icon" href="apple-touch-icon.png">

        <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/4.2.0/normalize.min.css">
        <script src="https://cdnjs.cloudflare.com/ajax/libs/modernizr/2.8.3/modernizr.min.js"></script>
        <!--<link rel="stylesheet" href="css/main.css"> -->
            <style>
        table, th, td {
            width:"100%";
            border: 1px solid black;
            border-collapse: collapse;
        }
        pre {
            margin:1px;
        }
        th {
            text-align: left;
        }
    </style>

Por motivos de seguridad, este bloque no puede estar editado como código. El siguiente bloque ha de ir entre etiqueta Script

    function rgba(r, g,b,a){
        r = Math.floor(r);
        g = Math.floor(g);
        b = Math.floor(b);
        return ["rgba(",r,",",g,",",b,",",a,")"].join("");
    }
    function colorize() {
        var rows=$("#data tr")
        var max=Math.max.apply(Math,rows.slice(1,rows.length).map(function(){ return this.childNodes[2].textContent}))
        for (i=1;i<rows.length;i++){
            var val=rows[i].childNodes[2].textContent;
            var c=(Math.pow(1-val/max,3))*255;
            var col=rgba(255,c,c,0.7);
            console.log(col);
            rows[i].style.backgroundColor=col;
        }
    }

Aquí iria el cierre de la etiqueta script

    </head>

    <body onload="colorize()">
        <!--[if lt IE 8]>
            <p class="browserupgrade">You are using an <strong>outdated</strong> browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p>
        <![endif]-->

Por motivo de seguriad, este bloque no puede estar editado como código

<table id="data">
<tr><th>Routine</th><th>Line</th><th>Total Time</th><th>Code</th></tr>
<!--output-->
</table>


    </body>
</html>

Analizar y reunir la información

Por medio de los siguientes scripts se obtiene la información relevante del CSV generado y se introduce en nuestra plantilla:

monlbl.sh

#!/bin/bash

cat $1|grep -vi totals| awk -F"," 'FNR>1 {out="<tr><td>"$1"</td>" "<td>" $2 "</td><td>" $54 "</td><td><pre>"; for(i=55;i<=NF;i++){out=out$i","}; out=substr(out, 1, length(out)-1) "</pre></td></tr>"; print out }'

gen-heatmap.sh

#!/bin/bash
./monlbl.sh $1 > /tmp/temp.data
sed -e '/<!--output-->/r/tmp/temp.data' template.html

Que llamamos de esta forma:

./gen-heatmap.sh /tmp/report.csv > heatmap.html

Resultado final

Ajustables

Si echas un vistazo más de cerca a la función de coloreado en nuestra plantilla, verás que no estoy usando un mapeo lineal para los tiempos:

    function colorize() {
        var rows=$("#data tr")
        var max=Math.max.apply(Math,rows.slice(1,rows.length).map(function(){ return this.childNodes[2].textContent}))
        for (i=1;i<rows.length;i++){
            var val=rows[i].childNodes[2].textContent;
            var c=(Math.pow(1-val/max,3))*255;
            var col=rgba(255,c,c,0.7);
            console.log(col);
            rows[i].style.backgroundColor=col;
        }
    }

Encontré que esto funcionaba bastante bien con los ejemplos que probé, pero los resultados pueden variar. Evidentemente, se puede aumentar el exponente para llevarlo más al rojo, o viceversa.

Código

Puedes encontrar todos los archivos relevantes aquí

Al trabajar desde casa durante estos "días de coronavirus", me faltan recursos.

• no tengo ninguna máquina Linux disponible
• espacio en disco limitado

Además, Docker Desktop (en Windows10) bloqueó de alguna manera los scripts de Durable %SYS como se describe aquí.
Investigando el caso, descubrí que se almacenaban muchos más datos de los que realmente necesitaba.
Así que diseñé mi durabilidad personalizada.

Utilizando las características de **iris-main **agrego un script de pre-procesamiento para iniciar mi contenedor con 

Después de que termina, guardo lo que creo necesitar para el próximo inicio.

Y eso es bastante menos.
De acuerdo: Puede que se me escapen algunas cosas y finalmente es más lento en start/stop. Muy bien. ¡Pero está en mis manos!
  Los scripts para ejecutar y también los datos guardados están almacenados en el directorio externo que necesito para la licencia.
Y esos scripts son bastante sencillos:

y

Como no hay nada que configurar en la primera ejecución, omito pre.copy como la primera ejecución hecha.
Por lo demás, mi comando de ejecución en Docker tiene el siguiente aspecto:

Si tiempo después descubro que necesito guardar/recuperar algo más (por ejemplo, para CSP, ... ) es fácil añadirlo.
La clave del éxito fue dejar la base de datos IRISSYS en la ubicación que se incluye en el contenedor. Su tamaño de ~92 MB (en mi caso) no es relevante.

En el artículo anterior creamos un gráfico simple con los datos de un solo archivo. Ahora bien, como todos sabemos, a veces tenemos diferentes archivos de datos para analizar y correlacionar. Así que en este artículo vamos a cargar datos adicionales de perfmon y aprenderemos a representarlos en el mismo gráfico.

Como podemos querer utilizar en informes o en una página web nuestros gráficos generados, también revisaremos formas de exportar los gráficos generados.

Cargando datos de Windows Perfmon

Los datos de perfmon extraídos del informe estándar de pbuttons tienen un formato de datos un poco peculiar. A primera vista es un archivo csv bastante sencillo. La primera fila contiene los encabezados de las columnas, las filas siguientes los datapoints. Sin embargo, para nuestros propósitos tendremos que hacer algo con las comillas que rodean las entradas de los valores. Utilizando el enfoque estándar para analizar el archivo en python, terminaremos con columnas de objetos de tipo cadena, que no funcionan bien para ser representados de forma gráfica.

perfmonfile="../vis-part2/perfmon.txt"
perfmon=pd.read_csv(perfmonfile,
                    header=0,
                    index_col=0,
                    converters={0: parse_datetime
                    })

A diferencia del archivo mgstat que utilizamos en la primera parte, los nombres de los encabezados están en la primera fila. Queremos que la primera columna defina nuestro índice (de esta manera no tenemos que volver a indexar el dataframe como hicimos la última vez). Por último, debemos analizar la primera columna para que realmente represente un DateTime. De lo contrario, terminaríamos con un índice de cadenas. Para ello, definimos una pequeña función de ayuda para analizar las fechas de perfmon:

def parse_datetime(x):
    dt = datetime.strptime(x, '%m/%d/%Y %H:%M:%S.%f')

    return dt

El parámetro ~~~conventers~~~ nos permite pasarlo como controlador de la primera columna.

Después de ejecutar esto, terminamos con los datos de perfmon en un DataFrame:

<class 'pandas.core.frame.DataFrame'>
Index: 2104 entries, 01/03/2017 00:01:19.781 to 01/03/2017 17:32:51.957
Columns: 105 entries, \\WEBSERVER\Memory\Available MBytes to \\WEBSERVER\System\Processor Queue Length
dtypes: float64(1), int64(11), object(93)
memory usage: 1.7+ MB

Ten en cuenta que la mayoría de las columnas actualmente son un object. Para convertir estas columnas a un formato utilizable, emplearemos la función to_numeric. Aunque podríamos usar apply para llamarlo en cada columna, eso estropearía nuestro índice de nuevo. Así que vamos a trazar los datos directamente mientras se canaliza a través de eso.

#Plotting En esta ocasión, nos interesa representar el tiempo total privilegiado de todas las CPUs. Lamentablemente, los números de las columnas no son constantes y varían con el número de CPU y drives. Así que tendrás que observar y averiguar qué columna es. En mi ejemplo es 91:

perfmon.columns[91]

'\\\\WEBSERVER\\Processor(_Total)\\% Privileged Time'

Utilizaremos más o menos el mismo enfoque que la última vez para crear un gráfico con Glorefs, Rdratio y nuestro nuevo Privileged Time:

plt.figure(num=None, figsize=(16,5), dpi=80, facecolor='w', edgecolor='k')
host = host_subplot(111, axes_class=AA.Axes)
plt.subplots_adjust(right=0.75)

par1 = host.twinx()
par2 = host.twinx()
offset = 60
new_fixed_axis = par2.get_grid_helper().new_fixed_axis
par2.axis["right"] = new_fixed_axis(loc="right",axes=par2,offset=(offset, 0))
par2.axis["right"].toggle(all=True)

host.set_xlabel("time")
host.set_ylabel("Glorefs")

par1.set_ylabel("Rdratio")
par2.set_ylabel("Privileged Time")
ws=30
p1,=host.plot(data.Glorefs,label="Glorefs")
p2,=par1.plot(data.Rdratio,label="Rdratio")
p3,=par2.plot(pd.to_numeric(perfmon[perfmon.columns[91]],errors='coerce'),label="PTime")

host.legend()

host.axis["left"].label.set_color(p1.get_color())
par1.axis["right"].label.set_color(p2.get_color())
par2.axis["right"].label.set_color(p3.get_color())

plt.draw()
plt.show()

Aquí es donde se utiliza to_numeric:

p3,=par2.plot(pd.to_numeric(perfmon[perfmon.columns[91]],errors='coerce'),label="PTime")

Cómo redirigir la salida

Mientras que Notebook es realmente bueno para tener un vistazo rápido de nuestros datos, con el tiempo nos gustaría ser capaces de ejecutar nuestros scripts de forma no interactiva, por lo que queremos que nuestros gráficos salgan como imágenes. Obviamente, realizar una captura de pantalla implica demasiado trabajo manual, así que utilizaremos la función pyplot savefig().

Reemplazaremos las llamadas draw() y show() con la llamada savefig():

#plt.draw()
#plt.show()
plt.savefig("ptime-out.png")

que nos dará el png en nuestro directorio de trabajo actual.

Salida avanzada

Como un pequeño ejercicio adicional vamos a echar un vistazo a Bokeh. Una de las muchas útiles características que bokeh está añadiendo a nuestra caja de herramientas, es la capacidad de generar nuestros gráficos como un archivo HTML interactivo. Interactivo en este caso significa que podemos ampliar y desplazarnos por nuestros datos. Añade la capacidad de vincular gráficos entre sí y podrás crear fácilmente renderizados interactivos de datos de pbuttons (u otros). Estos son especialmente útiles, porque se ejecutan en cualquier navegador y se pueden distribuir fácilmente a varias personas.

Por ahora, nuestro objetivo es añadir solo dos gráficos a nuestra salida. Nos gustaría obtener Glorefs y el tiempo privilegiado de perfom en una página.

Para eso primero tendremos que importar bokeh:

from bokeh.plotting import *

Vamos a definir un par de propiedades y etiquetas, así como el tamaño de cada gráfico. Después, representaremos los datos de los objetos que recogimos antes y ya hemos terminado.

Fíjate en el comentario output_notebook(), esto renderizaría la salida directamente en nuestro jupyter notebook. Estamos utilizando output_file ya que nos gustaría tener un archivo que podamos distribuir.

output_file("mgstat.html")
#output_notebook()
TOOLS="pan,box_zoom,reset,save"

left = figure(tools=TOOLS,x_axis_type='datetime',
    title="Glorefs",width=600, height=350,
   x_axis_label='time'
)
right=figure(tools=TOOLS,x_axis_type='datetime',
    title="PTime",width=600, height=350,
   x_axis_label='time',x_range=left.x_range
)
left.line(data.index,data.Glorefs,legend="Glorefs",line_width=1)
right.line(perfmon.index,pd.to_numeric(perfmon[perfmon.columns[91]],errors='coerce'),legend="privileged time",line_width=1)
p=gridplot([[left,right]])
show(p)

El ingrediente clave aquí es la vinculación de los rangos de nuestros dos gráficos con x_range=left.x_range. Esto actualizará la ventana derecha con nuestra selección/zoom/movimiento desde la izquierda (y viceversa).

La lista de HERRAMIENTAS es solo la lista de herramientas que nos gustaría tener en nuestra pantalla resultante. Usando gridplot vamos a poner los dos gráficos uno al lado del otro:

También puedes echar un vistazo al html resultante en el repositorio de github. Parece que es demasiado grande para publicarlo directamente por medio de github, así que tendrás que descargarlo.

Conclusiones

En este artículo, exploramos la extracción de datos de diferentes fuentes y su representación en el mismo gráfico. También estamos gestionando datos con frecuencia de muestreo diferente (apuesto a que no te diste cuenta ;D ). Bokeh nos ofrece una potente herramienta para crear vistas interactivas fácilmente distribuibles para nuestros gráficos.

En próximos artículos exploraremos más cosas para representar gráficamente: csp.log, registros de acceso de apache/iis, eventos de cconsole.log. Si tienes alguna sugerencia sobre algunos datos que te gustaría ver procesados con python, no dudes en comentarlo.

¡Comparte tus experiencias! ¡Esto está pensado como un aprendizaje interactivo!

Enlaces

Puedes encontrar todos los archivos de este artículo aquí También puedes ver la nueva herramienta de extracción pButtons de @murrayo, basada en algunas de las técnicas comentadas: https://github.com/murrayo/yape

Objetivo

Esta herramienta se usa para generar una Entrada/Salida (E/S) de lectura aleatoria desde dentro de la base de datos. La finalidad de esta herramienta es llevar la mayor cantidad de tareas posibles para conseguir las IOPS objetivo y asegurar que se mantienen tiempos de respuesta de disco aceptables. Los resultados recopilados de las pruebas de E/S variarán de configuración a configuración, de acuerdo con el subsistema de E/S. Antes de ejecutar estas pruebas, asegúrate de que el sistema operativo y la monitorización del nivel de almacenamiento estén configurados para capturar métricas de desempeño de E/S para su posterior análisis.

Metodología

Empieza con una cantidad reducida de procesos y 10 000 iteraciones por proceso. Usa 100 000 iteraciones por proceso para matrices de almacenamiento basadas íntegramente en tecnología flash. A continuación, aumenta el número de procesos, por ejemplo, empieza con 10 trabajos y aumenta en 10, 20, 40, etc. Sigue ejecutando pruebas individuales hasta que el tiempo de respuesta esté por encima de 10 ms de forma constante, o las IOPS calculadas ya no aumenten de forma lineal.  

Como guía, los siguientes tiempos de respuesta para lecturas aleatorias de bases de datos de 8KB y 64KB (sin cache) normalmente son aceptables para las matrices íntegramente flash:

• Promedio <= 2ms
• No debe exceder <= 5ms

La herramienta necesita una base de datos IRIS.DAT pre-expandida vacía, de un tamaño de al menos el doble del espacio de memoria en el servidor y de al menos cuatro veces el tamaño del la cache del controlador de almacenamiento. La base de datos debe ser mayor que la memoria, para asegurar que las lecturas no se guarden en la cache del sistema de archivos. 

La herramienta usa el comando VIEW de ObjectScript, que lee bloques de bases de datos en memoria, así que si no estás logrando los resultados esperados, puede que todos los bloques de la base de datos ya estén en memoria.

Especificaciones y objetivos

Completa la siguiente tabla con tus objetivos y especificaciones de entorno:

Instalación

Descarga la herramienta PerfTools.RanRead.xml de GitHub aquí.

Importa PerfTools.RanRead.xml en el namespace USER.

USER> do $system.OBJ.Load("/tmp/PerfTools.RanRead.xml","ckf")

Ejecuta el método Help para ver todos los puntos de acceso. Todos los comandos se ejecutan en %SYS.

USER> do ##class(PerfTools.RanRead).Help()
 
InterSystems Random Read IO Performance Tool
--------------------------------------------
do ##class(PerfTools.RanRead).Setup(Directory,DatabaseName,SizeGB,LogLevel)
    - Creates database and namespace with the same name. The log level must be in the range of 0 to 3, where 0 is “none” and 3 is “verbose”.
do ##class(PerfTools.RanRead).Run(Directory,Processes,Iterations)
    - Run the random read IO test.
do ##class(PerfTools.RanRead).Stop()
    - Terminates all background jobs.
do ##class(PerfTools.RanRead).Reset()
    - Deletes all random read history stored in ^PerfTools.RanRead*
do ##class(PerfTools.RanRead).Export(directory)
    - Exports a summary of all random read test history to tab delimited text file.

Configuración

Crea una base de datos vacía (preexpandida) llamada ZRANREAD de aproximadamente el doble de tamaño de la memoria del servidor físico a probar. Asegúrate de que la base de datos vacía tenga al menos cuatro veces el tamaño de la cache del controlador de almacenamiento. Para crear automáticamente un namespace y una base de datos, puedes hacerlo manualmente o usar el siguiente método.

USER> do ##class(PerfTools.RanRead).Setup("/usr/iris/db/zranread","ZRANREAD",100,1)
 
Creating 100GB database in /usr/iris/db/zranread/
Database created in /usr/iris/db/zranread/
Run %Installer Manifest...
2016-05-23 13:33:59 0 PerfTools.RanRead: Installation starting at 2016-05-23 13:33:59, LogLevel=1
2016-05-23 13:33:59 1 CreateDatabase: Creating database ZRANREAD in /usr/iris/db/zranread// with resource
2016-05-23 13:33:59 1 CreateNamespace: Creating namespace ZRANREAD using ZRANREAD/ZRANREAD
2016-05-23 13:33:59 1 ActivateConfiguration: Activating Configuration
2016-05-23 13:34:00 1 EnableEnsemble: Enabling ZRANREAD
2016-05-23 13:34:00 1 ActivateConfiguration: Activating Configuration
2016-05-23 13:34:00 0 PerfTools.RanRead: Installation succeeded at 2016-05-23 13:34:00
2016-05-23 13:34:00 0 %Installer: Elapsed time 1.066633s
Database /usr/iris/db/zranread/ ready for testing.
do ##class(PerfTools.RanRead).Run(directory,processes,iterations) e.g.
do ##class(PerfTools.RanRead).Run("/usr/iris/db/zranread/",1,10000)

Ejecución

Ejecuta el método Run aumentando la cantidad de procesos y tomando nota, cada vez, del tiempo de respuesta.
Si las pruebas son demasiado rápidas o los resultados no son los esperados, aumenta entonces el número de iteraciones a 10 000.

USER> do ##class(PerfTools.RanRead).Run("/usr/iris/db/zranread",20,10000)
 
InterSystems Random Read IO Performance Tool
--------------------------------------------
Starting 20 jobs in the background.
To terminate jobs run:  do ##class(PerfTools.RanRead).Stop()
Waiting for jobs to finish.........................
Random read background jobs finished.
20 processes (1000 iterations) average response time = 7.18ms
Calculated IOPS = 2787

Resultados

Los resultados para cada ejecución se guardan en USER en la tabla SQL PerfTools.RanRead. Ejecuta la siguiente consulta SQL para ver un resumen de resultados.

SELECT RunDate,RunTime,Database,Iterations,Processes,
    {fn ROUND(AVG(ResponseTime),2)} As ResponseTime,
    {fn ROUND(AVG(IOPS),0)} As IOPS
FROM PerfTools.RanRead
GROUP BY Batch

Para exportar el conjunto de resultados a un archivo de texto delimitado por tabulaciones, ejecuta lo siguiente:

USER> do ##class(PerfTools.RanRead).Export("/usr/iris/db/zranread/")
 
Exporting summary of all random read statistics to /usr/iris/db/zranread/PerfToolsRanRead_20160523-1408.txt
Done.

Análisis

Abre en Excel el archivo de texto exportado. Luego, copia y pega los datos en la hoja de cálculo PerfToolsRandomRead_Analysis_Template.xlsx para hacer un gráfico. 

La hoja de cálculo de muestra se puede descargar desde GitHub aquí.

Limpieza

Cuando se terminen de ejecutar las pruebas, elimina el historial ejecutando:

%SYS> do ##class(PerfTools.RanRead).Reset()

​

Una cuestión muy común es cuál es la configuración ideal para el servidor web Apache HTTPD cuando se utiliza con HealthShare. El propósito de este artículo es describir la configuración inicial recomendada del servidor web para cualquier producto HealthShare. 

Como punto de partida, se recomienda la versión 2.4.x (64-bit) de Apache HTTPD. Existen versiones anteriores como la 2.2.x, pero no se recomienda esta versión por rendimiento y escalabilidad de HealthShare.

Configuración de Apache

Módulo de la API de Apache sin NSD

HealthShare requiere la opción de instalación del módulo de la API de Apache sin NSD. La versión de los módulos vinculados de forma dinámica depende de la versión de Apache:

• CSPa24.so (Apache versión 2.4.x)

Es mejor dejar que la configuración de las Caché Server Pages (CSP) en el httpd.conf de Apache sea realizada por la instalación de HealthShare, la cual se explica en detalle más adelante en este documento. Sin embargo, la configuración puede realizarse manualmente. Para más información, consulta la Guía de Configuración de Apache que se encuentra en la documentación de InterSystems:  Opción recomendada: módulo de la API de Apache sin NSD (CSPa24.so)

Recomendaciones del Módulo de multiprocesamiento (MPM) de Apache

MPM Prefork de Apache vs. MPM Worker {#ApacheWebServer-ApachePreforkMPMVs.WorkerMPM}

El servidor web de Apache HTTPD incluye tres módulos de multiprocesamiento (Multi-Processsing Modules - MPM): Prefork, Worker y Event. Los MPM son responsables de conectar los equipos con los puertos de red, aceptar solicitudes y generar procesos hijos o secundarios que se encarguen de administrarlos. Por defecto, Apache se suele configurar con MPM Prefork, que no escala muy bien para un número de transacciones elevadas o altas cargas de trabajo de usuarios concurrentes.

En los sistemas de producción de HealthShare, el MPM Worker de Apache debería habilitarse por razones de rendimiento y escalabilidad. Se prefiere el MPM Worker por las siguientes razones:

• El MPM Prefork utiliza varios procesos secundarios con un hilo de ejecución (thread) cada uno, y cada proceso controla una conexión a la vez. Al utilizar Prefork, las solicitudes concurrentes se ven afectadas porque como cada proceso solo puede manejar una sola solicitud a la vez, las solicitudes se quedan esperando en cola hasta que se libere un proceso del servidor. Además, para escalar, son necesarios más procesos secundarios de Prefork, que consumen una gran cantidad de memoria.
• El MPM Worker utiliza varios procesos secundarios con muchos hilos de ejecución (thread) cada uno. Cada hilo de ejecución maneja una conexión al mismo tiempo, lo que es de gran ayuda para la concurrencia y reduce el uso de la memoria. Worker gestiona mejor la concurrencia que Prefork, ya que generalmente habrá hilos de ejecución libres disponibles para atender las solicitudes, en lugar de los procesos de Prefork con un solo hilo que podría estar ocupado.

Parámetros del MPM Worker de Apache {#ApacheWebServer-ApacheWorkerMPMParameters}

Utilizando hilos de ejecución para atender las solicitudes, Worker puede atender una gran cantidad de solicitudes empleando menos recursos del sistema que el Prefork utilizando procesos. 
Las directivas más importantes utilizadas para controlar el MPM Worker son ThreadsPerChild, que controla el número de hilos de ejecución desplegados por cada proceso hijo y MaxRequestWorkers, que controla el número total máximo de hilos que se pueden lanzar.
Los valores comunes de la directiva que se recomiendan para el MPM Worker se especifican en la siguiente tabla:

<th>
  Valor recomendado
</th>

<th>
  Comentarios
</th>

<td>
  Número máximo de usuarios simultáneos en el Visor Clínico de HealthShare, o el de otros componentes de HealthShare que se configuraron como la suma de todos los tamaños de grupo (*Pool Size*) de Business Services entrantes a todos los productos definidos por las producciones. 

Para más información, consulta la documentación correspondiente a la versión de Apache:

• Directivas comunes de Apache 2.4 MPM

Ejemplo para configurar el MPM Worker de Apache 2.4

En esta sección se especifica cómo configurar el MPM Worker para un servidor web Apache 2.4 de RHEL7, necesario para permitir hasta 500 usuarios simultáneos de TrakCare.

1. Primero, verificar el MPM mediante el siguiente comando:
2. Edita el archivo de configuración /etc/httpd/conf.modules.d/00-mpm.conf cuando sea necesario, agregando y eliminando el signo # para que solo se carguen los módulos MPM Worker. Modifica la sección MPM Worker con los siguientes valores, en el mismo orden que se indica a continuación:
3. Reinicia Apache
4. Después de que reinicie Apache correctamente, valida los procesos de worker ejecutando los siguientes comandos. Deberías ver algo parecido a lo siguiente, validando el proceso httpd.worker:

Fortalecimiento de Apache

Módulos requeridos de Apache

La instalación del paquete de distribución oficial de Apache habilitará, por defecto, un conjunto específico de módulos de Apache. Esta configuración predeterminada de Apache cargará estos módulos en cada proceso httpd. Se recomienda deshabilitar todos los módulos que no sean necesarios para HealthShare, por las siguientes razones:

• reducir el consumo de recursos del proceso httpd daemon,
• reducir la posibilidad de que falle la segmentación desde un módulo problemático,
• reducir las vulnerabilidades de la seguridad.

En la siguiente tabla se describen los módulos de Apache recomendados para HealthShare. Cualquier módulo que no se encuentre en la lista, se puede deshabilitar:

Cómo deshabilitar los módulos

Los módulos que no sean necesarios deben deshabilitarse para fortalecer la configuración y de esta manera reducir los puntos vulnerables en la seguridad. El cliente es responsable de las políticas de seguridad del servidor web. Por lo menos, deben deshabilitarse los siguientes módulos.

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

InterSystems recomienda que todas las comunicaciones que se realizan mediante TCP/IP entre los servidores y los clientes de HealthShare se cifren con SSL/TLS para proteger los datos durante las transferencias y garantizar la confidencialidad y la autenticación. Además, InterSystems también recomienda que se utilice HTTPS para llevar a cabo las comunicaciones entre los navegadores (clientes) de los usuarios y la capa del servidor web de la arquitectura propuesta. Asegúrate de consultar las políticas de seguridad de tu empresa, para garantizar que cumple con cualquier requisito de seguridad específico que tenga. 

El cliente es responsable de suministrar y administrar los certificados SSL/TLS.
Si utilizas certificados SSL, agrega ssl_module (mod_ssl.so).

Parámetros adicionales para el fortalecimiento de Apache

Para fortalecer aún más la configuración de Apache, realiza los siguientes cambios en httpd.conf:

• TraceEnable debe desactivarse para evitar posibles problemas de seguimiento entre sitios.

• ServerSignature debe desactivarse para que no se visualice la versión del servidor web.

Parámetros de configuración suplementarios de Apache {#ApacheWebServer-SupplementalApacheConfigurationParameters}

Keep-Alive {#ApacheWebServer-Keep-Alive}

La configuración de Apache Keep-Alive permite utilizar la misma conexión TCP para la comunicación mediante HTTP, en vez de abrir una nueva conexión para cada nueva solicitud, es decir, Keep-Alive mantiene una conexión persistente entre el cliente y el servidor. Cuando la opción Keep-Alive está habilitada, la mejora en el desempeño proviene de la descongestión de la red, la reducción de la latencia en las subsiguientes solicitudes y el menor uso del CPU ocasionado por la apertura simultánea de las conexiones. Keep-Alive está ACTIVO por defecto y el estándar HTTP v1.1 requiere que se asuma.

Sin embargo, hay ciertas condiciones para habilitar Keep-Alive; Internet Explorer debe ser la versión 10 o superior para evitar problemas como el tiempo de espera, que se presenta en las versiones anteriores de Internet Explorer. Además, intermediarios como firewalls, balanceadores de cargas y proxies, etc., pueden interferir con las “conexiones TCP persistentes” y pueden ocasionar el cierre imprevisto de las conexiones.  

Cuando se habilita Keep-Alive, su tiempo de espera también debe ser ajustarse. El tiempo de espera predeterminado de Keep-Alive para Apache es excesivamente bajo, y debe aumentarse en la mayoría de las configuraciones debido a que pueden surgir incidencias asociadas con la interrupción de las solicitudes AJAX (es decir, hipereventos). Estas incidencias pueden evitarse si se asegura que el tiempo de espera de Keep-Alive en el servidor es mayor que para el cliente.  En otras palabras, el cliente debe cumplir con el tiempo de espera y cerrar la conexión en vez de que lo haga el servidor.  La mayoría de las veces los problemas ocurren (en Internet Explorer más que en otros navegadores), cuando el navegador intenta utilizar una conexión (particularmente para una PUBLICACIÓN) que se supone que estaría abierta. 

Consulta los siguientes valores recomendados de KeepAlive y KeepAliveTimeout para un servidor web HealthShare.

Para habilitar KeepAlive en Apache, realiza los siguientes cambios en httpd.conf:

CSP Gateway

Para el parámetro KeepAlive de CSP Gateway, deja el valor predeterminado de No Action, porque el estado de KeepAlive se determina por los encabezados de respuesta HTTP de cada solicitud.

Nota (junio de 2019): han cambiado muchas cosas para obtener los detalles más recientes, haz clic aquíNota (septiembre de 2018): ha habido grandes cambios desde que esta publicación apareció por primera vez; sugiero que utilices la versión del contenedor en Docker dado que el proyecto y la información para que se ejecute como un contenedor sigue publicada en GitHub, en el mismo lugar, para que puedas descargarlo, ejecutarlo y modificarlo, si lo necesitas.

Cuando trabajo con clientes en revisiones de rendimiento, planificaciones de capacidad y resolución de problemas, con frecuencia tengo que descomprimir y revisar las métricas del sistema operativo y de caché desde pButtons. En vez de lidiar con los archivos html para cortar y pegar secciones que serán graficadas en Excel, hace algún tiempo escribí una publicación sobre una herramienta para descomprimir las métricas de pButtons, escrita con el intérprete de unix, perl y los scripts de awk. Si bien este es un valioso ahorro de tiempo, no es la historia completa…

También utilizo scripts para realizar automáticamente gráficos de las métricas, para revisiones rápidas y para inconporarlos a informes. Sin embargo, estos gráficos realizados con scripts no se mantienen fácilmente y se vuelven especialmente confusos cuando se necesita una configuración específica del sitio, por ejemplo, una lista de discos para iostat o windows perfmon. Por eso, nunca publiqué las herramientas para hacer gráficos. Pero estoy muy contento de anunciar que ahora existe una solución mucho más sencilla.

El descubrimiento fortuito ocurrió cuando estaba en las instalaciones de un cliente observando el rendimiento del sistema con Fabian, y él me mostró lo que hacía para utilizar ciertos módulos de Python para realizar gráficos. Esta es una solución mucho más flexible y fácil de mantener que los scripts que utilizaba. Y la facilidad de integrar los módulos de Python para administrar archivos y gráficos, incluyendo la posibilidad de compartir el html interactivo, significa que el resultado puede ser mucho más útil. Al tomar las publicaciones de Fabian como base, escribí Yape para extraer de forma rápida y sencilla, y luego hacer gráficos de los archivos pButtons de los clientes, en varios formatos. El proyecto se publicó en GitHub para que puedas descargarlo, ejecutarlo y modificarlo, si lo necesitas.

Resumen

Actualmente, este proceso consiste en dos pasos.

Paso 1. extract_pButtons.py

Extrae las secciones de interés desde pButtons, y escríbelas en archivos de tipo .csv para abrirlos con Excel o para que se procesen con gráficos utilizando graph_pButtons.py.

Paso 2. graph_pButtons.py

Los archivos de gráficos se crearon en el Paso 1. Actualmente las salidas pueden ser gráficas de líneas o de puntos que se representan como .png o .html interactivos e incluyen opciones de vista panorámica, zoom, impresión, etc.

Readme.md en GitHub tiene especificaciones sobre cómo configurar y ejecutar los dos scripts de Python, y será la referencia más reciente.

Notas adicionales

Por ejemplo: si utilizas las opciones para agregar prefijos a los directorios de entrada y salida, podrás examinar fácilmente un directorio con un conjunto de archivos pButtons de html (por ejemplo, semanas) y enviarlos a un directorio separado para cada archivo pButtons.

for i in `ls *.html`; do ./extract_pButtons.py $i -p ${i}_; done

for i in `ls *.html`; do ./graph_pButtons.py ./${i}_metrics -p ${i}_; done

A corto plazo, mientras continúo con la serie sobre cómo planificar y aumentar rendimiento de la plataforma de datos InterSystems IRIS, utilizaré los gráficos creados con estas herramientas.

Lo probé en OS X, pero no en Windows. No debería tener ningún problema para instalar y ejecutar Python en Windows. Supongo que necesitarás realizar algunos cambios en las barras que se encuentran en la ruta de un archivo. Deja tus comentarios si lo pruebas.

Nota: hasta hace unas semanas nunca había escrito nada en Python, así que si es un experto en este lenguaje, posiblemente te darás cuenta de que algunas partes del código no siguen las prácticas recomendadas. Sin embargo, utilizo los scripts casi todos los días, por lo que seguiré mejorándolos. Espero perfeccionar mis habilidades en Python, ¡pero siéntete libre de “educarme” si ves algo que debería corregirse!

Si descubres que los scripts te resultan útiles, házmelo saber y vuelve con frecuencia para obtener nuevas características y actualizaciones.

Hay tres aspectos muy importantes en cualquier conversación sobre el rendimiento de SQL: los Índices, el TuneTable, y el Plan de ejecución. En los PDFs adjuntos a este artículo se incluyen presentaciones antiguas sobre estos temas. En los enlaces a nuestra documentación debajo, se ofrece más información sobre estos y otros asuntos relacionados con el rendimiento de SQL. La formación online también refuerza varios de estos temas. Además, hay varios artículos de la Comunidad de Desarrolladores que están relacionados con el rendimiento de SQL y que mostramos a continuación.

Hay bastantes repeticiones en la información que se muestra a continuación.  Los aspectos más importantes a considerar sobre el rendimiento de SQL son:

• Los tipos de índices que están disponibles
• Por qué utilizar un tipo de índice en lugar de otro
• La información que TuneTable recaba para crear una tabla y lo que esto significa para Optimizer
• Cómo leer un Plan de ejecución para comprender mejor si una consulta es buena o mala

En la última publicación programamos recogidas de métricas de rendimiento usando pButtons, a lo largo de 24 horas. En esta publicación, analizaremos algunas de esas métricas clave que se están recogiendo y cómo se relacionan con el hardware del sistema subyacente. También empezaremos a explorar la relación entre las métricas de Caché (o de cualquiera de las plataformas de datos de InterSystems) y las métricas del sistema. Veremos también cómo usar estas métricas para entender el pulso diario de tu sistema y diagnosticar problemas de rendimiento.

Editado en octubre de 2016...Añado un ejemplo de script para extraer datos de pButtons a un archivo .csvEditado en marzo de 2018... Las imágenes habían desaparecido, las volví a añadir.

Grupos alimenticios de hardware

Como verás a medida que avancemos por esta serie de artículos, los componentes del servidor que afectan al rendimiento pueden categorizarse como:

• CPU
• Memoria
• Almacenamiento de entrada y salida
• Red de entrada y salida

Si alguno de estos componentes está bajo una carga excesiva, el rendimiento del sistema y la experiencia de usuario seguramente se vean disminuidas. Estos componentes también están todos relacionados entre sí, los cambios en un componente pueden afectar a otro, a veces con consecuencias imprevistas. He visto un caso en el que corregir un cuello de botella de E/S en una matriz de almacenamiento causó que el uso de CPU saltara a 100%. Esto resultó en una experiencia de usuario aún peor, ya que el sistema de pronto quedó libre para hacer más trabajo, pero no tenía los recursos de CPU para atender el aumento en la actividad de usuario y el rendimiento.

También veremos como la actividad del sistema Caché tiene un impacto directo sobre los componentes del servidor. Si los recursos de E/S de almacenamiento son limitados, un cambio positivo que se puede hacer es aumentar la memoria del sistema y aumentar la memoria para búferes globales de Caché, lo que a su vez puede reducir la E/S de lectura de almacenamiento del sistema (¡pero quizás aumentar la CPU!).

Una de las métricas más obvias del sistema para monitorizar frecuentemente o para revisar cuándo reportan problemas los usuarios es el uso de CPU. Debemos mirar top o nmon en Linux o AIX, o Windows Performance Monitor. Como la mayoría de los administradores de sistemas revisan frecuentemente los datos de la CPU, especialmente si se presentan de forma gráfica, un rápido vistazo nos da una buena idea de la salud actual del sistema: qué es normal y qué es un pico repentino de actividad que podría ser anormal o indicativo de un problema. En este artículo revisaremos brevemente las métricas de CPU, y nos centraremos en las métricas de Caché. Comenzaremos por ver los datos de mgstat y entenderemos que mirar los datos de forma gráfica nos permite obtener, de un vistazo, una idea de la salud del sistema.

Introducción a mgstat

mgstat es uno de los comandos de Caché incluidos y ejecutados en pButtons. mgstat es una gran herramienta para recoger métricas básicas de rendimiento para ayudarte a entender la salud de tus sistemas. Observaremos los datos de mgstat recogidos de un pButtons de 24 horas, pero si quieres capturar datos fuera de mgstat de pButtons, también puede ejecutarse a demanda de forma interactiva o como tarea en segundo plano desde el terminal de Caché.

Para ejecutar mgstat a demanda desde el namespace %SYS, el formato general es.

do mgstat(sample_time,number_of_samples,"/file_path/file.csv",page_length) 

Por ejemplo, para ejecutar una tarea en segundo plano para una ejecución de una hora con período de muestreo de 5 segundos y salida a un archivo csv.

job ^mgstat(5,720,"/data/mgstat_todays_date_and_time.csv") 

Por ejemplo, para mostrar en pantalla pero omitiendo algunas columnas, usa la entrada dsp132. Te dejaré como tarea revisar la salida para entender la diferencia.

do dsp132^mgstat(5,720,"",60)

Puedes encontrar información detallada sobre las columnas de mgstat en la Guía de monitarización de Caché en la documentación de InterSystems: InterSystems online documentation

Analizando los datos de mgstat

pButtons fue diseñado para compilarse en un único archivo HTML que se pueda navegar y empaquetar fácilmente para enviar a los especialistas del Centro de Soporte Internacional (WRC), que podrán diagnosticar problemas de rendimiento. Sin embargo, cuando ejecutas pButtons por tu cuenta y quieres mostrar los datos gráficamente, puedes volver a separarlos en un archivo csv para convertirlo en un gráfico, por ejemplo con Excel, usando un script de línea de comandos o simplemente cortando y pegando.

En este artículo, profundizaremos solo en algunas de las métricas de mgstat para mostrar como, incluso con un rápido vistazo, podemos hacernos una buena idea sobre si el sistema está funcionando bien, o si hay problemas reales o potenciales que afectarán a la experiencia del usuario.

Glorefs y CPU

El siguiente gráfico muestra el uso de CPU del servidor de la base de datos en un sitio donde se ejecuta una aplicación hospitalaria con una tasa muy elevada de transacciones. Presta atención al pico de actividad de la mañana, cuando hay muchos pacientes externos, con una caída a la hora del almuerzo y un descenso mantenido durante la tarde y labnoche. En este caso, los datos provienen de Windows Performance Monitor (_Total)% Processor Time - la forma del gráfico encaja con el perfil de un día laborable. No hay picos ni "valles" inusuales, lo que es normal para este sitio. Al hacer el mismo análisis para tu sitio, podrás empezar a tener una base de referencia de la actividad "normal". Un pico muy grande, especialmente si es prolongado, puede ser indicativo de un problema. En una publicación futura me enfocaré en el CPU.

Como referencia, este servidor de base de datos es un Dell R720 con dos procesadores E5-2670 de 8 núcleos, el servidor tiene 128 GB de memoria y 48 GB de búferes globales.

El siguiente gráfico muestra más datos de mgstat: Glorefs (referencias globales) o accesos a la base de datos para el mismo día que la gráfica de uso de CPU. Glorefs indica la cantidad de trabajo que se hace para procesar la carga de trabajo actual. Si bien las referencias globales consumen tiempo de CPU, no siempre consumen otros recursos del sistema, como lecturas físicas, por la forma en que Caché usa el recurso compartido de búfer de memoria global.

Como es típico en aplicaciones de Caché, hay una correlación muy fuerte entre Glorefs y uso de CPU.

Otra forma de analizar estos datos de CPU y gloref es decir que reducir las glorefs reducirá el uso de CPU, lo que permitirá el uso de servidores con menos núcleos o escalar más sobre los sistemas existentes. Puede haber formas de reducir las referencias globales si hacemos que la aplicación sea más eficiente. Volveremos a este concepto en otros artículo posteriores.

PhyRds y Rdratio

La forma del gráfico obtenido con los datos de mgstat PhyRds (Physical Reads, lecturas físicas) y Rdratio (Read ratio, tasa de lectura) también puede aportar información sobre qué esperar del rendimiento del sistema y ayudar con la planificación de capacidad. En futuras publicaciones hablaré con más detalle sobre el almacenamiento de entrada y salida para Caché.

PhyRds son simplemente IOPS de lectura física desde el disco a las bases de datos de Caché. Deberías ver los mismos valores reflejados en las métricas del sistema operativo para discos lógicos y físicos. Recuerda al mirar las IOPS del sistema operativo que también podrían estar mostrando IOPS provenientes de aplicaciones que no son de Caché. Dimensionar el almacenamiento y no tener en cuenta las IOPS esperadas es una receta para el desastre. Necesitas conocer las IOPS que tu sistema realiza en horas pico para realizar una adecuada planificación de capacidad. El siguiente gráfico muestra las PhyRds entre la media noche y las 15:30.

Observa el gran salto en lecturas entre las 05:30 y las 10:00. Hay otros picos menores a las 11:00 y justo antes de las 14:00. ¿Qué crees que los causa? ¿Ves este tipo de picos en tus servidores?

Rdratio es un poco más interesante: es la tasa de lectura de bloques lógicos por lectura de bloque físico. Así que es una tasa de cuántas lecturas son de búferes globales (lógicos) desde la memoria y cuántas son del disco, lo que es órdenes de magnitud más lento. Un Rdratio alto es algo bueno. Que caiga cerca de cero por largos períodos no es bueno.

Observa que al mismo tiempo que hay una alta cantidad de lecturas, Rdratio baja a cerca de cero. En este sitio me pidieron investigar cuando el departamento de TI comenzó a recibir llamadas de usuarios que se quejaban de que el sistema se volvía lento por largos períodos. Esto había estado sucediendo al parecer de forma aleatorio desde hacía semanas, y me pidieron analizar el sistema.

Como pButtons había sido programado para ejecutarse diariamente durante 24 horas, fue relativamente sencillo analizar varias semanas de datos para empezar a ver un patrón de PhyRds elevados y bajos Rdratio, correlacionados con las llamadas al soporte técnico.

Tras un mayor análisis, pude rastrear la causa hasta un trabajador por turnos nuevo, que estaba ejecutando varios informes metiendo parámetros "erróneos" junto con consultas mal redactadas, sin los índices adecuados, lo que causaba la elevada cantidad de lecturas a la base de datos. Este era el origen de las ralentizaciones aparentemente aleatorias. Como estos informes que abarcan mucho tiempo leen datos hacia los búferes globales, el resultado es que los datos de usuario interactivos se recuperan del almacenamiento físico en vez de hacerse desde la memoria. Esto ejerce una gran carga sobre el almacenamiento para atender las lecturas.

Supervisar PhyRds y Rdratio te dará una idea del estado de funcionamiento de tus sistemas y quizás te permita encontrar informes o consultas mal realizadas. Podría existir una razón válida para tener un PhyRds alto -- quizás sea necesario ejecutar un informe a cierta hora. Con los servidores y sistemas operativos modernos de 64 bits y su gran capacidad de memoria física, deberías poder minimizar el PhyRds en tus sistemas de producción.

Si observas un PhyRds alto en tu sistema, hay varias estrategias que puedes evaluar:

• Aumentar la cantidad de búferes (globales) de base de datos (y la memoria del sistema) para mejorar el desempeño.
• Mover fuera del horario de oficina la creación de informes o extractos que requieran un largo tiempo.
• Los informes de solo lectura que requieran mucho tiempo, las tareas por lotes y las extracciones de datos pueden ejecutarse en un servidor de shadowing independiente o mirror asíncrono, lo que minimizará el impacto sobre los usuarios interactivos y quitará parte de la carga sobre los recursos del sistema, como CPU e IOPS.

Un PhyRds que normalmente sea bajo es algo bueno, y debe ser nuestro objetivo al dimensionar sistemas. Sin embargo, si tienes un PhyRds bajo y los usuarios se quejan del rendimiento, hay otras cosas que se pueden revisar para asegurarse de que el almacenamiento no sea un cuello de botella - la cantidad de lecturas podría ser baja debido a que el sistema ya no puede dar más servicio. Analizaremos el almacenamiento con mayor profundidad en un artículo posterior.

Resumen

En esta publicación hemos visto que mostrar con gráficos las métricas recogidas en pButtons puede darnos una idea del estado del sistema de un vistazo. En publicaciones futuras, analizaré en mayor profundidad la relación entre el sistema y las métricas de Caché, y cómo se pueden usar para planificar para el futuro.