Árvore de páginas

Pontos importantes

O Smartclent Desktop será descontinuado; a partir da release 12.1.2410, é obrigatório o uso do WebApp. Clique para mais informações.

♦ Esta documentação é válida a partir do Release 12.1.2410 do Protheus com dicionário no banco de dados, considerando os bancos de dados SQL Server, Oracle e PostgreSQL.

♦ Os valores aqui descritos serão revisados levando em consideração dados coletados em conjunto com os clientes piloto.

♦ Para integrações do Protheus com Smart View, consulte também os Requisitos mínimos para Smart View.

♦ O clock mínimo do processador em todos os servidores é de 2.3GHz

ATENÇÃO: VERSÃO DE BANCO DE DADOS E SISTEMA OPERACIONAL

A partir do release 12.1.2410, não será mais permitido o uso de versões de banco de dados e sistemas operacionais não homologados. Consulte as especificações homologadas para o Protheus, DBAccess e Application Server.

Balanceamento de carga

É obrigatório o uso do Broker http para realizar a distribuição dos serviços, que inclui a funcionalidade nativa de proxy reverso. O Broker distribui as threads de acordo com a afinidade de memória RAM e CPU, evitando a sobrecarga de recursos de um servidor. O balanceamento tradicional, em comparação, não utiliza o proxy reverso e pode acarretar em erros de sincronismo entre o Webapp e o Appserver.

 Balanceamento de carga com broker

 Como realizar uma configuração básica de broker?

Para o ERP

Para o uso do Protheus com até 100 usuários, utilize 8 núcleos (8 core processor) da linha Intel ou AMD tecnologia x64, com o clock mínimo ou superior a 2.3 Ghz.

Quantidade de usuários

Threads em execução pelo Scheduler ou Jobs  também são consideradas como usuários. Leve isso em consideração ao realizar o sizing.

As seguintes tabelas exibem as recomendações para a(s) máquina(s) que executará(ão) o ERP Protheus, com até 100 usuários. Acima desta quantidade, é recomendável que seja realizado o dimensionamento por projeto.

Memória RAM

32,2GB

Tamanho mínimo do volume (Sistema Operacional)120GB

Tamanho mínimo do volume (ERP)

250GB 

Throughput de escrita mínima do disco (SSD - ERP)

96  MB/s

Throughput de leitura mínima do disco (SSD - ERP)

48  MB/s

Placa de rede 

1 gigabit 

Quantidade 

Nome do serviço

01

AppLicense Server

01

Broker HTTP AppServer (conexões via WAN/LAN)

01

AppServer webapp (secundário)

01

AppScheduler

01

AppWebService

01

DBAccess

Métricas de Memória

O valor de 182MB foi calculado de acordo com a média do consumo constatada nos testes, baseado nos dados por conexão do ERP. Para cenários com customizações, estime cerca de 30% adicionais caso o valor padrão não atenda às suas necessidades.

Este sizing se aplica para ambientes normalizados, indicando o hardware mínimo para o uso do ERP. Um ambiente normalizado é onde as condições de hardware e software seguem padrões predefinidos de qualidade, sem variações externas ou personalizações fora do comum, facilitando a previsibilidade, estabilidade e eficiência. Customizações que consumam recursos de maneira inadequada podem afetar o sizing, de acordo com a exigência computacional do programa. Caso o consumo de recursos seja muito superior à esta estimativa, realize a análise de seu ambiente para identificar e se obter o entendimento da rotina com maior uso de memória, e se é possível alterá-la para otimizar o consumo de recursos.

O consumo de memória do ERP exibido neste documento foi calculado utilizando a regressão linear (que é o processo de traçar uma reta através dos dados em um diagrama de dispersão) dos dados coletados nos clientes piloto da release 12.1.2410.

Como calcular a memória mínima de um host para 100 conexões feitas em um appserver?

  • 100 usuários x 182 MB = 18200 MB = 18,2GB (consumo no appserver) + 6GB (DBAccess, License) = 24,2GB.

  • 24,2GB para o ERP + 8GB reservado para o Sistema Operacional+Antivírus (mínimo recomendado).

  • Chegamos ao cálculo dos 32,2GB do Host supracitado.

Para análise e acompanhamento do consumo de memória por rotina, pode-se utilizar as seguintes chaves no appserver.ini: DebugThreadUsedMemory e ServerMemoryInfo.

Confira também as ferramentas para fazer o monitoramento de seu ambiente.

Consumo do AppServer

Com a evolução do binário, o comportamento em estudo chegou a 500 conexões simultâneas nos testes de benchmark. Recomendamos, no entanto, que cada Appserver seja dimensionado para até 120 conexões simultâneas para se ter uma margem de segurança. Todos os clientes que passam pela engenharia tem como recomendação reduzir a quantidade de appserver, respeitando a margem de segurança.

E qual é o cenário ideal de conexões por appserver?

Para uma melhor experiência com o produto, recomendamos usar entre 80 a 120 usuários simultâneos. Desta forma, o mapeamento de RPO no appserver é otimizado, garantindo melhor consumo de recursos.

Uso do DBAccess na release 12.1.2410

A melhor experiência para esta release é usar o dbaccess modo distribuído a partir de 500 conexões simultâneas; é a melhor prática a ser adotada, podendo usufruir do modo de espelhamento (SPOFLess) do dbaccess.

As vantagens do dbaccess distribuído são: diminuir a sobrecarga de um único dbaccess e ter uma melhor distribuição do processamento até a chegada ao banco, reduzindo os pontos de falha.

Não é recomendado o uso do dbaccess no servidor SGBD.

Exemplo de DBAccess distribuído conectado ao banco de dados:

Para o banco de dados

Utilize processadores com 8 núcleos (8 core processor) da linha Intel ou AMD tecnologia x64, com o clock mínimo ou superior a 2.3 Ghz.

A seguinte tabela exibe as recomendações para a máquina que executará o banco de dados.

Memória RAM

42GB

Tamanho mínimo do volume (Sistema Operacional)120GB

Tamanho mínimo do volume (Database)

400GB 

Throughput de escrita mínima do disco (SSD - Database)

144 MB/s

Throughput de leitura mínima do disco (SSD - Database)

96 MB/s

Placa de rede 

1 gigabit

Performance de IOPS

Quanto maior o valor de IOPS, melhor o desempenho do disco. Para exemplificar melhor esta proporção, verifique os dados da tabela abaixo:

Para a release 12.1.2410 é recomendo o uso de volumes com SSD.

Disco 7.200 RPM SATA 

~75-100 IOPS (não Recomendado)

Disco 15.000 RPM SAS

~175-210 IOPS (não Recomendado)

Disco SSD simples (primeira geração) SATA 3 Gb/s

~8.600 IOPS (Recomendado)

Disco SSD Nova Geração 6Gb/s

~85.000 IOPS (Preferencial)

Storage: Pontos importantes

  • Não recomendamos o uso de discos SATA 7.200 RPM, discos SAS 10.000 e 15.000 RPM.
  • Não recomendamos o uso de conexão iSCSI de 1GbE, mas sim, no mínimo, canais de 10GbE para o uso iSCSI.
  • Em caso de uso de storage com suporte ao TIER, utilize, de preferência, Tier 0, Tier 1 e Tier 2. Porém, é necessário validar a tecnologia de cada Storage, em alguns casos o cache da Storage pode suprir a necessidade do ambiente.
  • Na camada do Sistema Operacional é importante verificar se a média de escrita ou leitura se mantém inferior a 20ms
  • Não recomendamos o uso do Protheus no modelo Tier 3 pela sua baixa performance, tanto para o banco de dados quanto para a aplicação, pois o mesmo se aplica para cenários de backup, que não terão muito acesso em disco.
  • Algumas Storages indicam o Tier 2 somente para backup. Verifique a documentação de cada fabricante para conferir qual Tier é indicado para o ambiente de produção.
  • Em Storages com tecnologia mais antiga, os Raids indicados são 5, 10 e 50. Porém, as storages mais recentes apresentam novas tecnologias de cache que aceleram o acesso aos dados. Analise a documentação de cada storage para verificar o melhor raid ou tier para seu cenário.

Consulte também as páginas referentes à ajustes recomendados para VMWare e à ajustes recomendados para Hyper-V.

  • Sem rótulos