Como configurar os limites de memória do SAP HANA no SUSE Linux Enterprise Server

O controle de memória do SAP HANA no SUSE Linux Enterprise Server funciona melhor quando você separa duas tarefas distintas: limitar o que o HANA pode alocar e proteger as cargas de trabalho do SAP quando o host Linux estiver sob pressão de memória. O SAP HANA lida com a primeira tarefa com parâmetros de banco de dados como ` --database` global_allocation_limite ​​` statement_memory_limit--database`. A Proteção de Memória de Carga de Trabalho (WMP) do SUSE, baseada em systemd/cgroup, lida com a segunda tarefa com ` MemoryLow--database` SAP.slice. Esses mecanismos se complementam, mas não são intercambiáveis.

Este guia utiliza a documentação do SAP HANA Platform 2.0 SPS 08 e as orientações atuais do SUSE Linux Enterprise Server para aplicações SAP, disponíveis em outubro de 2026. Antes de alterar um sistema de produção, confirme se a sua revisão exata do HANA e o pacote de serviços do SLES são suportados. O guia de instalação da SAP direciona os administradores para a Nota SAP 2235581 para obter informações sobre os sistemas operacionais suportados: Guia de Instalação e Atualização do Servidor SAP HANA .

Qual controle de memória você deve usar?

Documentos SAP global_allocation_limitem MB. Com o parâmetro definido em seu valor padrão de 0, o HANA calcula um limite automático com base na memória física disponível; o Guia de Administração do SPS 08 descreve a fórmula atual como 90% dos primeiros 64 GB mais 97% de cada GB adicional, com tratamento especial para sistemas muito pequenos. O mesmo guia afirma que a alteração do parâmetro não requer reinicialização. Consulte o Guia de Administração do SAP HANA 2.0 SPS 08 .

Passo 1: Meça a memória do host antes de definir um limite.

Comece verificando a RAM física, a memória disponível, a atividade de swap no SLES e se os processos SAP já estão agrupados SAP.slice. Isso lhe dará as condições de contorno antes de decidir quanta memória o HANA poderá usar.

free -h
grep MemTotal /proc/meminfo
systemctl status SAP.slice

Não escolha um limite para o HANA simplesmente subtraindo um número fixo de gigabytes da RAM instalada. Reserve memória para o kernel do Linux, o SAP Host Agent, o software de monitoramento, as ferramentas de backup, os componentes do cluster e quaisquer servidores de aplicativos colocalizados. Se o ABAP e o HANA compartilharem um host, a SAP exige explicitamente que o dimensionamento de ambos os sistemas caiba na memória física disponível e recomenda coordenar o limite de alocação global do HANA com a PHYS_MEMSIZEconfiguração do ABAP: SAP Configuring Memory Settings .

Etapa 2: Leia os parâmetros de memória HANA existentes.

Antes de alterar qualquer coisa, registre a configuração efetiva. Você pode verificar isso M_INIFILE_CONTENTSno SAP HANA Database Explorer, no console SQL do Cockpit ou em outro cliente SQL autorizado.

SELECT FILE_NAME, SECTION, KEY, VALUE, LAYER_NAME
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
  AND KEY IN ('global_allocation_limit',
              'statement_memory_limit',
              'statement_memory_limit_threshold')
ORDER BY KEY, LAYER_NAME;

A camada é importante. Em sistemas multi-inquilinos, as configurações de nível de sistema e de nível de banco de dados podem ter escopos diferentes. Não copie um comando de um exemplo de contêiner único sem verificar se você está conectado ao SYSTEMDB ou a um banco de dados de inquilino e qual camada você pretende alterar.

Etapa 3: Defina o limite de alocação global do HANA

Use global_allocation_limitquando o objetivo for limitar a alocação total do HANA. Um valor como 180000 significa 180.000 MB; é apenas um exemplo, não uma recomendação universal. O número correto deve ser determinado com base no dimensionamento, histórico de carga de trabalho, requisitos de alta disponibilidade e na memória que deve permanecer disponível para o sistema operacional e outros processos.

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'global_allocation_limit') = '180000'
WITH RECONFIGURE;

A vantagem de um limite global mais baixo é a margem de segurança previsível fora do HANA. O custo é menos espaço para crescimento do armazenamento em colunas, caches, resultados intermediários de consultas e sobrecarga de serviço. Se o host for dedicado ao HANA, o valor padrão automático pode ser apropriado após a validação do dimensionamento. Se o host for compartilhado, um limite explícito geralmente é mais fácil de definir, pois cada carga de trabalho residente tem um orçamento definido.

Etapa 4: Decida se deseja limitar instruções SQL individuais.

statement_memory_limitControla a alocação máxima de memória para uma única instrução e é expressa em GB. A SAP documenta o valor padrão como 0, o que significa que não há limite específico para a instrução. Um valor finito é útil quando consultas analíticas ad-hoc ou junções mal filtradas podem consumir uma grande parte do pool global.

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'statement_memory_limit') = '5'
WITH RECONFIGURE;

A relação de compromisso é direta: um limite mais restritivo protege a concorrência, mas pode interromper instruções que consomem muita memória e que são válidas para o seu negócio. A SAP observa que atingir o limite interrompe a instrução e pode gerar um dump com compositelimit_oomo nome "limitado". Para obter detalhes, consulte a seção de gerenciamento de memória do Guia de Solução de Problemas e Análise de Desempenho do SAP HANA .

Etapa 5: Use limites específicos do usuário quando um valor global for muito grosseiro.

Um limite de extrato único é simples de operar, mas trata uma conta ETL overnight da mesma forma que um usuário de relatório interativo. O SAP oferece suporte a um limite específico do usuário STATEMENT MEMORY LIMITque tem precedência sobre o limite de extrato global para esse usuário.

ALTER USER REPORT_USER
SET PARAMETER STATEMENT MEMORY LIMIT = '2';

Essa abordagem costuma ser melhor do que reduzir o limite global para todos. Por exemplo, você pode restringir a geração de relatórios ad-hoc, mantendo uma permissão maior para contas de processamento em lote ou administrativas. A desvantagem é a governança: as exceções precisam ser documentadas, revisadas e eliminadas quando não forem mais necessárias. A SAP também documenta limitações para consultas entre bancos de dados e para determinados cenários do XS Classic, nos quais classes de carga de trabalho podem ser mais apropriadas. Consulte a seção " Configurando parâmetros de usuário para carga de trabalho" da SAP .

Etapa 6: Proteja a memória SAP no SUSE com MemoryLow, não com um segundo limite rígido.

No SLES para aplicações SAP, a SUSE recomenda a proteção de memória de carga de trabalho por meio do systemd e do cgroup v2. As instâncias SAP são colocadas em SAP.slice, e a SUSE afirma que, para o SAP HANA, o Limite Global de Alocação do HANA pode ser usado como base para MemoryLow.

sudo systemctl set-property SAP.slice MemoryLow=180G
systemctl show SAP.slice -p MemoryLow

MemoryLowé um limite de proteção: sob pressão de memória, o kernel tenta proteger essa quantidade para o cgroup. Não é o mesmo que MemoryMax, e não substitui o alocador próprio do HANA. Essa distinção é importante porque um limite rígido no nível do sistema operacional pode criar um modo de falha diferente dos controles de alocação internos do HANA.

A SUSE também alerta para não definir MemoryLowvalores próximos ou superiores à memória física total, pois os serviços do sistema e outros softwares instalados também precisam de memória. As orientações atuais estão disponíveis em SUSE Workload Memory Protection for SLES for SAP 15 SP6 .

Etapa 7: Confirme se você não adicionou acidentalmente um cap de cgroup conflitante.

Após configurar MemoryLow, inspecione as propriedades relevantes do systemd. Se o seu projeto não utiliza intencionalmente `systemd.conf` MemoryHighou MemoryMax`systemd.conf`, verifique se eles não foram introduzidos por um módulo local, sistema de automação ou política de ajuste não relacionada.

systemctl show SAP.slice | grep -E 'MemoryLow|MemoryHigh|MemoryMax'

Isso é especialmente importante em hosts compartilhados gerenciados por automação de configuração. A Proteção de Memória de Carga de Trabalho da SUSE foi projetada para proteger o SAP contra a pressão de cargas de trabalho fora do cgroup protegido; ela não pode proteger sistemas SAP ou instâncias SAP uns dos outros quando todos compartilham o mesmo SAP.slicecgroup. Isso significa que o dimensionamento em nível de aplicação ainda importa mesmo quando a proteção de cgroup está habilitada.

Etapa 8: Verifique as configurações do HANA e observe o comportamento sob carga de trabalho real.

Execute uma nova consulta M_INIFILE_CONTENTSapós a alteração e confirme a camada e os valores pretendidos. Em seguida, monitore o sistema durante cargas de trabalho normais e de pico. Uma configuração não é considerada bem-sucedida apenas porque a instrução SQL foi executada sem erros.

SELECT FILE_NAME, SECTION, KEY, VALUE
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
ORDER BY KEY;

Fique atento a eventos de falta de memória, cancelamentos de instruções, pressão sustentada na memória, troca de memória (swapping) e latência da carga de trabalho. Se instruções que antes eram concluídas sem erros começarem a falhar com erros de limite de memória, o valor por instrução pode estar muito restritivo. Se o Linux tiver pouca margem de segurança enquanto o HANA se aproxima regularmente do limite global, o limite global pode estar muito alto para a carga de trabalho combinada do host. Se o HANA permanecer muito abaixo do seu limite enquanto consultas críticas estão sendo interrompidas ou abortadas, o limite pode estar muito baixo ou a carga de trabalho pode precisar de uma política mais direcionada.

Escolher uma política para padrões de implantação comuns

Host HANA de produção dedicado

Priorize o gerenciamento de alocação global próprio do HANA e deixe espaço suficiente no sistema operacional com base no dimensionamento do SAP. Adicione um limite de instruções somente se o histórico de carga de trabalho mostrar que instruções individuais ameaçam a concorrência. Use o SUSE MemoryLowquando desejar proteger a carga de trabalho do SAP da pressão de memória não relacionada ao SAP no host.

HANA e servidor de aplicativos em um único host

Utilize orçamentos explícitos. Coordene o HANA global_allocation_limitcom as configurações de memória do servidor de aplicativos, como PHYS_MEMSIZE. Isso é menos flexível do que permitir que ambos os lados cresçam livremente, mas reduz o risco de um componente consumir a memória necessária para o outro.

Análises mistas com consultas ad-hoc imprevisíveis

Combine um limite de alocação global razoável com controles em nível de instrução. Comece com evidências de instruções dispendiosas e picos de uso de memória, em vez de um número pequeno arbitrário. Limites específicos do usuário ou classes de carga de trabalho são preferíveis quando apenas determinados usuários ou aplicativos geram consultas de risco.

Sistemas HA ou HANA em cluster

Dimensionar os estados ativo e de transição. Um nó secundário que se torna primário pode precisar de uma quantidade de memória substancialmente diferente da que utiliza durante a replicação em estado estável. Considere o projeto de failover, os agentes de cluster, a pilha de monitoramento e quaisquer cargas de trabalho colocalizadas como parte do orçamento de memória, em vez de configurar cada host isoladamente.

Erros comuns a evitar

• Tratar MemoryLow como um limite máximo rígido protege a memória, mas não limita o HANA a essa quantidade.
• Definir MemoryMax porque parece equivalente ao limite de alocação do HANA. A semântica é diferente, e um limite rígido do sistema operacional pode interferir no próprio gerenciamento de memória do HANA.
• Utilizar o mesmo limite de instruções para todos os usuários sem evidências de carga de trabalho. Uma consulta de relatório e uma operação de manutenção podem ter necessidades legítimas de memória muito diferentes.
• Ignorando a camada de configuração em sistemas MDC. Confirme se você está alterando o escopo de SYSTEM, HOST ou DATABASE e qual banco de dados sua sessão SQL está utilizando como alvo.
• Copiando números de exemplo para produção. Os valores de 180 GB e 5 GB mostrados aqui são valores de demonstração, não recomendações de dimensionamento.
• Não deixando margem para o SUSE e serviços de suporte. O HANA não é o único consumidor de RAM física.

Recomendação final

Use global_allocation_limito limite máximo de memória do SAP HANA como referência principal, adicione limites statement_memory_limitsomente quando precisar controlar o risco de consultas individuais e utilize políticas específicas do usuário ou da classe de carga de trabalho quando diferentes cargas de trabalho exigirem limites diferentes. No SUSE Linux Enterprise Server para SAP Applications, use SAP.slice MemoryLowo limite máximo de memória do SAP para proteger a carga de trabalho do host da pressão, em vez de tentar duplicar o limite do HANA com um limite rígido de cgroup.

O principal fator de equilíbrio reside na necessidade de equilibrar a capacidade máxima de cache/consulta do HANA com a margem de segurança do host para garantir o bom funcionamento do sistema operacional e dos serviços colocalizados. Os valores finais devem ser baseados no dimensionamento da SAP e nos picos de produção observados, e a partir daí, os resultados devem ser verificados tanto no HANA quanto no SLES após a alteração.