As versões de manutenção 2024.1.4 e 2023.1.6 da plataforma de dados InterSystems IRIS^® , InterSystems IRIS^® for Health^TM, e HealthShare^® Health Connect agora estão disponíveis para o público em geral (GA). Essas versões incluem as correções para o seguinte alerta emitido recentemente - Alerta: Queries SQL retornando resultados errados | InterSystems. Compartilhe seu feedback por meio da Comunidade de Desenvolvedores e assim construímos um produto melhor juntos. 

Documentação

Você pode encontrar as listas de alterações detalhadas e listas de verificação de atualizações nestas páginas:

Sei que pessoas completamente novas no VS Code, Git, Docker, FHIR e outras ferramentas podem, às vezes, ter dificuldades com a configuração do ambiente. Por isso, decidi escrever um artigo que percorre todo o processo de configuração passo a passo para facilitar o início.

Eu realmente agradeceria se você pudesse deixar um comentário no final – me diga se as instruções foram claras, se algo ficou faltando ou se há mais alguma coisa que você acharia útil.

A configuração inclui:

✅ VS Code – Editor de código
✅ Git – Sistema de controle de versão
✅ Docker – Executa uma instância do IRIS for Health Community
✅ Extensão REST Client do VS Code – Para executar consultas à API FHIR
✅ Python – Para escrever scripts baseados em FHIR
✅ Jupyter Notebooks –Para tarefas de IA e FHIR

Antes de começar: Certifique-se de ter privilégios de administrador no seu sistema.

Além de ler o guia, você também pode seguir os passos nos vídeos:

Para Windows

Olá Comunidade,

Aproveite o novo vídeo no canal InterSystems Developers YouTube:

⏯ Introdução à Plataforma OMOP 

Rubrica de Perguntas Frequentes (FAQ) da InterSystems

As configurações padrão para Stay Connected e Pool Size para hosts de negócios que usam o adaptador TCP são as seguintes:

No artigo anterior, apresentamos o aplicativo d[IA]gnosis, desenvolvido para auxiliar na codificação de diagnósticos na CID-10. Neste artigo, veremos como o InterSystems IRIS for Health nos fornece as ferramentas necessárias para a geração de vetores a partir da lista de códigos da CID-10, usando um modelo de linguagem pré-treinado, seu armazenamento e a subsequente busca por similaridades em todos esses vetores gerados.

Introdução

Resumo de Alertas

Detalhes dos Alertas

DP-439207 - Problemas no Parser JSON Unicode em AIX

Olá Comunidade! 

Animados com as novidades disponibilizadas na versão mais recente dos produtos InterSystems IRIS, InterSystems IRIS for Health, and HealthShare Health Connect ? 

A versão 2025.1 dos produtos está cheia de novidades incluindo melhorias na tela de Configuração da Produção e no Editor DTL.

Frequentemente, clientes, fornecedores ou equipes internas me pedem para explicar o planejamento de capacidade de CPU para para grandes bancos de dados de produção rodando no VMware vSphere.

Em resumo, existem algumas práticas recomendadas simples a seguir para dimensionar a CPU para grandes bancos de dados de produção:

• Planeje um vCPU por núcleo de CPU físico.
• Considere o NUMA e, idealmente, dimensione as VMs para manter a CPU e a memória locais para um nó NUMA.
• Dimensione as máquinas virtuais corretamente. Adicione vCPUs apenas quando necessário.

Geralmente, isso leva a algumas perguntas comuns:

• Devido ao hyper-threading, o VMware me permite criar VMs com o dobro do número de CPUs físicas. Isso não dobra a capacidade? Não devo criar VMs com o máximo de CPUs possível?
• O que é um nó NUMA? Devo me preocupar com o NUMA?
• As VMs devem ser dimensionadas corretamente, mas como sei quando estão?

Respondo a estas perguntas com exemplos abaixo. Mas também lembre-se, as melhores práticas não são imutáveis. Às vezes, você precisa fazer concessões. Por exemplo, é provável que grandes VMs de banco de dados de produção NÃO caibam em um nó NUMA e, como veremos, isso está OK. As melhores práticas são diretrizes que você terá que avaliar e validar para seus aplicativos e ambiente.~

Embora eu esteja escrevendo isso com exemplos para bancos de dados rodando em plataformas de dados InterSystems, os conceitos e regras se aplicam geralmente ao planejamento de capacidade e desempenho para qualquer VM grande (Monstro).

#VMs Monstruosas

Este post é principalmente sobre a implantação de _VMs Monstruosas _, às vezes chamadas de VMs Largas. Os requisitos de recursos de CPU de bancos de dados de alta transação significam que eles são frequentemente implantados em VMs Monstruosas.

Uma VM monstruosa é uma VM com mais CPUs virtuais ou memória do que um nó NUMA físico.

A arquitetura de processador Intel atual possui arquitetura de Memória de Acesso Não Uniforme (NUMA). Por exemplo, os servidores que estou usando para executar testes para este post têm:

• Dois sockets de CPU, cada um com um processador de 12 núcleos (Intel E5-2680 v3).
• 256 GB de memória (16 x 16GB RDIMM)

Cada processador de 12 núcleos tem sua própria memória local (128 GB de RDIMMs e cache local) e também pode acessar a memória em outros processadores no mesmo host. Os pacotes de 12 núcleos de CPU, cache de CPU e 128 GB de memória RDIMM são um nó NUMA. Para acessar a memória em outro processador, os nós NUMA são conectados por uma interconexão rápida.

Processos em execução em um processador que acessam a memória RDIMM e Cache local têm menor latência do que atravessar a interconexão para acessar a memória remota em outro processador. O acesso através da interconexão aumenta a latência, então o desempenho não é uniforme. O mesmo design se aplica a servidores com mais de dois sockets. Um servidor Intel de quatro sockets tem quatro nós NUMA.

O ESXi entende o NUMA físico e o agendador de CPU do ESXi é projetado para otimizar o desempenho em sistemas NUMA. Uma das maneiras pelas quais o ESXi maximiza o desempenho é criar localidade de dados em um nó NUMA físico. Em nosso exemplo, se você tiver uma VM com 12 vCPUs e menos de 128 GB de memória, o ESXi atribuirá essa VM para ser executada em um dos nós NUMA físicos. O que leva à regra;

Se possível, dimensione as VMs para manter a CPU e a memória locais em um nó NUMA.

Se você precisar de uma VM Monstruosa maior que um nó NUMA, está OK, o ESXi faz um trabalho muito bom calculando e gerenciando automaticamente os requisitos. Por exemplo, o ESXi criará nós NUMA virtuais (vNUMA) que agendam de forma inteligente nos nós NUMA físicos para um desempenho ideal. A estrutura vNUMA é exposta ao sistema operacional. Por exemplo, se você tiver um servidor host com dois processadores de 12 núcleos e uma VM com 16 vCPUs, o ESXi pode usar oito núcleos físicos em cada um dos dois processadores para agendar vCPUs da VM, o sistema operacional (Linux ou Windows) verá dois nós NUMA.

Também é importante dimensionar corretamente suas VMs e não alocar mais recursos do que o necessário, pois isso pode levar a recursos desperdiçados e perda de desempenho. Além de ajudar a dimensionar para NUMA, é mais eficiente e resultará em melhor desempenho ter uma VM de 12 vCPUs com alta (mas segura) utilização de CPU do que uma VM de 24 vCPUs com utilização de CPU de VM baixa ou mediana, especialmente se houver outras VMs neste host precisando ser agendadas e competindo por recursos. Isso também reforça a regra;

Dimensione as máquinas virtuais corretamente.

Nota: Existem diferenças entre as implementações NUMA da Intel e da AMD. A AMD tem múltiplos nós NUMA por processador. Já faz um tempo desde que vi processadores AMD em um servidor de cliente, mas se você os tiver, revise o layout NUMA como parte do seu planejamento.

Para o melhor agendamento NUMA, configure VMs largas; Correção Junho de 2017: Configure VMs com 1 vCPU por socket. Por exemplo, por padrão, uma VM com 24 vCPUs deve ser configurada como 24 sockets de CPU, cada um com um núcleo.

Siga as regras de melhores práticas do VMware..

Consulte este post nos blogs do VMware para exemplos. 

O post do blog do VMware entra em detalhes, mas o autor, Mark Achtemichuk, recomenda as seguintes regras práticas:

• Embora existam muitas configurações avançadas de vNUMA, apenas em casos raros elas precisam ser alteradas dos padrões.
• Sempre configure a contagem de vCPU da máquina virtual para ser refletida como Núcleos por Socket, até que você exceda a contagem de núcleos físicos de um único nó NUMA físico.
• Quando você precisar configurar mais vCPUs do que há núcleos físicos no nó NUMA, divida uniformemente a contagem de vCPU pelo número mínimo de nós NUMA.
• Não atribua um número ímpar de vCPUs quando o tamanho da sua máquina virtual exceder um nó NUMA físico.
• Não habilite o Hot Add de vCPU a menos que você esteja OK com o vNUMA sendo desabilitado.
• Não crie uma VM maior que o número total de núcleos físicos do seu host.t.

O licenciamento do Caché conta núcleos, então isso não é um problema, no entanto, para software ou bancos de dados diferentes do Caché, especificar que uma VM tem 24 sockets pode fazer diferença para o licenciamento de software, então você deve verificar com os fornecedores.

Hyper-threading (HT) frequentemente surge em discussões, e ouço: "hyper-threading dobra o número de núcleos de CPU". O que, obviamente, no nível físico, não pode acontecer — você tem tantos núcleos físicos quanto possui. O Hyper-threading deve ser habilitado e aumentará o desempenho do sistema. A expectativa é talvez um aumento de 20% ou mais no desempenho do aplicativo, mas a quantidade real depende do aplicativo e da carga de trabalho. Mas certamente não o dobro.

Como postei no post de melhores práticas do VMware, um bom ponto de partida para dimensionar grandes VMs de banco de dados de produção ié assumir que o vCPU tem dedicação total de núcleo físico no servidor — basicamente ignore o hyper-threading ao planejar a capacidade. Por exemplo;

Para um servidor host de 24 núcleos, planeje um total de até 24 vCPUs para VMs de banco de dados de produção, sabendo que pode haver folga disponível.

Após dedicar tempo monitorando o desempenho da aplicação, do sistema operacional e do VMware durante os horários de pico de processamento, você pode decidir se uma consolidação de VMs mais alta é possível. Na postagem de melhores práticas, eu estabeleci a regra como;

Um CPU físico (inclui hyper-threading) = Um vCPU (inclui hyper-threading).

O HT em processadores Intel Xeon é uma forma de criar dois CPUs _lógicos _ CPUsem um núcleo físico. O sistema operacional pode agendar eficientemente nos dois processadores lógicos — se um processo ou thread em um processador lógico estiver esperando, por exemplo, por E/S, os recursos do CPU físico podem ser usados pelo outro processador lógico Apenas um processador lógico pode estar progredindo em qualquer ponto no tempo, então, embora o núcleo físico seja utilizado de forma mais eficiente, o desempenho não é dobrado.

Com o HT habilitado na BIOS do host, ao criar uma VM, você pode configurar um vCPU por processador lógico HT. Por exemplo, em um servidor de 24 núcleos físicos com HT habilitado, você pode criar uma VM com até 48 vCPUs. O agendador de CPU do ESXi otimizará o processamento executando os processos das VMs em núcleos físicos separados primeiro (enquanto ainda considera o NUMA). Eu exploro mais adiante na postagem se alocar mais vCPUs do que núcleos físicos em uma VM de banco de dados "Monster" ajuda no escalonamento.

Co-stop e agendamento de CPU

Após monitorar o desempenho do host e da aplicação, você pode decidir que algum sobrecomprometimento dos recursos de CPU do host é possível. Se esta é uma boa ideia dependerá muito das aplicações e cargas de trabalho. Uma compreensão do agendador e uma métrica chave para monitorar podem ajudá-lo a ter certeza de que você não está sobrecomprometendo os recursos do host.

Às vezes ouço; para que uma VM progrida, deve haver o mesmo número de CPUs lógicos livres que vCPUs na VM. Por exemplo, uma VM de 12 vCPUs deve 'esperar' que 12 CPUs lógicos estejam 'disponíveis' antes que a execução progrida. No entanto, deve-se notar que, no ESXi após a versão 3, este não é o caso. O ESXi usa co-agendamento relaxado para CPU para melhor desempenho da aplicação.

Como múltiplos threads ou processos cooperativos frequentemente se sincronizam uns com os outros, não agendá-los juntos pode aumentar a latência em suas operações. Por exemplo, um thread esperando para ser agendado por outro thread em um loop de espera ocupada (spin loop). Para melhor desempenho, o ESXi tenta agendar o máximo possível de vCPUs irmãs juntas. Mas o agendador de CPU pode agendar vCPUs de forma flexível quando há múltiplas VMs competindo por recursos de CPU em um ambiente consolidado. Se houver muita diferença de tempo, enquanto algumas vCPUs progridem e outras irmãs não (a diferença de tempo é chamada de skew), então a vCPU líder decidirá se interrompe a si mesma (co-stop). Observe que são as vCPUs que fazem co-stop (ou co-start), não a VM inteira. Isso funciona muito bem mesmo quando há algum sobrecomprometimento de recursos, no entanto, como você esperaria; muito sobrecomprometimento de recursos de CPU inevitavelmente impactará o desempenho. Mostro um exemplo de sobrecomprometimento e co-stop mais adiante no Exemplo 2.

Lembre-se que não é uma corrida direta por recursos de CPU entre VMs; o trabalho do agendador de CPU do ESXi é garantir que políticas como shares de CPU, reservas e limites sejam seguidas, maximizando a utilização da CPU e garantindo justiça, throughput, responsividade e escalabilidade. Uma discussão sobre o uso de reservas e shares para priorizar cargas de trabalho de produção está além do escopo desta postagem e depende da sua aplicação e mix de cargas de trabalho. Posso revisitar isso em um momento posterior se encontrar alguma recomendação específica do Caché. Existem muitos fatores que entram em jogo com o agendador de CPU, esta seção apenas arranha a superfície. Para um mergulho profundo, consulte o white paper da VMware e outros links nas referências no final da postagem.

Para ilustrar as diferentes configurações de vCPU, executei uma série de benchmarks usando um aplicativo de Sistema de Informação Hospitalar baseado em navegador com alta taxa de transações. Um conceito semelhante ao benchmark de banco de dados DVD Store desenvolvido pela VMware.

Os scripts para o benchmark são criados com base em observações e métricas de implementações hospitalares reais e incluem fluxos de trabalho, transações e componentes de alto uso que utilizam os maiores recursos do sistema. VMs de driver em outros hosts simulam sessões web (usuários) executando scripts com dados de entrada aleatórios em taxas de transação de fluxo de trabalho definidas. Um benchmark com uma taxa de 1x é a linha de base. As taxas podem ser aumentadas e diminuídas em incrementos.

Juntamente com as métricas do banco de dados e do sistema operacional, uma boa métrica para avaliar o desempenho da VM do banco de dados do benchmark é o tempo de resposta do componente (que também pode ser uma transação) medido no servidor. Um exemplo de um componente é parte de uma tela do usuário final. Um aumento no tempo de resposta do componente significa que os usuários começariam a ver uma mudança para pior no tempo de resposta do aplicativo. Um sistema de banco de dados com bom desempenho deve fornecer alto desempenho consistente para os usuários finais. Nos gráficos a seguir, estou medindo em relação ao desempenho consistente do teste e uma indicação da experiência do usuário final, calculando a média do tempo de resposta dos 10 componentes de alto uso mais lentos. O tempo de resposta médio do componente deve ser inferior a um segundo, uma tela de usuário pode ser composta por um componente, ou telas complexas podem ter muitos componentes.

Lembre-se de que você sempre está dimensionando para a carga de trabalho máxima, mais um buffer para picos inesperados de atividade. Geralmente, busco uma utilização média de 80% da CPU no pico.

Uma lista completa do hardware e software do benchmark está no final da postagem.

É possível criar uma VM de banco de dados dimensionada para usar todos os núcleos físicos de um servidor host, por exemplo, uma VM de 24 vCPUs em um host de 24 núcleos físicos. Em vez de executar o servidor "bare-metal" em um espelho de banco de dados Caché para alta disponibilidade (HA) ou introduzir a complicação do clustering de failover do sistema operacional, a VM do banco de dados é incluída em um cluster vSphere para gerenciamento e HA, por exemplo, DRS e VMware HA.

Tenho visto clientes seguirem o pensamento da velha guarda e dimensionarem uma VM de banco de dados primária para a capacidade esperada no final da vida útil de cinco anos do hardware, mas como sabemos acima, é melhor dimensionar corretamente; você obterá melhor desempenho e consolidação se suas VMs não forem superdimensionadas e o gerenciamento de HA será mais fácil; pense em Tetris se houver manutenção ou falha do host e a VM monstro do banco de dados tiver que migrar ou reiniciar em outro host. Se a taxa de transações for prevista para aumentar significativamente, os vCPUs podem ser adicionados antecipadamente durante a manutenção planejada.

Observação, a opção de 'adicionar a quente' (hot add) de CPU desativa o vNUMA, portanto, não a use para VMs monstro.

Considere o seguinte gráfico mostrando uma série de testes no host de 24 núcleos. A taxa de transações 3x é o ponto ideal e a meta de planejamento de capacidade para este sistema de 24 núcleos.

• Uma única VM está sendo executada no host.
• Quatro tamanhos de VM foram usados para mostrar o desempenho em 12, 24, 36 e 48 vCPUs.
• Taxas de transação (1x, 2x, 3x, 4x, 5x) foram executadas para cada tamanho de VM (se possível).
• O desempenho/experiência do usuário é mostrado como o tempo de resposta do componente (barras).
• Utilização média da CPU% na VM convidada (linhas).
• A utilização da CPU do host atingiu 100% (linha tracejada vermelha) na taxa de 4x para todos os tamanhos de VM.

Há muita coisa acontecendo neste gráfico, mas podemos nos concentrar em algumas coisas interessantes.

• A VM com 24 vCPUs (laranja) escalou suavemente para a taxa de transação alvo de 3x. Com a taxa de 3x, a VM convidada está com uma média de 76% de CPU (picos foram em torno de 91%). A utilização da CPU do host não é muito maior do que a da VM convidada. O tempo de resposta do componente é praticamente plano até 3x, então os usuários estão satisfeitos. Quanto à nossa taxa de transação alvo — esta VM está dimensionada corretamente.

Então, chega de dimensionamento correto, e quanto a aumentar as vCPUs, o que significa usar hyper threads? É possível dobrar o desempenho e a escalabilidade? A resposta curta é Não!

Neste caso, a resposta pode ser vista observando o tempo de resposta do componente a partir de 4x. Embora o desempenho seja "melhor" com mais núcleos lógicos (vCPUs) alocados, ele ainda não é plano e consistente como era até 3x. Os usuários relatarão tempos de resposta mais lentos em 4x, independentemente de quantas vCPUs forem alocadas. Lembre-se que em 4x o _host _ já está no limite, com 100% de utilização da CPU, conforme relatado pelo vSphere. Em contagens de vCPU mais altas, mesmo que as métricas de CPU do convidado (vmstat) estejam relatando menos de 100% de utilização, esse não é o caso para os recursos físicos. Lembre-se que o sistema operacional convidado não sabe que está virtualizado e está apenas relatando os recursos apresentados a ele. Observe também que o sistema operacional convidado não vê threads HT, todas as vCPUs são apresentadas como núcleos físicos.

O ponto é que os processos do banco de dados (existem mais de 200 processos Caché na taxa de transação 3x) estão muito ocupados e fazem um uso muito eficiente dos processadores, não há muita folga para os processadores lógicos agendarem mais trabalho ou consolidarem mais VMs neste host. Por exemplo, grande parte do processamento do Caché está ocorrendo na memória, então não há muita espera por IO. Portanto, embora você possa alocar mais vCPUs do que núcleos físicos, não há muito a ganhar porque o host já está 100% utilizado.

Caché é muito bom em lidar com altas cargas de trabalho. Mesmo quando o host e a VM estão com 100% de utilização da CPU, o aplicativo ainda está em execução e a taxa de transações ainda está aumentando — o escalonamento não é linear e, como podemos ver, os tempos de resposta estão ficando mais longos e a experiência do usuário sofrerá — mas o aplicativo não "cai de um penhasco" e, embora não seja um bom lugar para se estar, os usuários ainda podem trabalhar. Se você tiver um aplicativo que não é tão sensível aos tempos de resposta, é bom saber que você pode empurrar até o limite, e além, e o Caché ainda funciona com segurança.

Lembre-se de que você não deseja executar sua VM de banco de dados ou seu host com 100% de utilização da CPU. Você precisa de capacidade para picos inesperados e crescimento na VM, e o hipervisor ESXi precisa de recursos para todas as atividades de rede, armazenamento e outras que realiza.

Eu sempre planejo para picos de 80% de utilização da CPU. Mesmo assim, dimensionar a vCPU apenas até o número de núcleos físicos deixa alguma folga para o hipervisor ESXi em threads lógicos, mesmo em situações extremas.

Se você estiver executando uma solução hiperconvergente (HCI), você DEVE também considerar os requisitos de CPU do HCI no nível do host. Veja minha postagem anterior sobre HCI para mais detalhes. O dimensionamento básico da CPU de VMs implantadas em HCI é o mesmo que o de outras VMs.

Lembre-se, você deve validar e testar tudo em seu próprio ambiente e com seus aplicativos.

Tenho visto sites de clientes relatando desempenho "lento" do aplicativo enquanto o sistema operacional convidado relata que há recursos de CPU de sobra.

Lembre-se de que o sistema operacional convidado não sabe que está virtualizado. Infelizmente, as métricas do convidado, por exemplo, conforme relatado pelo vmstat (por exemplo, em pButtons) podem ser enganosas, você também deve obter métricas de nível de host e métricas ESXi (por exemplo esxtop) para realmente entender a saúde e a capacidade do sistema.

Como você pode ver no gráfico acima, quando o host está relatando 100% de utilização, a VM convidada pode estar relatando uma utilização menor. A VM de 36 vCPU (vermelha) está relatando 80% de utilização média da CPU na taxa de 4x, enquanto o host está relatando 100%. Mesmo uma VM dimensionada corretamente pode ser privada de recursos, se, por exemplo, após a entrada em produção, outras VMs forem migradas para o host ou os recursos forem supercomprometidos por meio de regras DRS mal configuradas.

Para mostrar as principais métricas, para esta série de testes, configurei o seguinte:

• Duas VMs de banco de dados em execução no host.
• • uma de 24 vCPU em execução a uma taxa de transação constante de 2x (não mostrada no gráfico).
• -uma de 24 vCPU em execução a 1x, 2x, 3x (essas métricas são mostradas no gráfico).

Com outro banco de dados usando recursos; na taxa de 3x, o sistema operacional convidado (RHEL 7) vmstat está relatando apenas 86% de utilização média da CPU e a fila de execução tem uma média de apenas 25. No entanto, os usuários deste sistema estarão reclamando alto, pois o tempo de resposta do componente disparou à medida que os processos são desacelerados.

Como mostrado no gráfico a seguir, Co-stop e Tempo de Preparo contam a história de por que o desempenho do usuário é tão ruim. As métricas de Tempo de Preparo (%RDY) e CoStop (%CoStop) mostram que os recursos da CPU estão massivamente supercomprometidos na taxa alvo de 3x. Isso realmente não deveria ser uma surpresa, já que o host está executando 2x (outra VM) e a taxa de 3x desta VM de banco de dados.

O gráfico mostra que o tempo de espera (Ready time) aumenta quando a carga total da CPU no host aumenta.

Tempo de espera (Ready time) é o tempo em que uma VM está pronta para executar, mas não pode porque os recursos da CPU não estão disponíveis.

O co-stop também aumenta. Não há CPUs lógicas livres suficientes para permitir que a VM do banco de dados avance (como detalhei na seção HT acima). O resultado final é que o processamento é atrasado devido à contenção por recursos físicos da CPU.

Eu vi exatamente essa situação em um site de cliente onde nossa visão de suporte de pButtons e vmstat mostrava apenas o sistema operacional virtualizado. Enquanto o vmstat reportava folga de CPU, a experiência de desempenho do usuário era terrível.

A lição aqui é que só quando as métricas do ESXi e uma visão em nível de host foram disponibilizadas é que o problema real foi diagnosticado; recursos de CPU supercomprometidos causados por escassez geral de recursos de CPU do cluster e, para piorar a situação, regras DRS ruins fazendo com que VMs de banco de dados de alta transação migrassem juntas e sobrecarregassem os recursos do host.

Neste exemplo, usei uma VM de banco de dados de linha de base de 24 vCPUs executando a uma taxa de transação 3x, e depois duas VMs de banco de dados de 24 vCPUs a uma taxa de transação constante de 3x.

A utilização média da CPU da linha de base (veja o Exemplo 1 acima) foi de 76% para a VM e 85% para o host. Uma única VM de banco de dados de 24 vCPUs está usando todos os 24 processadores físicos. Executar duas VMs de 24 vCPUs significa que as VMs estão competindo por recursos e estão usando todas as 48 threads de execução lógicas no servidor.

Lembrando que o host não estava 100% utilizado com uma única VM, ainda podemos ver uma queda significativa no throughput e no desempenho, pois duas VMs de 24 vCPUs muito ocupadas tentam usar os 24 núcleos físicos no host (mesmo com HT). Embora o Caché seja muito eficiente ao usar os recursos de CPU disponíveis, ainda há uma queda de 16% no throughput do banco de dados por VM e, mais importante, um aumento de mais de 50% no tempo de resposta do componente (usuário).

Meu objetivo com este post é responder às perguntas comuns. Veja a seção de referência abaixo para um mergulho mais profundo nos recursos de CPU do host e no agendador de CPU do VMware.

Embora existam muitos níveis de ajustes e detalhes técnicos do ESXi para extrair a última gota de desempenho do seu sistema, as regras básicas são bastante simples.

Para grandes bancos de dados de produção :

• Planeje um vCPU por núcleo de CPU físico.
• Considere o NUMA e, idealmente, dimensione as VMs para manter a CPU e a memória locais em um nó NUMA.
• Dimensione corretamente as máquinas virtuais. Adicione vCPUs somente quando necessário.

Se você deseja consolidar VMs, lembre-se de que grandes bancos de dados são muito ocupados e utilizarão intensamente as CPUs (físicas e lógicas) em horários de pico. Não as superinscreva até que seu monitoramento indique que é seguro.

• Blog da VMware - Quando Supercomprometer vCPU:pCPU para VMs Monstruosas
• Introdução à Série de Mergulho Profundo em NUMA 2016
• O Agendador de CPU no VMware vSphere 5.1

Executei os exemplos neste post em um cluster vSphere composto por dois processadores Dell R730 conectados a um array all-flash. Durante os exemplos, não houve gargalos na rede ou no armazenamento.

• Caché 2016.2.1.803.0

PowerEdge R730

• 2x Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
• 16x 16GB RDIMM, 2133 MT/s, Dual Rank, x4 Data Width
• SAS 12Gbps HBA External Controller
• HyperThreading (HT) on

PowerVault MD3420, 12G SAS, 2U-24 drive

• 24x 24 960GB Solid State Drive SAS Read Intensive MLC 12Gbps 2.5in Hot-plug Drive, PX04SR
• 2 Controller, 12G SAS, 2U MD34xx, 8G Cache

VMware ESXi 6.0.0 build-2494585

• As VMs estão configuradas para as melhores práticas; VMXNET3, PVSCSI, etc.

RHEL 7

• Páginas grandes (Large pages)

A taxa de linha de base 1x teve uma média de 700.000 glorefs/segundo (acessos ao banco de dados/segundo). A taxa 5x teve uma média de mais de 3.000.000 glorefs/segundo para 24 vCPUs. Os testes foram permitidos a serem executados até que o desempenho constante fosse alcançado e, em seguida, amostras de 15 minutos foram coletadas e calculadas a média.

Estes exemplos são apenas para mostrar a teoria, você DEVE validar com sua própria aplicação!

InterSystems Anuncia Disponibilidade Geral do InterSystems IRIS, InterSystems IRIS for Health e HealthShare Health Connect 2025.1

A versão 2025.1 da plataforma de dados InterSystems IRIS®, InterSystems IRIS® for HealthTM e HealthShare® Health Connect agora está disponível para o público em geral (GA). Esta é uma versão de Manutenção Estendida (EM).

Destaques do Lançamento

Nesta versão emocionante, os usuários podem esperar vários novos recursos e melhorias, incluindo:

A interface de usuário de interoperabilidade agora inclui experiências de usuário modernizadas para os aplicativos Editor DTL e Configuração da Produção que estão disponíveis para aceitação em todos os produtos de interoperabilidade. Você pode alternar entre as visualizações modernizada e padrão. Todas as outras telas de interoperabilidade permanecem na interface de usuário padrão. Observe que as alterações são limitadas a esses dois aplicativos e identificamos abaixo a funcionalidade que está disponível atualmente.

Rubrica de FAQ da InterSystems
 

Pode ser feito com o TRY-CATCH:

#dim ex As%Exception.AbstractExceptionTRY {
    //Code that causes an error
  }
  CATCH ex {
     do ex.Log()
  }

Se você usar o ^%ETN, chame-o a partir do bloco BACK (BACK^%ETN).

Por favor, dê uma olhada também no artigo relacionado: Como buscar erros de aplicação (^ERRORS) usando um comando

Eu e os outros Arquitetos de Tecnologia frequentemente precisamos explicar aos clientes e fornecedores os requisitos de E/S do Caché e a forma como as aplicações Caché utilizarão os sistemas de armazenamento. As tabelas a seguir são úteis ao explicar o perfil e os requisitos típicos de E/S do Caché para uma aplicação de banco de dados transacional com clientes e fornecedores. As tabelas originais foram criadas por Mark Bolinsky.

Em publicações futuras, discutirei mais sobre E/S de armazenamento, portanto, estou publicando essas tabelas agora como referência para esses artigos.

Usando OpenEHR com InterSystems IRIS

Ocasionalmente, recebemos perguntas sobre o uso do OpenEHR com o InterSystems. Normalmente, essas discussões se concentram em por que e como uma organização deseja implementar o OpenEHR na construção de aplicativos. Aqui está um breve guia:

Plataformas de Dados e Desempenho da InterSystems - Parte 5: Monitoramento com SNMP

Em posts anteriores, mostrei como é possível coletar métricas de desempenho histórico usando pButtons. Recorro ao pButtons primeiro porque sei que ele é instalado com todas as instâncias de Plataformas de Dados (Ensemble, Caché, ...). No entanto, existem outras maneiras de coletar, processar e exibir métricas de desempenho do Caché em tempo real, seja para monitoramento simples ou, ainda, para análises operacionais e planejamento de capacidade muito mais sofisticados. Um dos métodos mais comuns de coleta de dados é usar o SNMP (Simple Network Management Protocol).

SNMP é uma maneira padrão para o Caché fornecer informações de gerenciamento e monitoramento para uma ampla variedade de ferramentas de gerenciamento. A documentação online do Caché inclui detalhes da interface entre o Caché e o SNMP. Embora o SNMP deva 'simplesmente funcionar' com o Caché, existem alguns truques e armadilhas de configuração. Levei alguns começos falsos e ajuda de outras pessoas aqui na InterSystems para fazer o Caché se comunicar com o agente mestre SNMP do Sistema Operacional, então escrevi este post para que você possa evitar a mesma dor.

Neste post, vou detalhar a configuração do SNMP para Caché no Red Hat Linux, e você deve ser capaz de usar os mesmos passos para outras distribuições *nix. Estou escrevendo o post usando o Red Hat porque o Linux pode ser um pouco mais complicado de configurar - no Windows, o Caché instala automaticamente uma DLL para se conectar com o serviço SNMP padrão do Windows, então deve ser mais fácil de configurar.

Uma vez que o SNMP esteja configurado no lado do servidor, você pode começar a monitorar usando várias ferramentas. Vou mostrar o monitoramento usando a popular ferramenta PRTG, mas existem muitas outras - Aqui está uma lista parcial.

Observe que os arquivos MIB do Caché e Ensemble estão incluídos na pasta Caché_installation_directory/SNMP. Os arquivos são: ISC-CACHE.mib e ISC-ENSEMBLE.mib.

Posts anteriores desta série:

• Plataformas de Dados InterSystems e desempenho - Parte 1
• Plataformas de Dados InterSystems e desempenho - Parte 2
• Parte 3 - Foco na CPU
• Parte 4 - Análise da memória

Comece aqui...

Comece revisando "Monitorando o Caché Usando SNMP" na documentação online do Caché..

1. Configuração do Caché

Siga os passos na seção Gerenciando SNMP no Caché na documentação online do Caché para habilitar o serviço de monitoramento do Caché e configurar o subagente SNMP do Caché para iniciar automaticamente na inicialização do Caché.

Verifique se o processo do Caché está em execução, por exemplo, olhando na lista de processos ou no sistema operacional:

ps -ef | grep SNMP
root      1171  1097  0 02:26 pts/1    00:00:00 grep SNMP
root     27833     1  0 00:34 pts/0    00:00:05 cache -s/db/trak/hs2015/mgr -cj -p33 JOB^SNMP

É só isso, a configuração do Caché está completa!

2. Configuração do sistema operacional

Há um pouco mais a fazer aqui. Primeiro, verifique se o daemon snmpd está instalado e em execução. Se não estiver, instale e inicie o snmpd.

Verifique o status do snmpd com:

service snmpd status

Inicie ou pare o snmpd com:

service snmpd start|stop

Se o SNMP não estiver instalado, você terá que instalá-lo de acordo com as instruções do sistema operacional, por exemplo: yum -y install net-snmp net-snmp-utils

3. Configure o snmpd

Conforme detalhado na documentação do Caché, em sistemas Linux, a tarefa mais importante é verificar se o agente mestre SNMP no sistema é compatível com o protocolo Agent Extensibility (AgentX) (o Caché é executado como um subagente) e se o mestre está ativo e escutando conexões na porta TCP padrão do AgentX, 705.

Foi aqui que encontrei problemas. Cometi alguns erros básicos no arquivo snmp.conf que impediram o subagente SNMP do Caché de se comunicar com o agente mestre do sistema operacional. O seguinte arquivo de exemplo /etc/snmp/snmp.conf foi configurado para iniciar o AgentX e fornecer acesso aos MIBs SNMP do Caché e do Ensemble.

Observe que você terá que confirmar se a seguinte configuração está em conformidade com as políticas de segurança da sua organização.

No mínimo, as seguintes linhas devem ser editadas para refletir a configuração do seu sistema.

Por exemplo, altere:

syslocation  "System_Location"

para

syslocation  "Primary Server Room"

Edite também pelo menos as seguintes duas linhas:

syscontact  "Your Name"
trapsink  Caché_database_server_name_or_ip_address public 	

Edite ou substitua o arquivo /etc/snmp/snmp.conf existente para corresponder ao seguinte::

###############################################################################
#
# snmpd.conf:
#   Um arquivo de configuração de exemplo para configurar o agente NET-SNMP com o 
    #   Caché.
#
#   Isto foi usado com sucesso no Red Hat Enterprise Linux e executando
#   o daemon snmpd em primeiro plano com o seguinte comando:
#
#	/usr/sbin/snmpd -f -L -x TCP:localhost:705 -c./snmpd.conf
#
#  Você pode querer/precisar alterar algumas das informações, especialmente o
#   endereço IP do receptor de traps se você espera receber traps. Eu também vi
#   um caso (no AIX) onde tivemos que usar a opção "-C" na linha de comando snmpd,
#  para garantir que estávamos obtendo o arquivo snmpd.conf correto.
#
###############################################################################

###########################################################################
# SEÇÃO: Configuração de Informações do Sistema
#
#   Esta seção define algumas das informações relatadas no
#   grupo mib "system" na árvore mibII.

# syslocation: A localização [tipicamente física] do sistema.
#   Observe que definir este valor aqui significa que ao tentar
#   executar uma operação snmp SET na variável sysLocation.0, o agente
#   etornará o código de erro "notWritable". Ou seja, incluir
#   este token no arquivo snmpd.conf desativará o acesso de gravação à
#   variável.
#   argumentos:  string_de_localização

syslocation  "Localização do Sistema"

# syscontact: As informações de contato do administrador
#   Observe que definir este valor aqui significa que ao tentar
#   executar uma operação snmp SET na variável sysContact.0, o agente
#   retornará o código de erro "notWritable". Ou seja, incluir
#   este token no arquivo snmpd.conf desativará o acesso de gravação à
#  variável.
#   argumentos:  string_de_contato

syscontact  "Seu Nome"

# sysservices: O valor adequado para o objeto sysServices.
#   argumentos:  número_sysservices

sysservices 76

###########################################################################
# SEÇÃO: Modo de Operação do Agente
#
#   Esta seção define como o agente operará quando estiver em execução.
#   

# master: O agente deve operar como um agente mestre ou não.
#   Atualmente, o único tipo de agente mestre suportado para este token
#   é "agentx".
#   
#   argumentos: (on|yes|agentx|all|off|no)

master agentx
agentXSocket tcp:localhost:705

###########################################################################
#  SEÇÃO: Destinos de Trap
#
#   Aqui definimos para quem o agente enviará traps.

# trapsink: Um receptor de traps SNMPv1
#   argumentos: host [community] [portnum]

trapsink  Caché_database_server_name_or_ip_address public 	

###############################################################################
# Controle de Acesso
###############################################################################

# Como fornecido, o daemon snmpd responderá apenas a consultas no
# grupo mib do sistema até que este arquivo seja substituído ou modificado
# para fins de segurança. Exemplos de como aumentar o nível de acesso
# são mostrados abaixo.
#
# De longe, a pergunta mais comum que recebo sobre o agente é "por que ele
# não funciona?", quando na verdade deveria ser "como configuro o agente
# para me permitir acessá-lo?"
#
# Por padrão, o agente responde à comunidade "public" para acesso somente
# leitura, se executado diretamente, sem nenhum arquivo de configuração
# no lugar. Os exemplos a seguir mostram outras maneiras de configurar
# o agente para que você possa alterar os nomes da comunidade e conceder
# a si mesmo acesso de gravação à árvore mib também.
#
# Para mais informações, leia o FAQ, bem como a página de manual
# snmpd.conf(5).
#
####
# Primeiro, mapeie o nome da comunidade "public" para um "nome de segurança"

#       sec.name  source          community
com2sec notConfigUser  default       public

####
# Segundo, mapeie o nome de segurança para um nome de grupo:

#       groupName      securityModel securityName
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser

####
# Terceiro, crie uma visualização para que o grupo tenha direitos de acesso:

# Faça com que pelo menos o snmpwalk -v 1 localhost -c public system volte a ser rápido.
#       name           incl/excl     subtree         mask(optional)
# acesso ao subconjunto 'internet' 
view    systemview    included   .1.3.6.1

# Acesso aos MIBs do Cache Caché e Ensemble 
view    systemview    included   .1.3.6.1.4.1.16563.1
view    systemview    included   .1.3.6.1.4.1.16563.2
####
# Finalmente, conceda ao grupo acesso somente leitura à visualização systemview.	
#       group          context sec.model sec.level prefix read   write  notif
access  notConfigGroup ""      any       noauth    exact  systemview none none

Após editar o arquivo /etc/snmp/snmp.conf, reinicie o daemon snmpd.

service snmpd restart

Verifique o status do snmpd, observe que o AgentX foi iniciado, veja a linha de status: Ativando o suporte mestre AgentX.

h-4.2# service snmpd restart
Redirecting to /bin/systemctl restart  snmpd.service
sh-4.2# service snmpd status
Redirecting to /bin/systemctl status  snmpd.service
● snmpd.service - Simple Network Management Protocol (SNMP) Daemon.
   Loaded: loaded (/usr/lib/systemd/system/snmpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2016-04-27 00:31:36 EDT; 7s ago
 Main PID: 27820 (snmpd)
   CGroup: /system.slice/snmpd.service
		   └─27820 /usr/sbin/snmpd -LS0-6d -f

Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Starting Simple Network Management Protocol (SNMP) Daemon....
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: Turning on AgentX master support.
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: NET-SNMP version 5.7.2
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon..
sh-4.2# 

Após reiniciar o snmpd, você deve reiniciar o subagente SNMP do Caché usando a rotina ^SNMP:

%SYS>do stop^SNMP()

%SYS>do start^SNMP(705,20)

O daemon snmpd do sistema operacional e o subagente Caché agora devem estar em execução e acessíveis.

4. Testando o acesso MIB

O acesso MIB pode ser verificado a partir da linha de comando com os seguintes comandos. snmpget retorna um único valor:

snmpget -mAll -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1.5.5.72.50.48.49.53

SNMPv2-SMI::enterprises.16563.1.1.1.1.5.5.72.50.48.49.53 = STRING: "Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT"

E snmpwalk irá 'percorrer' a árvore ou ramo MIB::

snmpwalk -m ALL -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1

SNMPv2-SMI::enterprises.16563.1.1.1.1.2.5.72.50.48.49.53 = STRING: "H2015"
SNMPv2-SMI::enterprises.16563.1.1.1.1.3.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/cache.cpf"
SNMPv2-SMI::enterprises.16563.1.1.1.1.4.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/mgr/"
etc
etc

Existem também vários clientes Windows e *nix disponíveis para visualizar dados do sistema. Eu uso o iReasoning MIB Browser gratuito. Você precisará carregar o arquivo ISC-CACHE.MIB no cliente para que ele reconheça a estrutura do MIB.

A imagem a seguir mostra o iReasoning MIB Browser no OSX.

Incluindo em Ferramentas de Monitoramento

É aqui que podem haver grandes diferenças na implementação. A escolha da ferramenta de monitoramento ou análise fica a seu critério.

Por favor, deixe comentários na postagem detalhando as ferramentas e o valor que você obtém delas para monitorar e gerenciar seus sistemas. Isso será de grande ajuda para outros membros da comunidade.

Abaixo está uma captura de tela do popular PRTG Network Monitor mostrando métricas do Caché. Os passos para incluir métricas do Caché no PRTG são semelhantes aos de outras ferramentas.

Fluxo de trabalho de exemplo - adicionando o MIB do Caché à ferramenta de monitoramento.

Passo 1.

Certifique-se de que você pode se conectar aos MIBs do sistema operacional. Uma dica é solucionar problemas com o sistema operacional, não com o Caché. É muito provável que as ferramentas de monitoramento já conheçam e estejam pré-configuradas para MIBs comuns de sistemas operacionais, então a ajuda de fornecedores ou outros usuários pode ser mais fácil.

Dependendo da ferramenta de monitoramento que você escolher, pode ser necessário adicionar um 'módulo' ou 'aplicativo' SNMP, que geralmente são gratuitos ou de código aberto. Achei as instruções do fornecedor bastante diretas para esta etapa.

Uma vez que você esteja monitorando as métricas do sistema operacional, é hora de adicionar o Caché.

Passo 2.

Importe os arquivos ISC-CACHE.mib eISC-ENSEMBLE.mibpara a ferramenta para que ela reconheça a estrutura do MIB.

Os passos aqui irão variar; por exemplo, o PRTG possui um utilitário 'Importador de MIB'. Os passos básicos são abrir o arquivo de texto ISC-CACHE.mib na ferramenta e importá-lo para o formato interno da ferramenta. Por exemplo, o Splunk usa um formato Python, etc.

Nota:_ Descobri que a ferramenta PRTG expirava o tempo limite se eu tentasse adicionar um sensor com todos os ramos do MIB do Caché. Presumo que ele estava percorrendo toda a árvore e expirou o tempo limite para algumas métricas como listas de processos. Não gastei tempo solucionando esse problema, em vez disso, contornei o problema importando apenas o ramo de desempenho (cachePerfTab) do ISC-CACHE.mib.

Uma vez importado/convertido, o MIB pode ser reutilizado para coletar dados de outros servidores em sua rede. O gráfico acima mostra o PRTG usando o sensor Sensor Factory para combinar vários sensores em um único gráfico.

Resumo

Existem muitas ferramentas de monitoramento, alerta e algumas ferramentas de análise muito inteligentes disponíveis, algumas gratuitas, outras com licenças para suporte e muitas funcionalidades variadas.

Você deve monitorar seu sistema e entender qual atividade é normal e qual atividade foge do normal e deve ser investigada. SNMP é uma maneira simples de expor métricas do Caché e do Ensemble.

Olá Colegas! 

Muitas vezes, durante o desenvolvimento de um frontend de aplicação ou qualquer outra comunicação com API REST, vale a pena usar o Swagger UI -  uma IU de teste para aplicações REST que segue a especificação Open API 2.0. Geralmente, é bem trabalhoso, pois permite testes manuais rápidos em relação à API REST, suas respostas e os dados contidos nela.

Recentemente eu introduzi o suporte ao Swagger para o modelo InterSystems IRIS FHIR para API FHIR R4: 

Como fazê-lo funcionar. 

A partir da plataforma de dados InterSystems IRIS® versão 2025.1, a InterSystems está oficialmente descontinuando o MultiValue e incluindo-o na lista de Recursos Descontinuados e Obsoletos. Embora a InterSystems continue a oferecer suporte aos clientes existentes que usam o MultiValue, ele não é recomendado para novos aplicativos.

O Que Isso Significa:

19 de Fevereiro de 2025 – Alerta: Consultas SQL Retornando Resultados Errados

A InterSystems corrigiu dois problemas que podem fazer com que um pequeno número de consultas SQL retornem resultados incorretos. Além disso, a InterSystems corrigiu uma inconsistência no tratamento de tipo de dados de data/hora que pode levar a resultados diferentes e inesperados — mas corretos — para aplicativos existentes que dependem do comportamento inconsistente anterior.

DP-436825: Consultas SQL com Junção Lateral Podem Retornar Resultados Errados

O que é JWT?

JWT (JSON Web Token) é um padrão aberto (RFC 7519) que oferece um método leve, compacto e auto-contido para transmitir informações de forma segura entre duas partes. É comumente usado em aplicações web para autenticação, autorização e troca de informações.

Um JWT é tipicamente composto por três partes:

1. Cabeçalho JOSE (JSON Object Signing and Encryption) 
2. Payload (Carga útil)
3. Assinatura

Essas partes são codificadas no formato Base64Url e concatenadas com pontos (.) separando-as.

Estrutura de um JWT

Cabeçalho

{ "alg": "HS256", "typ": "JWT"}

Payload

Para um de nossos clientes, precisei integrar com o endpoint AFAS imageconnector/imageconnector/{imageId}?format={format}. Esse endpoint retorna uma mensagem JSON com a imagem como uma propriedade de string codificada em base64, além do mimetype da imagem.

/// Image Object
Class Mycustomer.Model.AfasGet.Image Extends (%SerialObject, %XML.Adaptor, %JSON.Adaptor)
{
/// file data (base64 encoded)
Property Filedata As %String(%JSONFIELDNAME = "filedata");

/// MimeType e.g. "image/jpeg"
Property MimeType As %String(%JSONFIELDNAME = "mimetype");
}

Na classe Message, tentamos lidar com isso da seguinte forma:

Property Image As Mycustomer.Model.AfasGet.Image;

/// AFAS GetImage response
/// get /imageconnector/{imageId}?format={format}
Method LoadFromResponse(httpResponse As %Net.HttpResponse, caller As %String = "") As %Status
{
	Set sc = $$$OK

	If $$$LOWER($Piece(httpResponse.ContentType,";",1))="application/json",httpResponse.StatusCode = "200" {
		set ..Image = ##class(Mycustomer.Model.AfasGet.Image).%New()
		set ..status = ..Image.%JSONImport(httpResponse.Data)
	}

	Return sc
}

Tudo isso funcionava bem até que, em algum momento, o tamanho do filedata se tornou maior que o $$$MaxStringLength (3.641.144), caso em que uma exceção MAXSTRING era levantada.

O próximo passo lógico foi alterar o tipo da propriedade filedata para %Stream.GlobalCharacter:

/// Image Object
Class Mycustomer.Model.AfasGet.Image Extends (%SerialObject, %XML.Adaptor, %JSON.Adaptor)
{
/// file data (base64 encoded)
Property Filedata As %Stream.GlobalCharacter(%JSONFIELDNAME = "filedata");

/// MimeType e.g. "image/jpeg"
Property MimeType As %String(%JSONFIELDNAME = "mimetype");
}

Mas isso não funcionou, %JSONImport() ainda gerava um erro MAXSTRING

Tentei então com Python, mas como não sou um especialista em Python, eventualmente desisti dessa abordagem.

Graças à resposta de Steven Hobbs https://community.intersystems.com/user/steven-hobbs em https://community.intersystems.com/post/maxstring-trying-read-string-json-object#comment-250216, aprendi então que é possível e direto recuperar propriedades de string JSON para um stream usando image.%Get("filedata", , "stream")):

Method LoadFromResponse(httpResponse As %Net.HttpResponse, caller As %String = "") As %Status
{
	Set sc = $$$OK

	If $$$LOWER($Piece(httpResponse.ContentType,";",1))="application/json",httpResponse.StatusCode = "200" {
		set ..Image = ##class(Mycustomer.Model.AfasGet.Image).%New()
		set image = {}.%FromJSON(httpResponse.Data)
		set ..Image.MimeType = image.mimetype
		set ..Image.Filedata = ##class(%Stream.GlobalCharacter).%New()
		do ..Image.Filedata.CopyFrom(image.%Get("filedata", , "stream"))
	}

	Return sc
}

Ainda estou perplexo sobre como eu poderia instruir a classe %JSON.Adaptor e usar a lógica interna para mapear para um stream. Se houver alguém por aí que saiba como fazer isso, por favor, me avise!

Rubrica de Perguntas Frequentes da InterSystems

Para executar SQL no Terminal, use $system.SQL.Shell().

Por favor, consulte o exemplo abaixo.

Você pode encontrar erros durante qualquer ponto da execução do programa, e existem várias maneiras de levantar e tratar essas exceções. Neste artigo, exploraremos como as exceções são tratadas de forma eficiente no IRIS.

Um dos tipos de retorno mais comumente usados é %Status, que é usado por métodos para indicar sucesso ou falha. Vamos começar discutindo os valores de %Status.

Trabalhando com %Status

Você precisa instalar o aplicativo primeiro. Se não estiver instalado, por favor, consulte o artigo anterior.

Demonstração do aplicativo

Após executar com sucesso o aplicativo de busca de vetores de imagem de íris, alguns dados precisam ser armazenados para suportar a recuperação de imagens, pois não são inicializados na biblioteca.

Armazenamento de imagens

Primeiramente, arraste e solte a imagem ou clique no ícone de upload, selecione a imagem e clique no botão de upload para enviar e vetorizá-la. Este processo pode ser um pouco lento.

As primeiras prévias para desenvolvedores da plataforma de dados InterSystems IRIS^® data platform, InterSystems IRIS^® for Health, e HealthShare^® Health Connect 2025.1 foram publicadas no site de prévia para desenvolvedores do WRC. Os contêineres podem ser encontrados em nosso registro de contêineres e são marcados como última prévia.

As últimas versões de manutenção estendida do InterSystems IRIS, InterSystems IRIS for Health, and HealthShare Health Connect já estão disponíveis.

✅ 2024.1.3

Versão 2024.1.3 fornece correções de bugs para qualquer uma das versões anteriores a 2024.1.x, incluindo a correção para o seguinte alerta emitido recentemente - Alerta: Dados inválidos introduzidos no Banco de Dados e no Journal com operações $LIST específicas. 

Você pode encontrar as listas de alterações detalhadas e as listas de verificação de atualizações nestas páginas:

Não tenho certeza se muitos se conectam ao MS SQL para executar consultas, procedimentos armazenados, etc., mas nosso Sistema de Saúde possui muitos bancos de dados baseados em MS SQL que utilizamos no ambiente de Interoperabilidade por vários motivos.

Com a migração do ambiente local para a nuvem, enfrentamos algumas dificuldades com as conexões do SQL Gateway e como configurá-las para usar o Microsoft Entra para autenticação do Active Directory.

Rubrica de perguntas frequentes da InterSystems

Você pode configurar o tamanho máximo do banco de dados IRISTemp na inicialização do IRIS ao definir um parâmetro de configuração chamado MaxIRISTempSizeAtStart.

Após a definição, o sistema truncará o IRISTemp para o valor definido (MB) na próxima inicialização do IRIS. Se o tamanho atual for menor que o MaxIRISTempSizeAtStart especificado, não ocorrerá nenhum truncamento. Além disso, se for especificado 0, o truncamento não será realizado, então o tamanho será inicializado sem alteração. As configurações (padrão) são realizadas no menu abaixo.

Portal de Gerenciamento
[Administração do Sistema] > [Configuração] > [Configurações adicionais] > [Inicialização] > "MaxIRISTempSizeAtStart"

Para mais detalhes, consulte a página de documentação abaixo.
MaxIRISTempSizeAtStart

A InterSystems corrigiu um defeito que faz com que registros inválidos de banco de dados e diário sejam introduzidos ao usar uma sintaxe $LIST específica. A probabilidade de encontrar esse defeito é muito baixa, mas os impactos operacionais podem ser significativos.

Produtos Afetados

Lançamos o IPM 0.9.0. Anteriormente comentei um pouco da história e do raciocínio aqui; para resumir, este é um grande lançamento por dois motivos: representa uma reunificação há muito esperada do nosso trabalho interno e conduzido pela comunidade em torno do gerenciamento de pacotes ObjectScript centrado no IRIS, e tem algumas incompatibilidades com versões anteriores. Há várias incompatibilidades com versões anteriores necessárias em nosso roteiro, e nós as juntamos; isso não será uma nova norma.

No artigo anterior. Práticas de membros de classe e sua execução dentro do Python embutido. Agora voltaremos nossa atenção para o processo de alternância de espaços de nomes, acesso a variáveis globais, travessia e execução de rotinas dentro do Python embutido.

Antes de prosseguir para as outras funções. vamos revisar brevemente a função executedentro do pacote iris. Esta função é excepcionalmente benéfica para executar funções ObjectScript arbitrárias e invocação de classe.

Olá comunidade,

Neste artigo, vou descrever e ilustrar o processo de implementação do ObjectScript dentro do Python embutido. Esta discussão também fará referência a outros artigos relacionados ao Python embutido, bem como abordará questões que foram benéficas para a minha jornada de aprendizado.

Como você sabe, a integração de recursos Python dentro do IRIS tem sido possível há algum tempo. Este artigo se concentrará em como incorporar perfeitamente o ObjectScript com o Python embutido.