Limite de Memória no SQL Server

Adicionalmente ao post que eu fiz sobre Configuração de Balance no Protheus gostaria também de compartilhar uma configuração muito simples e que pode salvar servidores que estão à beira de um colapso, especialmente quando as aplicações do Protheus e o SQL Server rodam na mesma máquina. Essa situação (aplicações e banco no mesmo servidor) não é muito recomendada quando a empresa começa a exigir mais do sistema (a partir de 30 usuários simultâneos; ou quando se utiliza rotinas de processamento com certa frequência). Mas sabemos que nem todos possuem estrutura ($$$) suficiente para um dimensionamento ideal. Dessa forma, travamentos no sistema podem ser resolvidos com o Balance que expliquei anteriormente. Mas a lentidão ainda existirá. Resolvê-la completamente é outra história. Exige realmente um correto dimensionamento dos servidores, de preferência feito por um Analista de Infra e um bom DBA (eu não sou nem um nem outro!).

No entanto, podemos reduzir bastante a lentidão e praticamente nos livrar de travamentos no servidor por estouro de memória. Sabemos que o Windows Server não faz um gerenciamento de memória perfeito, portanto quando falei sobre o Balance expliquei que o ideal é que os appservers do Protheus não trabalhem com mais de 1 GB de memória cada. Acompanhando esse raciocínio, devemos então entender que o servidor precisa ter disponível esse 1 GB de memória RAM para cada appserver que configuramos. Quando temos uma demanda de 20 a 40 usuários, o SQL Server roda muito bem com 2 GB de RAM dedicados. Mas no padrão, o SQL Server utiliza TODA a memória disponível do sistema, e isso não é nada bom, pois o Windows Server frequentemente se enrola. Precisamos resolver isso! Então devemos definir no SQL Server um limite máximo de uso de memória.

(1) No Management Studio, clique com o botão direito no servidor conectado.

(2) Em seguida, clique em Propriedades ou Properties.

memsql_1

 

(3) Acesse a página Memória ou Memory.

(4) Edite o campo Maximum server memory ou Memória máxima do servidor.

memsql_2

Pronto. Ao confirmar essa tela, imediatamente você poderá ver no monitor de recursos ou gerenciador de tarefas, que o SQL Server agora ocupará no máximo o número que você determinou. Lembrando que você somente conseguirá editar essa configuração se for o administrador do SQL Server.

Assim, se configuramos um balance com 1 master e 3 slaves, por exemplo, ter um servidor com 8 GB de memória RAM é suficiente, pois deixamos 2 GB para o próprio Windows Server que trabalhará com uma folga + 4 GB para os appservers + 2 GB para o SQL Server.

Mais uma vez quero deixar claro de que não sou um expert em Infra tão menos um DBA. Minhas dicas são com base na minha experiência no mercado atendendo empresas de médio e grande porte como consultor de negócios, analista e programador, onde eventualmente me deparo com problemas no servidor e preciso dar solução imediata. Então, por favor, não considerem as minhas dicas como a última verdade!

Mas elas funcionam 😉

Configuração de Balance no Protheus

Aviso: os números nesse post são baseados na minha experiência durante os anos de trabalho com consultoria. No entanto, não sou especialista em infra e por isso não leve como uma regra.

Normalmente quando mais de 20 usuários utilizam o sistema já é desejável dividir o serviço do Protheus em 2 ou mais aplicações para que todas operem longe do limite de memória (algo em torno de 1 GB). Quando uma aplicação Protheus ultrapassa esse limite de uso de memória física, não é raro experimentar lentidão no uso do Smartclient e até mesmo travamentos no Appserver.

A configuração do balance, então, se faz necessária. O que é balance? O próprio nome explica, balanço. É uma aplicação comumente chamada de Master, que faz uma divisão dos usuários logados para cada servidor de aplicação (Slaves) existente. Quando o usuário abre seu Smartclient e requisita uma conexão com o Master, este verifica os usuários logados em cada Slave e direciona o usuário para o Slave mais disponível entre todos de acordo com a porcentagem configurada para proporção de cada Slave.

Para saber em qual aplicação se encontra cada usuário, utilize a coluna “Servidor” no Monitor para identificar o endereço e porta do Slave:

monitor

Uma vez entendido o conceito podemos então concluir que é necessário a configuração de um Appserver Master e 2 ou mais Appservers Slaves. Não é nada complexo e compreende apenas numa configuração do arquivo INI de cada servidor.


1) Comece replicando a pasta “appserver” dentro de “bin” criando por exemplo 5 cópias da pasta: appserver_master, appserver_slave1, appserver_slave2, appserver_slave3 e appserver_slave4.

2) Vamos configurar 1 master com 4 slaves proporcionando 25% das conexões para cada um deles.

2.1) Appserver.ini – Master:

Configure neste appserver a porta TCP que deseja que os smartclients se conectem, por exemplo 5010. Depois adicione as seguintes configurações no fim do arquivo (modifique o endereço IP deste exemplo):

[ServerNetwork]
MasterConnection=0
Servers=SLAVE1, SLAVE2, SLAVE3, SLAVE4

[SLAVE1]
Type=TCPIP
Server=192.168.1.1
Port=5011
Connections=25

[SLAVE2]
Type=TCPIP
Server=192.168.1.1
Port=5012
Connections=25

[SLAVE3]
Type=TCPIP
Server=192.168.1.1
Port=5013
Connections=25

[SLAVE4]
Type=TCPIP
Server=192.168.1.1
Port=5014
Connections=25

2.2) Appserver.ini – Slaves:

Configure cada slave em sua respectiva porta TCP de acordo com o configurado em SLAVE1, SLAVE2, SLAVE3 e SLAVE4 no INI do Master.

2.3) Configuração como serviço:

Lembre-se de adicionar a configuração de nome do serviço diferente em todos os appservers configurados para que seja possível distinguí-los na lista de serviços do servidor.

servicos

Exemplo da configuração:

[Service]
Name=TOTVS11_MASTER
DisplayName=TOTVS 11 – Master

[Service]
Name=TOTVS11_SLAVE1
DisplayName=TOTVS 11 – Slave 1

[Service]
Name=TOTVS11_SLAVE2
DisplayName=TOTVS 11 – Slave 2

[Service]
Name=TOTVS11_SLAVE3
DisplayName=TOTVS 11 – Slave 3

[Service]
Name=TOTVS11_SLAVE4
DisplayName=TOTVS 11 – Slave 4

3) Smartclients

Todos os Smarclients devem apontar sempre para o endereço e porta da aplicação master.


Bastando essas configurações para colocar em funcionamento o Balance. Se o seu Protheus está trabalhando com 40 ou mais usuários, todos sentirão uma boa melhora na performance.

Esta configuração de exemplo funciona bem com até 120 usuários simultâneos. Eu utilizo como referência a base de 30 usuários por aplicação slave. Evidentemente isso depende do uso, características do sistema, rotinas utilizadas e hardware disponível para o sistema. E como disse no aviso ao início desse post: não sou perito em infra, portanto esses números são conclusões pessoais minhas no decorrer da minha experiência dentro das empresas.