Histórico da Página
Informações |
---|
Esta ferramenta será descontinuada em releases posteriores. |
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.
Nota | ||
---|---|---|
| ||
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 | 24 GB22GB |
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 AppServer (conexões via WAN/LAN)(Recomendação) |
01 | AppServer (secundário) |
01 | AppScheduler |
01 | AppWebService |
01 | DBAccess |
Aviso | ||
---|---|---|
| ||
Para Utilize o Broker para realizar a distribuição dos serviços, utilize o Broker, que 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 SmartClient e o Appserver. |
Note que: O balanceamento de carga tradicional "Load Balance" será descontinuado. |
Aviso | ||
---|---|---|
| ||
♦ A partir desta release (12.1.2210), não é necessário o uso do LockServer em ambientes Linux; este serviço será descontinuado em releases posteriores. ♦ Note que: O Lockserver é um serviço exclusivo para ambientes Linux. |
Métricas de Memória
O valor de 167MB foi 145MB 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. 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 (Regressão linear: é 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.332210.Para 100 conexões, por exemplo, deve ser feito o seguinte cálculo:
Como calcular a memória mínima de um host para 100 conexões feitas em um appserver?
100 usuários x 167 145 MB = 16700 14500 MB = 16GB 14,1GB (consumo no appserver) + 4GB (DBAccess e , License) = 20GB18,1GB.
20GB 18GB para o ERP + 4GB reservado para o Sistema Operacional (mínimo recomendado).
Chegamos ao cálculo dos 24GB 22GB do Host supracitado.
Informações |
---|
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é 100 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.
Para o banco de dados
Utilize processadores com 8 núcleos (8 core processorsprocessor) da linha Intel com HyperThread habilitadoou 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 | 32 42 GB | |||
Tamanho mínimo do volume | 400GB | (Sistema Operacional) | 120GB | |
Tamanho mínimo do volume (Database) | 500GB | |||
Throughput Velocidade de escrita mínima do disco (SSD - Database) | 144 MB500 mbps/s | |||
Velocidade Throughput de leitura mínima do disco | 500 mbps/s | Throughput mínimo do disco | (SSD - Database) | 96 MB3GB/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.2210 é 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) |
Nota | ||
---|---|---|
| ||
|
Provisionamento de
Disco em Virtualizadoresdisco em virtualizadores (VMWare)
No momento da criação dos disco é necessário realizar o formato de provisionamento. Os seguintes principais formatos de provisionamento de Disco são Thin e Thick. Esses formatos, inicialmente, foram mais popularizados nos virtualizadores; também são muito utilizados em algumas Storages.
- Provisionamento Thin: não aloca o espaço no sistema de arquivos no momento da criação do disco.
- Provisionamento Thick: aloca o espaço no sistema de arquivos no momento da criação do disco.
- Para artefatos do Protheus e banco de dados, utilize Thick Provision Eager Zeroed.
O Formato Thin é é interessante para ambientes de desenvolvimento, onde não há a necessidade de melhor performance. A recomendação para se obter melhor performance do ERP e Banco de dados é que se utilize o formato Thick, alocando, no início da criação do volume, todo o espaço necessário.Recomendação para o ambiente virtual:.
Informações |
---|
Consulte também a página referente à ajustes recomendados para VMWare. |
Provisionamento de disco em virtualizadores (Hyper-V)
Recomendamos o uso do VHDX em modo (fixed size) foi introduzido no Windows Server 2012 ou superior tem uma melhor relação de benefícios muito melhor em relação ao formato VHD.
- Melhor alinhamento do formato de disco rígido virtual para trabalhar melhor com discos com setores grandes;
- Tamanhos de blocos maiores para discos dinâmicos e diferenciados, o que melhora o seu desempenho;
- 4 kilobytes (KB) do setor lógico de disco virtual, o que aumenta o desempenho quando usado por aplicativos que são projetados para setores com 4 KB;
- Eficiência na representação de dados, o que resulta em menor tamanho de arquivo, de modo que o armazenamento físico subjacente ao dispositivo pode recuperar o espaço não utilizado (a operação de compensação).
Selecione a opção VHDX. Este formato suporta discos virtuais de até 64 TB e é resiliente para problemas de consistência que possam ocorrer em caso de falhas de energia elétrica. Este formato não é suportado em sistemas operacionais anteriores ao Windows Server 2012.
Informações |
---|
Consulte também a página referente à ajustes recomendados para Hyper-V. |