Quería escribirlo como comentario alartículo de @Evgeny.Shvarov. Pero resultó demasiado largo, así que decidí publicarlo por separado.

Me gustaría añadir una pequeña aclaración sobre cómo utiliza Docker el espacio en disco y como limpiarlo. Yo uso macOS, por lo tanto todo lo que explico aplica principalmente a macOS, pero los comandos de Docker se adaptan a cualquier plataforma.

Cuando Docker se incluye en Linux, por defecto funciona en el mismo sistema de archivos. Pero en Windows y macOS, funciona en una pequeña máquina virtual con su propio Linux dentro. Y el espacio del disco está limitado por mi configuración en Docker. En mi caso, lo configuré para utilizar hasta 112 GB.

Por lo tanto, cuando trabajes de forma activa con Docker, tu espacio interior dejará de usarse. Puedes comprobar como Docker emplea todo ese espacio con el comando:

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              84                  6                   66.02GB             55.6GB (84%)
Containers          6                   5                   4.914GB             0B (0%)
Local Volumes       19                  4                   1.812GB             342.7MB (18%)
Build Cache         0                   0                   0B                  0B

En macOS con las últimas versiones de Docker, se utiliza el formato en bruto del disco (anteriormente era qcow2). Y junto con el sistema de archivos APFS en macOS, este archivo puede ocupar menos espacio físico que el propio tamaño del archivo. Observa estos dos comandos. 

$ ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
-rw-r--r--@ 1 daimor  staff   104G Jul 13 15:49 /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

$ du -h ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
 88G    /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

El comando ls muestra el tamaño de mi archivo Docker.raw como 104Gb, mientras que el comando du muestra el tamaño real en el disco, que es de 88Gb.

Bien, docker system df me mostró que puedo recuperar algo de espacio. Vamos a hacerlo.

$ docker system prune -f
Deleted Containers:
79b3d54ae5a881e37771cfdc1d651db9ce036abc297dc55bdd454eb287f0e329

Deleted Images:
deleted: sha256:298d555976effb112428ed3f6bcc2f4d77ab02b4f287a230d9535001184078f5
deleted: sha256:adb2c64ce6e44d837fce8067c7498574822bff90ed599d1671c126539fe652ac
deleted: sha256:9695172139cec16f1071449daf29bd1c424353044088b92b8acbf33f59952e67
deleted: sha256:24d834b252e25e645b8b5d9194360f5ab1a26ffd2b5c03b6593b9a2c468f59fa
deleted: sha256:1b4e3e73fe0b7d88d5ec718bdc6dc6d17d9fe8ba00988eb72690d76f2da3d1a3
deleted: sha256:9f218f6c7aca9c21760ae43590a2d73b35110e10b6575125ed3ccd12c4495d6e
deleted: sha256:b2fa3335d672a0dc60ea7674c45ee3c85b9fc86584a0e21cc7f1900c368ceec3
deleted: sha256:2ecace396ab65fd393dfb2e330bece974cd952e7a41364352f9c867d9ea4c34e
deleted: sha256:16b894351fe53b95dd43d7437bbbcd5104b8613bc1fa8480826e843d65fc92a3
deleted: sha256:b00d9c05035eac62f3ed99a814cd6feea3e4b68797b6d1203e2f41538c78c2aa
deleted: sha256:5a3d0d9f36b356cb47d3838585da6450c60e2860ef143d1406b48d3a5e72b92b
deleted: sha256:998e719368ff74d13b3a8c096ce81f8f2c4bb28bd1ccd169bfa173b4a78d2e74
deleted: sha256:a74d7ff2ca7d623134f9ce1db40da476134a733935a3f322ba34b99653c6273d
deleted: sha256:4d0dcd2bdad2cf0cb91d13313afff29326771bdac27fcb8780545687dbd39ae4
deleted: sha256:29a8989eed3d4002053f98bf562654910ee5f8836940daaa2f2344a8f29a52a2
deleted: sha256:12d34fbf938d19b193199ea6cce5d690fd0d57ec3f4d1630e1d4b3790379c9ec
deleted: sha256:75aba481bb5ccaa52a3aadf311ae22485fb2a82d69be864fe2f45f2834c5e515
deleted: sha256:326efafee9b92e06876878b21a2931ba771bc0e0b2b359f906ef6cca1d297905
deleted: sha256:913937f4ea932fcb00b6c6b3007970296955aa4f488d6fbaa1a575a5aa4ff5ab
deleted: sha256:f3fc0c75858a36ff9d3f4e8eb7a96f511158bbac92d128760b0d3340d828c5da
deleted: sha256:c002dde1ea6a02ae3e3037442a5c556a925e3e4750a6b2aa923c51fa3d11f5ac
deleted: sha256:e763f6e226613c67aaf5984e4c74b9f6e9e28e0490a4f3286885f498a57d3fa0
deleted: sha256:e7daf0a1574376c8602515dc70e44392d16e1b79013d6e81a9b697794432e660
deleted: sha256:ce33670f78109dcacc73a7c6d70f4b5cd4a13bcfe7878b9df5e4e16b812e5df4
deleted: sha256:95bf79e86f83ed16943f9c34035bf8167a4b89466a05d6793c2957d6d46bab2d
deleted: sha256:056d184391613b33303ccf3818a95a17398e9da813d093a6ee5d87952539380c

Total reclaimed space: 5.537GB

Este comando elimina cualquier contenedor detenido y cualquier imagen no etiquetada que no se esté utilizando por cualquier imagen etiquetada. Y se puede eliminar de forma segura.

Tal vez has notado que solo se recuperaron 5.5 GB, mientras que docker system df hablaba de unos 55 GB. Eso es porque df cuenta todas las imágenes no activas, no solo las activas. Si también quieres eliminar todas esas imágenes, puedes utilizar este comando, lo que elimina cualquier imagen que no se utilice en los contenedores que estén ejecutándose en este momento. Por lo tanto, si no tienes ningún contenedor funcionando, eliminará todas las imágenes locales.

docker system prune -a

Acabo de recuperar solo las imágenes activas y los contenedores detenidos. Cuánto espacio utiliza mi docker ahora.

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              83                  5                   60.48GB             50.1GB (82%)
Containers          5                   5                   4.914GB             0B (0%)
Local Volumes       19                  3                   1.812GB             342.7MB (18%)
Build Cache         0                   0                   0B                  0B

Como puedes ver, ya utiliza menos tamaño. ls mostrará el mismo resultado. El tamaño del archivo principalmente crece.

$ ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
-rw-r--r--@ 1 daimor  staff   104G Jul 13 16:07 /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

Pero para macOS es más importante cuánto espacio se utiliza en un disco físico.

$ du -h ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw
 69G    /Users/daimor/Library/Containers/com.docker.docker/Data/vms/0/Docker.raw

Y como puedes ver ahora son 69 GB, que son aproximadamente 19 GB menos de los que eran anteriormente.

Así que, para los usuarios de macOS, realmente no importa el tamaño del archivo, con las optimizaciones de APFS en realidad puede ser menor.

Otra forma es reducir las imágenes antiguas con algún filtro por fecha de creación. Al igual que este ejemplo, se eliminarán todas las imágenes creadas hace más de 10 días, pero se mantendrán las imágenes que actualmente utilizan los contenedores.

$ docker image prune --all --filter until=240h

Comenzando este año 2023, hemos programado una serie de cursos oficiales sobre InterSystems IRIS que iremos realizando a lo largo del año. Los cursos se impartirán on-line y ya están abiertos para que os podáis registrar si estáis interesados (hasta un máximo de 10 personas por curso, quorum mínimo 5 asistentes). Toda la información está disponible en nuestro sitio web: Formación en el aula virtual | InterSystems

Disclosure Statement: Sugerencias para relalizar pruebas en ambientes usados para demostraciones o desarrollos, no en ambientes productivos.

Caso de uso: teniendo IAM, lo ejecutamos desde un archivo YML, y necesitamos que se conecte a una Instancia IRIS en seguida, pero IRIS tiene deshabilitado el usuario IAM y la aplicación IAM.

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

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

Durante una actualización a una versión principal (major) es aconsejable recompilar las clases y rutinas de todos tus namespaces (ver Tareas tras la instalación de una versión major).

do $system.OBJ.CompileAllNamespaces("u")

do ##Class(%Routine).CompileAllNamespaces()

Para automatizar esta tarea de administración y mantener un registro de cualquier error, os muestro un ejemplo de una clase para importar y compilar en el namespace USER, que puedes usar después de cada actualización: admin.utils.cls

Servir el café: Cómo crear y programar una tarea

¿No te gustaría que una taza de café caliente te esperara justo al llegar a la oficina? ¡Vamos a automatizar eso!

Cache e IRIS incorporan un Administrador de tareas, que debería resultar familiar a quienes estén acostumbrados a utilizar el programador de tareas de Windows o a usar cron en Linux. Tu cuenta de usuario requerirá tener acceso al recurso %Admin_Task para utilizarlo, y puedes acceder a él desde el portal de administración en System Operation -> Task Manager. Cuando se instala por primera vez, hay aproximadamente 20 tipos de tareas que puedes programar.

Si quieres añadir tus propias tareas, empieza creando una clase que extienda %SYS.Task.Definition. Como mínimo, debes sobreescribir el método OnTask, que tiene una firma de Method OnTask() As %Status. El código de ese método se ejecutará cada vez que se lance la tarea. De hecho, si tu tarea arroja "Error #5003: No implementado (Error #5003: Not Implemented)" cada vez que se ejecuta, es porque este método no se sobreescribió correctamente. De manera muy básica, podría ser:

Class User.Pour Extends %SYS.Task.Definition{    Method OnTask() As %Status    {        write "Pour the coffee!",!        quit $$$OK    }}

Una vez que hayas desarrollado esa clase, puedes volver al portal de administración e ir a System Operation -> Task Manager -> New Task. Esta vez, si cambias el Namespace para ejecutar la tarea en el menú desplegable al *namespace* donde creaste esta clase, al hacer clic en el menú desplegable "Task type" y deberías ver tu nueva clase, en este caso User.Pour. También podrás darle a tu tarea un nombre y una descripción. Estos aparecerán en el Task Schedule una vez que hayas programado tu tarea. Elige un usuario con el que se ejecutará la tarea. Este usuario deberá tener los permisos adecuados que le permitan ejecutar cualquier código que se encuentre en el método OnTask.

También deberías indicar que la opción "Abrir el archivo de salida cuando la tarea está en ejecución (Open output file when task is running)" la tengas activada (Sí), y seleccionar un archivo para la salida. Cualquier sentencia en forma escrita o similar en la tarea se escribirá en ese archivo, y como eso es todo lo que hace nuestra tarea, no veremos un gran resultado si no configuramos esta parte.Este archivo se iniciará de nuevo cada día, no se anexará, por lo que solamente verás lo que se escribió desde que se ejecutó su tarea más reciente.  

Haz clic en "Next" para ver las opciones de programación. Verás que se puede ejecutar la tarea de forma automática diariamente, semanalmente, mensualmente (como en "el día 15 de cada mes"), o mensualmente por día (como en "el segundo martes de cada mes"). Las dos últimas opciones son un poco diferentes, ya que no necesariamente ejecutan una tarea a una hora específica programada.

"After another task completes" (Después de que se complete otra tarea) es útil para encadenar varias tareas en un orden determinado. Por ejemplo, una vez que tengamos esta tarea en el horario, podríamos crear una segunda tarea y llamarla "Add the creamer" (Añadir la leche) y cada vez que la tarea "Pour the coffee" (Servir el café) se complete, la tarea "Add the creamer" también se ejecutará, y siempre ocurrirán en ese orden, incluso si por alguna razón Servir el café llevó más tiempo de lo normal un día. Si la tarea Servir el café falla, no se ejecutará la tarea Añadir la leche en polvo.

"On Demand" (A Demanda) no añade la tarea al horario. En su lugar, solo crea una entrada en el portal de administración en System Operation -> Task Manager -> On Demand Task. De hecho, cualquier tarea, incluyendo las del horario, puede ejecutarse cuando se solicita a partir de ahí, o desde el propio Task Schedule. Solo ten en cuenta que cuando se ejecuta una tarea de esta manera, no se ejecuta inmediatamente. Está programada dentro del siguiente minuto.

Cuando hayas configurado tu horario y hayas hecho clic en "Finalizar", ¡felicidades! ¡Has programado tu primera tarea! Si miras el Task Schedule del Administrador de tareas, verás tu tarea en la parte inferior del horaio. En mi caso, he puesto Pour the coffee a las 9 de la mañana (¡sé que dormir hasta tan tarde es un poco extravagante para la mayoría de nosotros!) todos los días de la semana. En los días programados, mi archivo de salida se reescribirá para decir "Pour the coffee!", justo después de las 9:00 AM.

Son las cinco en algún lugar: Cómo crear opciones para tu tarea

¡¿Pero qué sucede a la hora de la salida?! No siempre queremos café. Necesitamos ser capaces de incorporar algunas opciones a nuestra tarea. Cualquier cosa que definas como una propiedad dentro de tu clase de tarea creará un aviso al programar la tarea. Vamos a añadir una propiedad a nuestra tarea y modificar el método OnTask para utilizarla:

Class User.Pour Extends %SYS.Task.Definition{Property Beverage As %String(DISPLAYLIST = ",coffee,bourbon", VALUELIST = ",coffee,bourbon") [ Required ];    Method OnTask() As %Status    {        write "Pour the "_..Beverage_"!",!        quit $$$OK    }}

En este ejemplo, he hecho que mi propiedad fuera una cadena de texto, pero puede ser de cualquier tipo de dato, y el formulario tendrá una entrada para ella. La mayoría de los tipos de datos tendrán de forma predeterminada una entrada de texto sin formato. Los booleanos tendrán una casilla de verificación. Si defines un DISPLAYLIST y un VALUELIST para la propiedad, como en el caso anterior, obtendrás un desplegable como alternativa, pero la primera opción debe estar en blanco o solo mostrará el cuadro de texto de forma predeterminada. Si la propiedad se marca como requerida, el indicador mostrará un * y el usuario no podrá continuar sin proporcionar un valor.

Ahora puedo crear una tarea que escriba "¡Sirve el café!" en un archivo de registro a las 9:00 AM y otra que escriba "¡Sirve el bourbon!" a las 5:00 PM añadiendo el mismo tipo de tarea al horario, pero con una opción diferente.

Mal servicio, 0 estrellas: Gestionando los fallos en las tareas

¡No tenía mi café esta mañana! ¿Qué ha pasado?

Hay un par de formas de comprobar el historial de tareas. Si seleccionas "Task History" (Historial de tareas) en el menú del Administrador de tareas del portal de administración, obtienes una lista cronológica y combinada con el historial de todas las tareas. Si vas a Task Schedule y haces clic en "History" (Historial), a la derecha de la tarea que te interesa, puedes ver el historial solo para esa tarea en particular. Allí podrás ver cualquier error.

También puedes ser más previsor y evitar las reseñas negativas en internet. Vuelve a tu Portal de administración y selecciona System Administration -> Additional Settings -> Task Manager Email. En esa sección puedes configurar los ajustes del correo electrónico de salida para recibir las notificaciones del Administrador de tareas. La configuración de SMTP está fuera del alcance de este artículo, pero deberías poder obtenerla de tu administrador de correo electrónico. Puedes fijar frases como asunto y mensajes tanto para el éxito como para el fracaso. No podrás crear un conjunto diferente de ajustes por tarea, pero en la parte inferior puedes ver una lista de variables que puedes incluir en tus correos electrónicos para proporcionar la información que necesitas. Los valores predeterminados proporcionan toda la información que normalmente se necesita.

Ahora, vamos a programar una tarea otra vez. En la parte inferior, aparecen los campos que no estaban antes si no se había configurado el SMTP. "Send completion email notification to" (Enviar notificación para completar la tarea) es donde se pone la dirección de correo electrónico a la que se enviará el mensaje cuando la tarea se complete correctamente. "Send error email notification to" (Enviar notificación de error por correo electrónico a) es donde se envía una notificación por correo electrónico cuando la tarea no se completa correctamente. Si eligió un archivo de salida, ese archivo también se adjuntará a las notificaciones por correo electrónico.

Vamos a hacer una pausa aquí para añadir claridad. Cuando manejemos esta configuración, "Error" significa que la tarea se ejecutó por completo, pero el método OnTask devolvió un estado de error. Todos los ajustes en la página de configuración de la tarea que se refieren al error o al éxito utilizan esa definición. Si el método OnTask devuelve un estado de error, se enviará el correo electrónico de notificación de error, y si "Suspend task on error?" (¿Suspender la tarea en caso de error?) se fijó en sí, la tarea se suspenderá hasta que le indiques que se reanude. Eso no se debe confundir con un error en el que un defecto en el método OnTask impidió que se completara. En ese tipo de error, no se enviarán notificaciones por correo electrónico y la tarea siempre se suspenderá. Debido a esto, ¡ten mucho cuidado con la forma de manejar los errores!

También hay una casilla desplegable para "Reschedule task after system restart?" (¿Reprogramar la tarea después de reiniciar el sistema?)" Esta opción determina cómo el sistema gestiona las tareas que debían ejecutarse, pero el sistema no funcionaba en ese momento. Si se establece en "No", la ejecución particular de la tarea solo se perderá y se reanudará de forma normal la siguiente vez que deba ejecutarse. Si se establece en "Sí" y la tarea se debería ejecutar mientras el sistema está inactivo, la tarea se ejecutará poco después de que el sistema se reinicie.

¡Pero es IMPORTANTE!: Esa opción que hemos ignorado

Prioridad Normal. Hazlo.

En realidad, eso es lo que querrás la gran mayoría de las veces. La Configuración Task Priority (Prioridad de Tareas) tiene que ver con la forma en que varios procesos compiten por los recursos de tu servidor cuando está ocupado, y rara vez querrás cambiarla. Si te preocupa tener la CPU con un porcentaje cercano al 99% todo el día y quieres que la tarea reciba una prioridad más alta o más baja que otras tareas que se llevan a cabo, puedes cambiar esta configuración para determinar cómo solucionar ese problema, pero humildemente te aviso que cambiar esta configuración no resuelve el verdadero problema.

¡Eso es todo! En este caso, mantuve mi método OnTask muy básico para mantener el foco en el uso real del administrador de tareas y la clase %SYS.Task.Definition, pero puedes poner lo que quieras allí. De este modo, podrás automatizar una gran cantidad de trabajo. Por ejemplo, en nuestros servidores, tenemos un servicio alojado en Tomcat que imprime, envía por correo electrónico y/o archiva Crystal Reports, y automatizamos un %Net.HttpRequest para llamar a ese proceso. Puedes programar cualquier cosa que puedas escribir en un método. Si se te ocurre alguna buena idea o tienes algún ejemplo, compártalo en los comentarios.

¡Hola desarrolladores!

Nos complace anunciaros que vamos a ofrecer una convocatoria gratuita para un examen de certificaciónde InterSystems a todas las personas inscritas en el Global Summit 2022. El precio habitual de estos exámenes es de 150$ por examen.

Los exámenes deberán realizarse durante una de las 7 sesiones vigiladas que habrá durante la Convención.

De vez en cuando, recibimos la pregunta anterior en soporte, algo o alguien está usando más licencias de las esperadas y necesitamos encontrar qué está pasando.

Tenemos dos escenarios. El primer escenario es cuando nos damos cuenta que las licencias están agotadas porque la aplicación no funciona o porque intentamos conectarnos a través del terminal y sale el "encantador" mensaje <LICENSE LIMIT EXCEEDED>: 

Encontré este pequeño artículo de @Brendan Bannon de hace unos años... pero creo que es muy útil para cuando tengamos estructuras de almacenamiento basadas puramente en globals y queramos tener la posibilidad de acceder a ellas desde el punto de vista de Objetos y/o Relacional.

El fichero ZIP adjunto contiene un paquete de ejemplos de mapeos SQL Storage (válido para IRIS y Caché) que he hecho y recopilado a lo largo de estos años.

El Programador de Ensemble se utiliza para encender y apagar automáticamente los hosts en determinadas fechas y horas. Podrías usarlo si, por ejemplo, solo quisieras ejecutar un host de negocios de 9:00 a 17:00 todos los días. Por el contrario, si desea activar un evento para que ocurra en un momento específico, por ejemplo, un trabajo que se ejecuta a la 01:00, para agrupar y enviar todas las transacciones del día anterior en un archivo, recomendamos otros métodos como el Administrador de tareas.  

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

Esta vez quiero hablar de algo que no es específico de InterSystems IRIS, pero que creo que es importante si quieres trabajar con Docker y tu máquina de trabajo es un PC o portátil con Windows 10 Pro o Enterprise.

Como probablemente sabes la tecnología de contenedores viene básicamente del mundo Linux y, a día de hoy, es en los hosts que corren Linux donde pueden mostrar su máximo potencial. Los que usamos Windows vemos que tanto Microsoft como Docker han hecho grandes esfuerzos estos últimos años y nos permiten correr contenedores Linux en nuestro sistema Windows de una manera muy sencilla... pero no está soportado para entornos productivos y, aquí viene el gran problema, no es fiable si queremos mantener persistencia de datos fuera del contenedor, en el sistema host,...  debido principalmente a las importantes diferencias entre los sistema de archivos de Windows y Linux. Al final el propio Docker for Windows utiliza una pequeña máquina Linux virtual (MobiLinux) sobre la que realmente se levantan los contenedores.... lo hace de forma transparente para el usuario de windows... y de hecho funciona muy bien hasta que, como digo, quieren hacer que tus bases de datos sobrevivan más allá de la vida del contenedor...

En fin,... que me enrollo,... el caso es que muchas veces, para evitar problemas y simplificar, lo que se precisa es de un sistema Linux completo... y, si nuestra máquina es Windows, la única forma de tenerlo es vía una máquina virtual. Al menos hasta que salga WSL2 en Windows 10 en unos meses, pero eso es otra historia.

En este artículo te voy a contar, paso a paso, como instalar un entorno en el que puedas trabajar con contenedores Docker sobre un Ubuntu en tu servidor Windows. Vamós allá...

Si trabajas utilizando el Portal de Gestión con varias instancias de IRIS, es posible que te resulte útil establecer el Modo del Sistema de esas instancias, de forma que tengas un recordatorio visual acerca del tipo de instancia con la que estás trabajando.

Por ejemplo:

or:

or:

or:

Esta configuración se establece aquí:

Y la funcionalidad se menciona aquí en la documentación.

Internamente esta configuración se almacena en la global ^%SYS("SystemMode") y tiene como posibles valores: LIVE, TEST, DEVELOPMENT, FAILOVER.

Puede obtenerse este valor también utilizando $SYSTEM.Version.SystemMode(), de forma que es posible hacer que tu aplicación se comporte de forma diferente en función del modo de sistema configurado en la instancia.

Además, si estableces un valor propio en la global ^%SYS("SystemMode") puedes conseguir que el título del Portal de Gestión contenga un mensaje no-estándar personalizado. Por ejemplo:

Sin embargo, si utilizas esta opción personalizada, ten en cuenta que si alguien modifica el System Mode en la página de Memory and Startup se perderá tu opción personalizada.

El equipo de documentación en el departamento de Servicios de Formación de InterSystems se complace en anunciar la nueva Guía de Migración del Servidor de InterSystems IRIS

¿Alguna vez has querido copiar, mover o clonar una instancia de InterSystems IRIS a un nuevo servidor? Quizá el sistema operativo en el antiguo servidor ya no está soportado. O quizá quieres añadir un nuevo miembro a un mirror existente. Migrar las bases de datos de tu aplicación es fácil, pero... ¿qué pasa con tus tareas, usuarios, roles, recursos y otras configuraciones de seguridad? ¿Qué necesitas para migrar y cuál es la mejor forma de hacerlo?

Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros.

En el Centro de Soporte Internacional (WRC), con frecuencia los clientes se ponen en contacto con nosotros porque su Web Gateway no puede publicar páginas web. En este artículo explicaré el motivo más frecuente por el que pueden producirse estos errores; y también explicaré algunas herramientas que se pueden utilizar para solucionar el problema. Esta explicación se centra en el Web Gateway que enlaza con las instancias de InterSystems IRIS, pero la misma explicación debería aplicar también a la CSP Gateway que enlaza con instancias de Caché.

El problema:

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.

Prometheus es uno de los sistemas de monitorización adaptado para recoger datos de series temporales.

Su instalación y configuración inicial son relativamente sencillos. El sistema tiene un subsistema gráfico integrado llamado PromDash para la visualización de datos, pero los desarrolladores recomiendan usar un producto de otro proveedor, llamado Grafana. Prometheus puede monitorizar muchas cosas (hardware, contenedores, distintos sistemas de gestión de base de datos), pero en este artículo me gustaría analizar la monitorización de una instancia de Caché (para ser exactos, será una instancia de Ensemble, pero las métricas serán de Caché). Si te interesa, sigue leyendo.

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.

En los recientes trabajos de benchmarking a gran escala, observamos un tiempo excesivo de uso del CPU %sys que afectó negativamente en la escalabilidad de la aplicación.

Problema

Encontramos que gran parte del tiempo se pasó llamando a la llamada localtime() del sistema, debido a que la variable de entorno TZ no estaba configurada. Se creó una rutina de prueba sencilla para confirmar la observación, y las diferencias entre el tiempo transcurrido y los recursos que necesitó la CPU con la variable TZ vs. cuando TZ no estaba establecida, fueron extraordinarios. Se descubrió que el uso hereditario de las llamadas stat() de sistema hacia /etc/local_time desde localtime() es muy costoso cuando la variable TZ no está establecida.

Recomendación

InterSystems recomienda encarecidamente que se confirme en cualquier sistema que tenga Linux instalado, ya sea en x86 o Linux on Power, que la variable de entorno TZ está configurada adecuadamente, para obtener un rendimiento óptimo. Para más información, consulta: "man tzset".

La versión de prueba de Caché 2016.1 contiene optimizaciones relacionadas con las funciones de fecha y hora, y las pruebas iniciales indican importantes mejoras. A continuación, se muestran ejemplos de salidas, resultado de probar las nuevas llamadas a funciones internas en un bucle con Linux on Power, donde en ambos casos TZ *no* se establece:

Antes de Caché 2016.1 FT:

real	0m22.60suser	0m1.64ssys	0m20.89s

Con Caché 2016.1 FT:

real	0m0.40s
user	0m0.37s
sys	0m0.00s

Publica tus comentarios sobre cualquier experiencia que hayas tenido con tu aplicación, relacionada con la variable de entorno TZ, y también sobre el impacto que la versión de prueba de Caché 2016.1 tiene con o sin la variable TZ definida.

Causado por un conflicto en la asignación del puerto, obtengo esta entrada en messages.log y SMS ya no responde:

La primera línea es correcta,
La segunda es solo ilusión.  "Fake News"

¿Cómo puedo reiniciar mi servidor SMP sin una secuencia de reinicio / parada completa de IRIS? 

¿Principalmente en WINDOWS?

¡Hola Comunidad!

Las empresas necesitan crecer y administrar sus infraestructuras informáticas globales de forma rápida y eficiente, al mismo tiempo que optimizan y administran la manera en que invierten y gastan sus fondos. Los servicios de computación y de almacenamiento de Amazon Web Services (AWS) y Elastic Compute Cloud (EC2) satisfacen las necesidades de las aplicaciones más exigentes basadas en InterSystems IRIS, al proporcionar una infraestructura informática global sumamente sólida.

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.

Hola a todos,

con este artículo, me gustaría mostrar lo fácil y dinámicamente que puede ser configurada nuestra herramienta de Alerta y Monitorización de Sistema (SAM, del inglés System Alerting and Monitoring). El caso de uso podría ser el de un flujo de aprovisionamiento CI/CD ágil y rápido, donde queráis ejecutar vuestros tests unitarios y de estrés, y podáis ver rápidamente si los tests tuvieron éxito o cómo están estresando el sistema y tu aplicación ( el API de SAM en el backend de InterSystems IRIS es extensible para tu implementación APM). 

Introducción

Ya está disponible la primera versión oficial (v1.0) de InterSystems System Alerting and Monitoring (InterSystems SAM)  InterSystems SAM v1.0 proporciona una solución moderna de monitorización para productos basados en InterSystems IRIS. Permite vistas a alto nivel de grupos de instancias (clusters) así como la visualización de métricas bajando al nivel de nodos individuales, todo ello junto con la notificación de alertas. Esta primera versión permite visualizar más de 100 métricas del kernel de InterSystems IRIS, y los usuarios pueden extender la plantilla de Grafana que se incluye por

Ya están disponibles las versiones de prueba de la primera versión (v1.0) del Sistema de Alerta y Monitorización de InterSystems (SAM, System Alerting and Monitoring).
  
InterSystems SAM v1.0 ofrece una moderna solución de monitorización para los productos que tienen como base IRIS de InterSystems. Permite vistas de alto nivel de clústeres y visualización de métricas desglosadas de nodo único, junto con notificaciones de alertas. La primera versión ofrece visualización para más de cien métricas del kernel de InterSystems IRIS, y los usuarios pueden extender a su criterio la plantilla de Grafana ofrecida por defecto.

Hola Comunidad:

Esta publicación está dedicada a la tarea de supervisar una instancia de Caché usando SNMP. Algunos usuarios de Caché probablemente ya lo hacen de una u otra forma. Hace ya mucho que el paquete de Caché estándar soporta la supervisión por SNMP, pero no todos los parámetros necesarios vienen "listos para usar". Por ejemplo, sería bueno poder supervisar el número de sesiones CSP, obtener información detallada sobre el uso de la licencia, KPI particulares del sistema en uso, etc. Después de leer este artículo, sabrás cómo agregar tus parámetros a la supervisión de Caché mediante SNMP.